# Hashed, ranged and compound hashed shard keys > Source-anchored research for Hashed, ranged and compound hashed shard keys. Run status: COMPLETED. Parent: [Shard Key Design and Resharding as Cost Levers](https://llms-explorer.com/tree/shard-key-design-and-resharding-as-cost-levers/) · 6 facets · 11 facts · page: https://llms-explorer.com/tree/hashed-ranged-and-compound-hashed-shard-keys/ ## 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) ## 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) ## 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](https://github.com/yorkie-team/yorkie/blob/main/docs/design/mongodb-sharding.md) ## 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) ## 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) ## 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](https://www.mongodb.com/docs/manual/core/ranged-sharding.md) - 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - 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](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - 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](https://www.percona.com/blog/refining-shard-keys-in-mongodb-4-4-and-above/) - 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](https://www.mongodb.com/docs/manual/sharding.md) - 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](https://www.percona.com/blog/refining-shard-keys-in-mongodb-4-4-and-above/)