Strategie di sharding ranged e hashed

MongoDB supports two built-in sharding strategies: ranged sharding and hashed sharding. Ranged sharding assigns contiguous ranges of shard key values to specific shards; hashed sharding applies a hash function to the key first and distributes based on the hash. Both have distinct strengths, and the right choice depends on your data access patterns.

In ranged sharding, MongoDB divides the shard key's value space into contiguous ranges and assigns each range (chunk) to a shard. For example, users with userId 1–10,000 go to shard A, 10,001–20,000 to shard B, and so on. Documents with nearby shard key values are co-located on the same shard, which is ideal for range queries.

Ranged sharding excels when your application frequently queries ranges of values: date ranges, price ranges, alphabetical name ranges, or paginated results sorted by a numeric ID. Because adjacent values are co-located, range queries become targeted queries that touch only one or a few shards, keeping latency low.

The critical weakness of ranged sharding is write hot spots when the shard key is monotonically increasing (timestamps, auto-increment IDs, ObjectId). All new documents cluster at the high end of the range and land on one shard. Until the balancer migrates chunks, this shard absorbs all write traffic while other shards sit idle.

In hashed sharding, MongoDB computes a hash of the shard key value and uses the hash to determine the chunk. Documents are distributed based on hash values, which appear random even if the original keys are monotonically increasing. This guarantees a near-uniform initial write distribution across all shards.

Hashed sharding is the best choice when your primary goal is uniform write distribution across shards and you do not need range queries on the shard key. It is ideal for high-insert-rate workloads with monotonic keys (event logs, IoT sensor data, messaging) where every shard should absorb an equal share of write traffic.

The trade-off of hashed sharding is that range queries on the shard key become scatter-gather. Because adjacent hash values are scattered across shards, a query like { createdAt: { $gte: t1, $lte: t2 } } must fan out to all shards. If range queries are frequent and latency-sensitive, hashed sharding may negate the performance gains from sharding.

Decision guide: Ranged sharding → your shard key has natural distribution (not monotonic) AND your top queries are range queries on that key. Hashed sharding → your shard key is monotonic OR your top queries are point lookups (equality) on a high-cardinality field. When in doubt and inserts are the bottleneck, prefer hashed.

You can combine both strategies with a compound shard key where the first field is ranged and gives query affinity, while adding a hashed second field spreads the load within each range. Example: { tenantId: 1, _id: 'hashed' } co-locates data by tenant for targeted queries while distributing writes across shards within each tenant.

You can inspect a collection's sharding configuration to determine which strategy is in use. The config server metadata stores the shard key and whether it uses 'hashed'. The sh.status() command and db.collection.stats() both expose this information.

When bulk-loading data into a freshly sharded collection, all chunks initially live on one shard and must be migrated by the balancer — which can be slow. Pre-splitting creates an initial set of empty chunks distributed across all shards before loading. This ensures the balancer's work is minimised and writes are spread from the first insert.

In this lesson you learned: ranged sharding co-locates similar key values for efficient range queries but creates hot spots with monotonic keys, hashed sharding distributes uniformly across shards but makes range queries scatter-gather, and compound keys can combine both benefits. Next up we explore zone sharding for pinning data to specific regions.