Summary
Cassandra uses a consistent hash ring (via Murmur3 partitioner by default) to distribute partition keys across nodes. Virtual nodes (vnodes) improve distribution uniformity and enable automatic rebalancing when nodes join or leave.
Evidence
- ·Cassandra uses Murmur3 partitioner to hash partition keys to tokens on a ring from -2^63 to 2^63-1
- ·{'Virtual nodes (default': '256 per node) enable proportional token assignment without manual token management'}
- ·When a new node joins, vnodes transfer token ranges from existing nodes automatically
- ·Replication factor N copies each partition to N distinct nodes: determined by token ring position
- ·Cassandra's documentation explicitly describes this as a consistent hash ring implementation
Operational Context
- ·Partition key design determines data distribution: low-cardinality keys create hot partitions
- ·NODESYNC (Cassandra 4.0) uses the token ring to schedule repair operations efficiently
- ·Changing vnode count requires a full data rebuild: vnode count should be set at cluster formation
Tradeoffs
- ·Murmur3 partitioner prevents range queries across partition keys: range queries require a secondary index
- ·Consistent hashing distributes data but does not prevent hot partitions if access is skewed
- ·Vnodes increase repair complexity: more token ranges to repair per node compared to single-token assignment
Evidence grounding
Grounded, 5 supporting itemsConsistent hashing is fundamental to Cassandra's distributed architecture, documented since the original Cassandra paper (Lakshman, Malik, 2010). Murmur3 partitioner and vnodes are core operational concepts.