15. Sharding
1
The picture to keep in your head2
15.1 Why shard at all?3
15.2 How do you choose the shard key?4
15.3 What are the ways to map keys to shards?5
15.4 What is a hot shard?6
15.5 How do you add shards without moving everything?7
15.6 What happens to queries and joins that cross shards?8
15.7 How do you keep IDs and unique rules across shards?9
15.8 How do sharding and replication work together?10
Memory card and where the analogy breaks11
Practice: five levels12
Interview questions13
Solutions14
Sources15
Code lab15. Sharding
15.2 How do you choose the shard key?
3 min read+10 XP
At the exam centre: The rule decides everything. Split by roll number and every hall gets a fair share. Split by surname initial and the "S" hall overflows. Split by date of registration and all the late students crowd the newest hall.
In the system: The shard key (or partition key) is the column used to decide which shard a row lives on. It's the most important sharding decision, because it decides:
- Even spread: a good key has many distinct values and spreads reads and writes evenly. A bad key (country, status, today's date) piles traffic onto a few shards.
- Which queries stay on one shard: a query that includes the shard key goes to one shard; a query without it must ask all of them (15.6). So pick the key from your most frequent queries.
- What can be done together: transactions and joins are easy only within one shard. Data that's changed or read together should share a shard key.
For the bookstore's orders, user_id is a strong choice:
- millions of users, so plenty of spread;
- the hottest queries ("my orders", "my cart", checkout) all include the user;
- one user's orders, items and payments can live together on one shard.
What it makes harder: "all orders for book 42" or "today's sales" now span every shard. That's fine for admin and analytics, which can use a separate copy built for them (15.6).
Memory code: "Pick the key your busiest questions already contain, with many values and even traffic."