Hashed shard-key write distribution and local index locality
Parent: Random-key (hashed/UUID) index insert behavior · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Hashed shard-key write distribution and local index locality. 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.
How it works
- Random indexed inserts, explicitly including hashed indexes, can reduce local insert performance when the index working set no longer fits cache: cache eviction and replacement increase, and index updates require disk access. This is a conditional effect, not proof that every hashed workload is slower. (medium confidence) [source]
- Hashing an _id shard key does not mean the ordinary _id index has been replaced: a collection can have both {_id: 1} and {_id: 'hashed'}, and an additional unnecessary index consumes resources and adds maintenance overhead when indexed values are inserted or changed. (medium confidence) [source]
- For large bulk inserts of random indexed values, MongoDB documents a conditional performance decline: when accesses spread beyond the cached index, WiredTiger eviction and replacement increase and index updates involve disk. This is a cache-working-set condition, not a universal penalty for every random-key insert. (low confidence) [source]
Comparisons and alternatives
- Yorkie's sharding design supplies an independent application example: it selects hashed doc_id for document-wide collections to spread writes and selects keys according to query patterns. Treat this as a design rationale rather than a controlled benchmark or proof of universal throughput gains. (low confidence) (verified as of 2026-10-30) [source]
Facts and statements
- For a high-cardinality monotonically increasing shard key, ranged sharding concentrates new inserts in the MaxKey chunk; hashed sharding distributes them across hash ranges and can spread writes across shards. (high confidence) [source]
- Cluster write distribution and local index locality are separate concerns. Inference from the documentation: hashed sharding can distribute inserts while the maintained hashed index still incurs random-entry updates and cache pressure. Even shard traffic therefore does not guarantee fast per-shard inserts. (high confidence) [source]
- Hashing does not repair low cardinality or a hot repeated key. Identical shard-key values still map to the same hash and chunk; sufficiently frequent values can bottleneck a shard even if other hash ranges are well distributed. (high confidence) [source]
- With single-field hashed sharding, equality predicates on the shard key can target a shard, but nearby original values need not share a chunk or shard; range queries on that field are more likely to require broadcast operations. (high confidence) [source]
- The documented option to drop a hashed shard-key index can reduce index maintenance and improve insertion speed, but it is not a cost-free tuning step: the documented procedure disables balancing for that collection, requires checking for orphaned documents, and recommends a supporting non-hashed index to avoid collection scans on shard-key predicates. (medium confidence) (verified as of 2026-10-14) [source]
- Hashing does not create additional distinct values from a low-cardinality input or divide one repeated full shard-key value across chunks. High-frequency values can remain bottlenecks; a compound key with an additional low-frequency field can increase partitioning opportunities. (medium confidence) [source]
- Yorkie provides an application-owned example of choosing distribution and query grouping together: its design uses hashed doc_id for document-wide collections and a (project_id, hashed _id) key for clients, while retaining ranged project_id for documents and schemas. This is a design example, not a measured throughput comparison. (low confidence) [source]
- MongoDB documents support for dropping a hashed shard-key index starting with 7.0.3, 6.0.12 and 5.0.22, which can improve insertion speed. The drop procedure advises retaining a supporting non-hashed shard-key index to avoid collection scans for shard-key filters. (medium confidence) (verified as of 2026-10-30) [source]
- Dropping the hashed shard-key index excludes the collection from future balancing rounds until the index is recreated, and prevents the range deleter from cleaning remaining orphans. MongoDB instructs operators to stop the balancer and confirm that no orphans remain before dropping it; restarting the balancer does not restore eligibility for that collection. (low confidence) (verified as of 2026-10-30) [source]
Children
- No children recorded.