Art of Codeartofcode
Lesson 2 of 15

15. Sharding

1
The picture to keep in your head
2
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 breaks
11
Practice: five levels
12
Interview questions
13
Solutions
14
Sources
15
Code lab
15. Sharding

15.1 Why shard at all?

3 min read+10 XP

Splitting the data

At the exam centre: You split students across halls only when one hall can't fit them. It's more work: more invigilators, more answer sheets to collect, and "who topped the city?" becomes a bigger job. Nobody splits a 30-student exam across five halls.

In the system: Sharding (also called horizontal partitioning) splits a table's rows across several database servers, the shards. Each shard holds a subset of rows and handles reads and writes for that subset.

You shard when one machine can't cope with:

  • Data size: the data no longer fits on one server's disks, or backups and restores of it take too long.
  • Write throughput: the leader can't apply writes fast enough. Replication doesn't help here (Chapter 14, section 14.1); sharding does, because each shard takes only its share of writes.
  • Working set: the hot data no longer fits in one machine's memory.

Shard last, not first. It's the top rung of Chapter 6's database ladder: fix queries, cache, scale up, add replicas, and only then shard. Sharding changes how every query, transaction and constraint works, and it's very hard to undo. Many products never need it. Some systems also partition inside one database (splitting a table by month, say); that helps management and queries but isn't the same as spreading load across machines.

Memory code: "Split the halls only when one hall can't fit the students."