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 just opened this JIRA https://issues.apache.org/jira/browse/CASSANDRA-7850 - Drew On Aug 29, 2014, at 4:36 PM, Robert Coli <rc...@eventbrite.com> wrote: > On Fri, Aug 29, 2014 at 3:48 PM, Drew Kutcharian <d...@venarc.com> 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 events per sensor, so you’d have sensorId-datetime row key so you > don’t end up with very large rows. Is there a way to have the partitioner use > only the “sensorId” part of the row key for the hash? This way we would be > able to store all the data relating to a sensor in one node. > > As a general statement, if you believe you need to create a custom > Partitioner in order to handle your use case, you are almost certainly wrong > or Doing It Wrong. > > =Rob
