分片概念：块、均衡器和分片键

Sharding is MongoDB's horizontal scaling strategy. Instead of storing all data on a single replica set, a sharded cluster divides the data across multiple shards, each of which is itself a replica set. This lets you scale storage, throughput, and memory horizontally by adding more shards as your data grows.

A sharded cluster has three roles: Shards — replica sets that store the actual data. mongos — a query router that receives client connections and routes operations to the correct shard(s). Config servers — a replica set that stores cluster metadata, including the shard key ranges and chunk locations. Clients always connect to mongos, never directly to shards.

The shard key is a field (or compound of fields) you choose when sharding a collection. MongoDB uses the shard key value to determine which shard a document belongs to. Every document in a sharded collection must contain the shard key, and the key is immutable — you cannot change it after sharding. Choosing the wrong shard key is the most common MongoDB scaling mistake.

MongoDB divides the shard key range into chunks — contiguous ranges of shard key values. Each chunk lives on exactly one shard. By default, a chunk grows up to 128 MB before MongoDB splits it into two smaller chunks. The shard each chunk lives on is tracked in the config server metadata.

The balancer is a background process that monitors chunk distribution across shards. If one shard has significantly more chunks than others (by default, a difference of 8 or more), the balancer migrates chunks from the busiest shard to less-loaded shards. Migrations happen automatically and try to avoid peak traffic windows.

When a query includes the shard key, mongos routes it directly to the one (or few) shards that hold matching documents — a targeted query. When the query does not include the shard key, mongos must send it to all shards and merge results — a scatter-gather query. Targeted queries are dramatically faster. Design your queries around the shard key for best performance.

A hot shard (or hot spot) occurs when a disproportionate share of reads or writes land on a single shard. Common causes: using a monotonically increasing shard key (like createdAt or ObjectId) so all new inserts always go to the highest chunk, or using a low-cardinality key (like a boolean) that limits parallelism. Hot shards negate the benefits of sharding.

A jumbo chunk is a chunk that has grown beyond the maximum size but cannot be split because all of its documents share the same shard key value. Jumbo chunks cannot be migrated by the balancer and create a persistent imbalance. The fix is to choose a shard key with sufficient cardinality so that no single key value maps to more documents than fit in one chunk.

sh.status() gives a complete picture of your sharded cluster: which collections are sharded, how many chunks exist per shard, and the key ranges each shard owns. Use it to quickly spot imbalanced chunk distribution and confirm that the balancer has completed migrations after adding a new shard.

Adding a shard to a running cluster is an online operation. The balancer automatically migrates chunks from existing shards to the new one over time. You can pre-split chunks before adding a shard to speed up initial distribution, especially when bulk-loading data. No downtime is required when adding shards.

Sharding adds operational complexity. Before sharding, exhaust vertical scaling and indexing options. Common triggers to shard: data volume > 1–2 TB on a single replica set, write throughput that saturates a single primary, or working set that no longer fits in RAM. Always benchmark with explain() and profiling before deciding to shard.

In this lesson you learned: sharding distributes data across multiple shards (replica sets) using a shard key, chunks are contiguous shard key ranges the balancer migrates to maintain even distribution, and targeted queries (including the shard key) are far more efficient than scatter-gather queries. Next up we explore how to choose the right shard key.