Hashed, ranged and compound hashed shard keys
Parent: Shard Key Design and Resharding as Cost Levers · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Hashed, ranged and compound hashed shard keys. 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.
Definitions
- Field order is a design choice: a hashed prefix can address monotonically increasing input values, whereas a non-hashed prefix retains that prefix's ordering and the later hashed field distributes values within each prefix. (medium confidence) [source]
Structure and components
- A compound hashed shard key hashes exactly one component and combines that hash with the other, ordered components. The hashed field need not be first; for example, {tenantId: 1, eventId: 'hashed'} preserves a tenant prefix while adding hashed event values. (high confidence) [source]
How it works
- Yorkie's MongoDB design documents three workload-specific choices: ranged project_id for Documents and Schemas; hashed doc_id for document-wide collections; and {project_id: 1, _id: 'hashed'} for Clients. It explicitly notes that a maintenance query omitting project_id causes scatter-gather. (low confidence) (verified as of 2026-10-30) [source]
Problems, failure modes and limitations
- Hashing does not create distinct values from repeated identical input values. Low cardinality or frequent complete shard-key values can therefore still limit distribution. Adding a sufficiently variable compound component can increase the number of distinct complete keys; high cardinality alone does not guarantee even load. (high confidence) [source]
Comparisons and alternatives
- Cost implication, inferred from the documented routing and distribution behavior: evaluate candidate keys against both write concentration and read fan-out. A key that spreads inserts but broadcasts frequent range reads can move the resource bottleneck rather than reduce total work. No cited source supplies a general cost-reduction percentage. (medium confidence) [source]
Facts and statements
- Ranged sharding partitions original shard-key values into contiguous ranges. Nearby values can remain together, allowing range reads to contact only shards containing the requested ranges; locality and distribution still depend on the chosen key. (high confidence) [source]
- A monotonically increasing ranged shard key directs new inserts to the current upper-end range and can bottleneck its shard. Hashing a high-cardinality monotonic field spreads distinct incoming values across the hash space and can distribute writes more effectively. (high confidence) [source]
- For a single-field hashed shard key, an equality predicate can target one shard, but a range predicate on the original values loses range locality and may require a broadcast. The hashed index itself does not support original-value range queries. (high confidence) [source]
- Percona's worked MongoDB 4.4 example changes a frequently repeated hashed key from {index: 'hashed'} to {index: 'hashed', _id: 1}; its purpose is to make repeated index values separable by the additional ordinary field. (low confidence) [source]
- Including a compound shard-key prefix can let mongos target a shard or set of shards. It does not guarantee single-shard execution: the prefix's matching ranges may reside on multiple shards. Queries lacking a useful shard-key prefix generally require broadcast routing. (high confidence) [source]
- Refining a shard key adds suffix fields while preserving the existing key as its prefix. Percona demonstrates extending {index: 'hashed'} to {index: 'hashed', _id: 1}. This can distinguish documents sharing the original value; it does not replace or reorder the original prefix. (high confidence) [source]
Children
- Hashed component position in compound shard keys (frontier)
- Shard-key cardinality and value frequency (frontier)
- Range-query locality versus equality targeting (frontier)
Frontier under this node: Hashed component position in compound shard keys, Range-query locality versus equality targeting, Shard-key cardinality and value frequency