A hot partition holds disproportionately more data than other partitions. It often results from a partitioning scheme that does not fit the data’s distribution. The imbalance can worsen latency and limit throughput even when other partitions have spare capacity. section 5.5.1 section 5.5
Partitioning users by zip code
Suppose a users table is split into key ranges by zip code. If many users live in a few areas, the ranges containing those zip codes may hold most of the keys. Hashing the zip-code key instead can distribute those keys more evenly. Equal key counts are not enough, however: partitions containing larger values, such as large images in an object store, can still hold much more data. section 5.5.1
Check both key distribution and stored value sizes when investigating a hot partition, and measure application latency. Changing the partition key or scheme may help, but a poor initial choice can require rebalancing every partition—a difficult operation on a live system. Distinguish this data-volume problem from a skewed workload, where incoming processing is concentrated on only some partitions. section 5.1 section 5.5.1 section 5.5
