Hashed versus ranged shard-key tradeoffs
Parent: Shard key selection for query isolation · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Hashed versus ranged shard-key tradeoffs. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Problems, failure modes and limitations
- A range predicate on the hashed field cannot use the hashed index for an ordered range scan. Such predicates remain executable, but hashing alone cannot use original-value ordering to isolate them to a small shard subset. (medium confidence) [source]
- A hashed index cannot itself carry a unique constraint. This index restriction must be considered separately from whether queries target one shard or broadcast. (medium confidence) [source]
Comparisons and alternatives
- Yorkie’s sharding design issue, last updated January 31, 2024, records choosing ranged project_id and doc_id keys after examining its query patterns, key properties, and uniqueness requirements. This is application-specific design evidence rather than a controlled hashed-versus-ranged benchmark. (low confidence) [source]
Facts and statements
- Ranged sharding partitions contiguous original shard-key values, so nearby values tend to share chunks or shards; hashed sharding partitions hash values, sacrificing that locality and making original-value range reads more likely to broadcast. (high confidence) [source]
- With a monotonically increasing single-field ranged shard key, the chunk ending at MaxKey receives most new inserts, concentrating writes on its shard; hashing a sufficiently diverse key spreads those inserts more evenly across the cluster. (high confidence) [source]
- With a single-field hashed shard key, mongos can target an equality match on that key to one shard; MongoDB computes the hash automatically, so the application supplies the original value. (medium confidence) [source]
- Hashing still requires a high-cardinality key. It does not create additional distinct original values or split documents sharing one complete shard-key value across shards; low cardinality and frequently repeated hot values remain distribution risks. (medium confidence) [source]
- Ranged sharding enables targeted bounded-range reads but does not promise that every range query reaches exactly one shard: a range spanning chunks on multiple shards still requires those shards. Ranged keys also need suitable cardinality, frequency, and insert patterns. (medium confidence) [source]
- MongoDB truncates floating-point values to 64-bit integers before hashing, so values such as 2.2, 2.3, and 2.9 share a hash. Fine-grained numeric distinctions therefore do not necessarily produce distinct hashed placement values. (medium confidence) [source]
- Ranged sharding partitions contiguous shard-key value ranges; nearby values are likely to share a chunk or shard. This supports targeted reads over contiguous key ranges, but does not guarantee that every range fits on one shard. (high confidence) [source]
- Hashing disperses nearby original key values across chunks and shards. Range predicates on a single-field hashed shard key therefore lose range locality and generally require broadcast operations, trading query isolation for more even data distribution. (high confidence) [source]
- A monotonically increasing ranged shard key concentrates incoming inserts in the chunk bounded above by MaxKey and its owning shard. Hashing that field spreads inserts across the cluster, making monotonically increasing ObjectId or timestamp values candidates for hashed sharding. (high confidence) [source]
- For workloads dominated by ranges on the shard-key value, prefer evaluating ranged sharding for locality. For high-volume inserts on a high-cardinality monotonic field, evaluate hashing while explicitly accepting the range-query fanout cost. This is workload guidance, not a universal latency or throughput guarantee. (medium confidence) [source]
Children
- No children recorded.