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
gt;
> From: Drew Kutcharian
> Sent: Friday, August 29, 2014 6:48 PM
> To: user@cassandra.apache.org
> Subject: Data partitioning and composite partition key
>
> Hey Guys,
>
> AFAIK, currently Cassandra partitions (thrift) rows using the row key,
> basically uses th
@cassandra.apache.org
Subject: Data partitioning and composite partition key
Hey Guys,
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
Hey Guys,
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 events per sensor, so you’d have sensorId-datetime row
