point of Cassandra is scalability and distributed processing,
right?
-- Jack Krupansky
From: Drew Kutcharian
Sent: Friday, August 29, 2014 7:31 PM
To: user@cassandra.apache.org
Subject: Re: Data partitioning and composite partition key
Hi Jack,
I think you missed the point of my
of Cassandra is scalability and distributed
> processing, right?
>
> -- Jack Krupansky
>
> From: Drew Kutcharian
> Sent: Friday, August 29, 2014 7:31 PM
> To: user@cassandra.apache.org
> Subject: Re: Data partitioning and composite partition key
>
> Hi Jack,
&
separate nodes?
I mean, the whole point of Cassandra is scalability and distributed processing,
right?
-- Jack Krupansky
From: Drew Kutcharian
Sent: Friday, August 29, 2014 7:31 PM
To: user@cassandra.apache.org
Subject: Re: Data partitioning and composite partition key
Hi Jack,
I think you
Hi Rob,
I agree that one should not mess around with the default partitioner. But there
might be value in improving the Murmur3 partitioner to be “Composite Aware”.
Since we can have composites in row keys now, why not be able to use only a
part of the row key for partitioning? Makes sense?
I
On Fri, Aug 29, 2014 at 3:48 PM, Drew Kutcharian wrote:
> AFAIK, currently Cassandra partitions (thrift) rows using the row key,
> basically uses the hash(row_key) to decide what node that row needs to be
> stored on. Now there are times when there is a need to shard a wide row,
> say storing eve
Hi Jack,
I think you missed the point of my email which was trying to avoid the problem
of having very wide rows :) In the notation of sensorId-datatime, the datatime
is a datetime bucket, say a day. The CQL rows would still be keyed by the
actual time of the event. So you’d end up having Seso
With CQL3, you, the developer, get to decide whether to place a primary key
column in the partition key or as a clustering column. So, make sensorID the
partition key and datetime as a clustering column.
-- Jack Krupansky
From: Drew Kutcharian
Sent: Friday, August 29, 2014 6:48 PM
To: user@cas
