When and How Should you Shard?
summary
Explains when sharding actually speeds queries or writes, and how to pick a shard key with measurable evidence: turn the profiler to full, parse logs with pt-mongodb-query-digest, replay traffic with MongoDB Replay or Facebook Flashback against a cloned cluster, then measure balancing and SLAs. Gives concrete limits: chunks move in 32–64MB batches (up to ~250k docs), hash keys hurt past 5–6 shards, arrays and nulls are forbidden and resharding requires delete-and-reload.
AI-written summary · about
chapters (8)
- 0:00Sharding concepts
- 1:04Why shard your database
- 5:22Choosing shard key
- 8:53Proving shard key choice
- 13:26Validating shard key
- 17:04Rules for shard key
- 20:37Validating sharding
- 23:03Q&A
related talks
47mSharding in MongoDB
45mSharding and Things We'd Like To See Improved
52mTo Shard or Not to Shard
32mA New Sharding Architecture for MongoDB
32mThe New MongoDB Sharding Architecture
34mScaling Applications with MongoDB: Best Practices and Challenges
41mHow to Survive Under Load with 100TB in an Unsharded MongoDB
33mFive Sharding Data Models and Which is Right