Sharding per zone: assegnare i dati alle regioni

Zone sharding (formerly tag-aware sharding) lets you assign specific shard key ranges to designated groups of shards called zones. Documents whose shard key falls in a zone's range are stored only on the shards belonging to that zone. This enables geographic data residency, hardware-tier affinity, and workload isolation within a single sharded cluster.

Zone sharding solves several production problems: Data residency — EU GDPR requirements mandate that European user data stays in EU data centers. Tiered storage — keep hot recent data on NVMe shards and cold archive data on slower, cheaper shards. Tenant isolation — in a multi-tenant SaaS application, pin each enterprise customer's data to dedicated shards for noisy-neighbor prevention.

The first step is to assign a zone tag to one or more shards. A shard can belong to multiple zones. Tags are just arbitrary strings you choose. Once tagged, the balancer will only move chunks assigned to a zone tag onto shards that carry that same tag.

Next, define which shard key ranges map to each zone using sh.addTagRange(). This tells the balancer: 'all documents with a shard key in this range must live on shards tagged with this zone.' Use MinKey and MaxKey as open-ended range boundaries.

Zone sharding requires a compound shard key where the first component is the zone discriminator (e.g., region, tenantId, tier). The second component provides granularity within the zone for further splitting. Example: { region: 1, userId: 1 } — region routes to the right zone; userId allows fine-grained chunk splitting within each zone.

Once zones are configured, the balancer continuously enforces zone membership. If a chunk with a key in the EU zone range ends up on a US shard (e.g., after adding a shard or changing zone definitions), the balancer migrates it to an EU shard. This migration happens automatically during the next balancer round.

Zone sharding enables tiered storage: assign recent data (e.g., current month) to a 'hot' zone on fast NVMe-backed shards, and older data to a 'cold' zone on slower HDD-backed shards. As data ages, you can update the zone range assignments so the balancer gradually migrates aging chunks from the hot zone to the cold zone.

Zone range assignments can be updated to move data as business needs change. Remove an existing range with sh.removeTagRange() and add a new one. The balancer will then migrate the affected chunks to match the new assignment. This is how you roll data from a 'hot' zone to a 'cold' zone monthly.

When using a compound zone-aware shard key like { region: 1, userId: 1 }, queries that include the region field are automatically routed to the correct zone's shards. This gives both data residency compliance and query performance — EU queries never touch US shards.

Zone sharding has some important limitations: 1) It only works with ranged sharding (not hashed sharding with a single field). 2) Documents not covered by any zone range can be balanced to any shard — ensure your ranges cover all possible values using MinKey to MaxKey. 3) Zone migration can take time for large collections; plan migrations during low-traffic windows.

You can inspect the current zone configuration at any time. The zone tags are stored in the config server's config.shards and config.tags collections. sh.status() prints zone information along with chunk distribution, making it easy to verify that the balancer has enforced zone membership correctly.

In this lesson you learned: zone sharding pins shard key ranges to tagged shards for data residency and workload isolation, a compound shard key with a zone discriminator as the first field is required, and the balancer automatically enforces zone membership and migrates chunks when zone assignments change. Next up we explore performance tuning and the database profiler.