Zone sharding for tiered hardware (hot, warm, cold)
Parent: Independent shard scaling and per-shard tiering · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Zone sharding for tiered hardware (hot, warm, cold). 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
- Hot, warm, and cold are operator-defined zone names and hardware choices, not fixed MongoDB storage classes. MongoDB documents a fast recent tier and a slower archive tier; a third intermediate tier extends the same range-placement mechanism. (medium confidence) [source]
- Rolling retention tiers require an operator or automation to update absolute date boundaries. The balancer enforces the configured ranges; a fixed boundary does not advance merely because documents become older. Rotation frequency trades operational frequency against migration volume per rotation. (medium confidence) [source]
How-to and procedures
- To benefit from targeted reads, queries should include the relevant shard key or usable prefix. Queries without it can broadcast across shards, so a cold tier can remain part of an application read path even when most user-facing data is recent. (high confidence) [source]
- Configure zone placement before allowing newly added low-spec shards to receive ordinary balancing traffic. Percona warns that adding those shards with the balancer running can move unintended data; MongoDB's hardware-tier tutorial stops balancing while configuring zones. (high confidence) [source]
Problems, failure modes and limitations
- A reported hot/cold configuration with shard key order {id, ts} used MinKey-to-MaxKey spans for id in both ranges and failed with an overlapping-zone-range error. This illustrates why a trailing timestamp cannot be treated as an independent age partition across every leading id. (medium confidence) [source]
- Zone configuration needs eligible destination shards. The balancer policy warns that chunks in a zone with no assigned shards cannot be balanced, so a tier label and its date ranges alone do not provision working cold capacity. (high confidence) [source]
Comparisons and alternatives
- Age-based placement needs a shard key whose ordered ranges can distinguish the ages being separated. A creation-date prefix can support this; hashing the age field makes its zone ranges operate on hash values rather than chronological intervals. (high confidence) [source]
- Zone intervals include their lower bound and exclude their upper bound, and cannot overlap. Derived ordering consequence: when the leading date and field names are equal, an upper bound ending in MaxKey sorts above a lower bound ending in MinKey. Those bounds leave an overlapping key interval rather than being the same adjacent boundary; use matching complete compound-key boundaries. (medium confidence) [source]
Facts and statements
- Zone sharding maps shard-key ranges to named groups of shards. Assigning recent and archival ranges to shards with different hardware lets one collection serve data with different latency requirements. (high confidence) [source]
- Cold-shard economics depend on having substantial rarely accessed data and accepting slower reads for it. Smaller RAM and CPU allocations and slower, higher-capacity disks can reduce infrastructure cost, but these sources do not establish a generally applicable savings percentage. (high confidence) [source]
- Zone changes converge through chunk migrations. Existing chunks can violate the new placement rules until balancing completes, and migration activity can affect cluster performance; plan rotation timing and verify final placement. (high confidence) [source]
- Ranges outside all configured zones may reside on any shard. Cover the intended chronological domain explicitly if hot/warm/cold hardware placement must apply to all records. (high confidence) [source]
- A monotonically increasing timestamp used for range sharding can concentrate new writes on the highest-key chunk and its shard. Hardware tiering therefore does not by itself distribute concurrent new inserts across the hot shards. (high confidence) [source]
Children
- No children recorded.