Choosing a Shard Key: Cardinality, Frequency, Monotonicity
Learners will evaluate shard key candidates against the three dimensions—cardinality, write distribution, and query targeting—and avoid hot shard anti-patterns.
Why Shard Key Choice Is Critical
The shard key is immutable once set and cannot be changed without unsharding and re-sharding the entire collection — an expensive, disruptive operation. Choosing the wrong shard key leads to hot shards, poor query routing, and wasted hardware. You must evaluate candidates against three dimensions: cardinality, frequency, and monotonicity.
Cardinality: How Many Distinct Values?
Cardinality is the number of distinct values the shard key can take. High cardinality (e.g., userId, email, orderId) is good — it gives MongoDB many possible chunk boundaries and lets the balancer distribute data finely. Low cardinality (e.g., status: 'active' | 'inactive', country with 50 values) creates jumbo chunks that cannot be split or migrated.
// HIGH cardinality — good shard key
sh.shardCollection('mydb.users', { userId: 1 })
// LOW cardinality — avoid: only 2 chunk boundaries possible
sh.shardCollection('mydb.users', { status: 1 }) // BADAll lessons in this course
- Sharding Concepts: Chunks, Balancer, and Shard Keys
- Choosing a Shard Key: Cardinality, Frequency, Monotonicity
- Ranged vs Hashed Sharding Strategies
- Zone Sharding: Pinning Data to Regions