Partitioning and Replication for Scale
Beyond one machine, data is split by key across nodes and copied for safety. The partition key decides which queries stay fast and which become scatter-and-gather, and the replication scheme decides what a read may return after a recent write.
What a learner can do afterwards
- Choose a partition key for a stated query mix and say which queries it hurts
- Explain what a hot partition is and how it arises from a skewed key
- Compare synchronous and asynchronous replication on what a reader can see
1 · Read
Past one machine, you split rows by a partition key and copy each part for safety. The key you choose decides which queries stay fast and which must knock on every door.
An orders table keyed by customer keeps one customer's orders together, so that lookup is quick. A report over all recent orders must visit every partition, which is slow scatter and gather. If one seller owns half the rows, its partition runs hot while the rest sit idle.
Copies guard against lost machines. With synchronous replication the write waits for its copies, so later reads see it. With asynchronous replication the write returns fast, but a quick read from a copy can return the older value.
Pick the key from your most common query, check the key for skew before you commit, and choose sync or async by asking how stale a read is allowed to be.
Split by the key your queries need, watch for skew, and pick copies that match how fresh your reads must be.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.