Key hash partitioning assigns records to horizontal partitions according to a hash of their partitioning-key values. Records with the same key go to the same partition. Spreading different keys across partitions can reduce hotspots and support lower-latency access, but the choice of key still matters. section 5.2.1
Figure 5.1 Horizontally partitioning a database table. On the left, you can see the full logical table with four rows. On the right side, you can see three horizontal partitions.
The table illustrates partitioning by Location: users in New York share a partition, while Sydney and Cape Town users occupy other partitions. section 5.2.1
Prefer a key with high cardinality, or combine columns to increase cardinality. A low-cardinality key creates too few distinct placements; skewed values can leave one partition much larger than the others. Hash partitioning can distribute unevenly spaced keys more effectively than key range partitioning, but range partitioning has an advantage when queries need range scans. section 5.2.1 section 5.5.1
Check partition size as well as key counts. Even partitions holding similar numbers of keys can differ substantially in size when their values differ—for example, when some partitions hold larger images. A poor scheme may require rebalancing every partition, which is difficult on a live system. section 5.5.1
Route a user-profile request
A partition-aware HTTP client could hash a user ID to choose the node holding that profile. The Rust REST API and client demonstration supplies node IDs and request routing, but its benchmark selects nodes round-robin; hashed user-ID routing and data partitioning are proposed extensions, not implemented results. Its lower tail latency with five nodes reflects parallel request handling, not a measured benefit of key hashing. section 5.6
