cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cassandra Wiki] Update of "Partitioners" by JonathanEllis
Date Fri, 05 Oct 2012 16:23:08 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "Partitioners" page has been changed by JonathanEllis:

  Cassandra supports the following partitioners, in order of preference.  TLDR: always use
!Murmur3Partitioner in new clusters.
- == !Murmur3Partitioner ==
+ == Murmur3Partitioner ==
  This is the default in Cassandra 1.2.  It's functionally the same as RandomPartitioner,
but Murmur3 is a much faster hash than MD5.  We don't care about MD5's cryptographic properties;
all we need is a good distribution over the hash space, which Murmur3 delivers.
- == !RandomPartitioner ==
+ == RandomPartitioner ==
  Default partitioner in Cassandra 1.1 and earlier.  Hashes with MD5.
- == !ByteOrderedPartitioner ==
+ == ByteOrderedPartitioner ==
  An order-preserving partitioner that operates on partition key bytes lexicographically.
- == !OrderPreservingPartitioner ==
+ == OrderPreservingPartitioner ==
  Assumes keys are UTF8 strings.  Not recommended both because of this limitation and because
globally ordering all your partitions generates hot spots: some partitions close together
will get more activity than others, and the node hosting those will be overloaded relative
to others.  You can try to mitigate with active load balancing but this works poorly in practice;
by the time you can adjust token assignments so that less hot partitions are on the overloaded
node, your workload often changes enough that the hot spot is now elsewhere.  Remember that
preserving global order means you can't just pick and choose hot partitions to relocate, you
have to relocate contiguous ranges.

View raw message