13 19:12
To: user@cassandra.apache.org
Subject: Re: data model advice needed
One possibility would be to use dynamic columns, with each column name being a
composite made from a timestamp, and the value of each containing serialized
json of the details. The host could be the key. Then you could
19:12
To: user@cassandra.apache.org
Subject: Re: data model advice needed
One possibility would be to use dynamic columns, with each column name being a
composite made from a timestamp, and the value of each containing serialized
json of the details. The host could be the key. Then you could slice
There are many different patterns in noSQL with 90% being different than
an RDBMS. Check out this page for some things to get you thinking
http://buffalosw.com/wiki/Patterns-Page/
If you ever consider playorm and you can figure out how to partition your
data(perhaps by month), you can do querie
-
From: "Hans-Peter Sloot"
To: user@cassandra.apache.org
Sent: Wednesday, February 27, 2013 1:01:24 PM
Subject: data model advice needed
Hi,
I would like to get some advice on how to model columnfamilies for storing log
of firewalls.
The columns are listed further below.
All the pos
Hi,
I would like to get some advice on how to model columnfamilies for storing log
of firewalls.
The columns are listed further below.
All the possibilities confuse me a bit (super columns, secondary indexes etc).
My main question is how can I create the columnfamily in order to be able to
get
On Fri, Feb 24, 2012 at 10:46 AM, David Leimbach wrote:
>
>
> On Thu, Feb 23, 2012 at 7:54 PM, Martin Arrowsmith
> wrote:
>>
>> Hi Franc,
>>
>> Or, you can consider using composite columns. It is not recommended to use
>> Super Columns anymore.
>
>
> Yes, but why? Is it because composite columns
On Thu, Feb 23, 2012 at 7:54 PM, Martin Arrowsmith <
arrowsmith.mar...@gmail.com> wrote:
> Hi Franc,
>
> Or, you can consider using composite columns. It is not recommended to use
> Super Columns anymore.
>
Yes, but why? Is it because composite columns effectively replace and
simplify similar mo
On Fri, Feb 24, 2012 at 2:54 PM, Martin Arrowsmith <
arrowsmith.mar...@gmail.com> wrote:
> Hi Franc,
>
> Or, you can consider using composite columns. It is not recommended to use
> Super Columns anymore.
>
> Best wishes,
>
On first read it would seem that there is fair bit of overhead with
compo
On Fri, Feb 24, 2012 at 2:54 PM, Martin Arrowsmith <
arrowsmith.mar...@gmail.com> wrote:
> Hi Franc,
>
> Or, you can consider using composite columns. It is not recommended to use
> Super Columns anymore.
>
Thanks,
I'll look in to composite columns
cheers
>
> Best wishes,
>
> Martin
>
>
> On
Hi Franc,
Or, you can consider using composite columns. It is not recommended to use
Super Columns anymore.
Best wishes,
Martin
On Thu, Feb 23, 2012 at 7:51 PM, Indranath Ghosh wrote:
> How about using a composite row key like the following:
>
> Entity.Day1.TypeA: {col1:val1, col2:val2, . . .
How about using a composite row key like the following:
Entity.Day1.TypeA: {col1:val1, col2:val2, . . . }
Entity.Day1.TypeB: {col1:val1, col2:val2, . . . }
.
.
Entity.DayN.TypeA: {col1:val1, col2:val2, . . . }
Entity.DayN.TypeB: {col1:val1, col2:val2, . . . }
It is better to avoid super columns..
Hi,
I've finished my first model and experiments with Cassandra with result I'm
pretty happy with - so I thought I'd move on to something harder.
We have a set of data that has a large number of entities (which is our
primary search key), for each of the entities we have a smallish (<100)
number
12 matches
Mail list logo
