← DDIA

Chapter 06 · Partitioning

Partitioning

One customer is 30% of your traffic. One shard is on fire. Now what?

Split the data across N nodes. Every scheme trades one pain for another.

Three acts: 1. fire 2. schemes 3. pick

The fire

Even by design. Skewed by workload.

C clients P0 node-A P1 node-A P2 node-B P3 node-B P4 node-C P5 node-C req/s celebrity key · 1 partition · fan-out amplification

The fix waits three slides down. Hash first, then salting.

Takeaway

Hash spreads load. Range keeps scans cheap. Salting patches hot keys. Every scheme is a trade.

Pick your partitioning scheme.

01

Range

sorted keys, scan-friendly.

PICK WHEN range queries dominate · time-series with rolling windows.
STRUGGLES AT sequential keys (timestamps) → all writes on one partition.
EXAMPLES HBase, BigTable.
02

Hash

even load, no scans.

PICK WHEN point lookups dominate · load must spread evenly.
STRUGGLES AT range queries → scatter/gather across every partition.
EXAMPLES Cassandra hash, DynamoDB.
03

Fixed-N partitions

even load · cheap rebalancing.

PICK WHEN nodes come and go · you want to add capacity without downtime.
STRUGGLES AT range queries (same as hash) · one hot key still needs salting.
EXAMPLES Riak, Elasticsearch, Couchbase.

Rebalancing is orthogonal: fixed-N is the default sane choice; dynamic (HBase, Mongo) splits as data grows; proportional-to-nodes (Cassandra) scales bins with the cluster.