Hashed vs Ranged Sharding in MongoDB: Key Differences and Usage

In MongoDB, hashed sharding distributes data evenly by hashing the shard key, which balances load but limits range queries. Ranged sharding partitions data by continuous ranges of the shard key, enabling efficient range queries but may cause uneven data distribution.

Quick Comparison

This table summarizes the main differences between hashed and ranged sharding in MongoDB.

Factor	Hashed Sharding	Ranged Sharding
Data Distribution	Evenly distributed using hash of shard key	Partitioned by continuous ranges of shard key
Query Efficiency	Poor for range queries, good for equality queries	Excellent for range queries on shard key
Load Balancing	Automatically balanced across shards	May cause uneven shard sizes if data is skewed
Use Case	High write throughput with uniform key distribution	Range queries and sorted data access
Chunk Splitting	Chunks split by hashed values	Chunks split by key ranges
Complexity	Simpler to manage due to automatic balancing	Requires monitoring for hotspots and balancing

Key Differences

Hashed sharding works by applying a hash function to the shard key's value. This spreads documents evenly across shards regardless of the original key order, which helps prevent hotspots and balances write load well. However, because the data is distributed by hash, range queries on the shard key are inefficient or impossible to target a subset of shards.

In contrast, ranged sharding divides data into chunks based on continuous ranges of the shard key. This allows efficient range queries and sorted scans because related data is stored together on the same shard. But if the shard key values are not uniformly distributed, some shards can become overloaded, causing uneven data and load distribution.

Choosing between them depends on your query patterns and data distribution. Hashed sharding is best when you want even load and your queries mostly target specific keys. Ranged sharding is better when you need to run range queries or sort data by the shard key.

Code Comparison

Here is how to enable hashed sharding on a collection in MongoDB:

javascript

sh.enableSharding("myDatabase")
sh.shardCollection("myDatabase.myCollection", { "userId": "hashed" })

Output

Shard collection myDatabase.myCollection on { userId: "hashed" }

Ranged Sharding Equivalent

Here is how to enable ranged sharding on the same collection using a range shard key:

javascript

sh.enableSharding("myDatabase")
sh.shardCollection("myDatabase.myCollection", { "userId": 1 })

Output

Shard collection myDatabase.myCollection on { userId: 1 }

When to Use Which

Choose hashed sharding when you want to evenly distribute writes and your queries mostly target specific shard key values without range scans. It is ideal for workloads with high write throughput and uniform key distribution.

Choose ranged sharding when your application requires efficient range queries, sorted data access, or queries that scan ranges of the shard key. Be prepared to monitor and balance shards if data distribution is skewed.

Key Takeaways

Hashed sharding evenly distributes data but limits efficient range queries.

Ranged sharding supports efficient range queries but may cause uneven shard load.

Use hashed sharding for uniform key distribution and high write throughput.

Use ranged sharding when range queries or sorted access on shard key are needed.

Monitor shard balance closely when using ranged sharding to avoid hotspots.