Ranged vs Hashed Sharding, Compound Keys, and Prefix-Aware Targeting

Learning objectives

1. Ranged and hashed sharding optimize different locality

Ranged sharding preserves the sort order of shard-key values in the range map, so nearby values can share ranges and range predicates can be targeted. Hashed sharding stores ranges of the server-computed hash instead; logically adjacent source values are intentionally scattered through hash space. That usually improves write distribution for a high-cardinality monotonic key, but it sacrifices natural range locality.

2. Build ranged and hashed AtlasMart collections

const app=db.getSiblingDB("atlasmart");sh.enableSharding("atlasmart", "atlasmart-shard17-l2-a");app.events_range.drop();app.events_hash.drop();app.events_range.createIndex({tenantId:1,seq:1});printjson(sh.shardCollection("atlasmart.events_range", {tenantId:1,seq:1}));printjson(sh.splitAt("atlasmart.events_range", {tenantId:"m",seq:MinKey}));printjson(sh.moveChunk("atlasmart.events_range", {tenantId:"z",seq:1}, "atlasmart-shard17-l2-b"));app.events_hash.createIndex({eventId:"hashed"});printjson(sh.shardCollection("atlasmart.events_hash", {eventId:"hashed"}));const ranged=[], hashed=[];for (let i=1;i<=400;i++) {  const tenant = i%2 ? "b" : "p";  ranged.push({tenantId:tenant,seq:i,eventId:i,kind:"order"});  hashed.push({tenantId:tenant,seq:i,eventId:i,kind:"order"});}app.events_range.insertMany(ranged);app.events_hash.insertMany(hashed);sh.status(true);

The hashed collection's exact per-shard count is not a fixed expected number in this lesson. What matters is that the hash breaks the source-value ordering; verify the actual distribution with sh.getShardedDataDistribution().

3. Explain targeting, not just result correctness

function shardNames(explain) {  const found = new Set();  function walk(v) {    if (!v || typeof v !== "object") return;    if (typeof v.shardName === "string") found.add(v.shardName);    if (Array.isArray(v.shards)) {      for (const s of v.shards) {        if (s && typeof s.shardName === "string") found.add(s.shardName);        walk(s);      }    }    for (const k of Object.keys(v)) walk(v[k]);  }  walk(explain);  return Array.from(found).sort();}const app=db.getSiblingDB("atlasmart");for (const [label,coll,query] of [  ["range-prefix", app.events_range, {tenantId:"b"}],  ["range-full", app.events_range, {tenantId:"b",seq:42}],  ["range-no-prefix", app.events_range, {seq:{$gte:390}}],  ["hash-equality", app.events_hash, {eventId:42}],  ["hash-range", app.events_hash, {eventId:{$gte:390,$lt:400}}],]) {  const ex=coll.find(query).explain("executionStats");  printjson({label,query,shards:shardNames(ex),nReturned:ex.executionStats?.nReturned});}

For the ranged compound key, a query on the leading tenantId prefix can narrow routing even if it omits seq. A query on seq alone does not contain that prefix. For the hashed collection, an equality predicate lets mongos hash the value and target the corresponding range, but a source-value range such as 390–399 is not a contiguous hashed range.

4. Boundary case: “hashed means balanced” is too strong

from collections import Countervalues = ["mega"] * 700 + [f"t{i:03d}" for i in range(300)]counts = Counter(values)print("distinct source values:", len(counts))print("hottest source value frequency:", counts["mega"])print("Hashing maps each distinct value to a hash; it does not split 700 identical mega values into 700 independent values.")

5. Production judgment

Prefer ranged keys when business locality and range targeting are valuable and you can avoid hot edge ranges. Prefer hashed components when write distribution for a high-cardinality monotonic field dominates and equality targeting is sufficient. Compound keys let you blend concerns, but every additional field becomes part of the routing/index contract and future zone design. Measure explain shard fan-out and per-shard workload; do not infer production performance from a one-host lab.

Bridge. Lesson 3 replaces hand-calculated intuition with MongoDB's analyzeShardKey and sampled workload metrics.

Authoritative references

• Choose a Shard Key — Cardinality, frequency, monotonicity, query patterns, and shard-key tradeoffs.
• Troubleshoot Shard Keys — Hot ranges, uneven load, jumbo/indivisible ranges, and scatter/gather symptoms.
• analyzeShardKey — Key-characteristic and sampled read/write-distribution metrics.
• configureQueryAnalyzer — Query sampling for prospective shard-key analysis.
• Hashed Indexes for Sharding — Write distribution and range-query limitations.
• Zones — Zone membership, non-overlapping zone ranges, prefix requirements, and balancing behavior.
• addShardToZone — Associate shards with zone labels.
• Change a Shard Key — Refine versus reshard decision boundary.
• Refine a Shard Key — Append suffix fields without changing existing shard-key field types.
• reshardCollection — Full shard-key change, redistribution phases, demo mode, and abort/commit boundaries.
• unshardCollection — MongoDB 8.0+ consolidation of a sharded collection onto one shard.
• moveCollection — MongoDB 8.0+ relocation of an unsharded collection between shards.
• MongoDB Sharding — Routing, ranges, balancer behavior, and mongos-only client access.
• MongoDB 8.3 Release Notes — Current 8.3 release and sharding/DDL changes.
• mongosh Release Notes — mongosh 2.10.0 baseline.
• PyMongo Release Notes — PyMongo 4.17 baseline.