Partition Key Selection

Foundations

In the first lesson, any key could be hashed to a node. Now, what if the hot read needs many records together and in order, so the choice of key decides whether one node or every node answers?

A composite key has two parts: a partition key, which chooses the node, and a sort key, which orders records within it. Choose as partition key the id that every hot read already carries, and as sort key the order that read needs, such as a sequence number. Then the read is one contiguous range on one node. The cost: one very busy partition key still lands on a single node.

Take records written by many authors into threads, always read one thread at a time, oldest first. Keyed by author, a thread's records scatter across nodes and must be merged. Keyed by (thread_id, seq), thread t1 lives on one node in order, and reading everything after sequence 40 is a single range scan.

• Partitioning

  Keys are spread over nodes by hashing. That lesson covers the ring.

  Open lesson

Case Scenario

To see how a partition key keeps a read on one node, consider chat history in an app like Slack: messages are stored in order per conversation, and readers always know the conversation id. Keyed by (conversation_id, seq), a conversation's history is one ordered range on one partition, with no global message table to scan.

Chat history is always opened for a known conversation, but its messages come from different senders. Splitting by sender scatters Ana’s and Bo’s lines even though readers need them together and in one order. A history request for conversation c1 must be one ordered range read on one partition, without scanning a global message table.