Sharding & Horizontal Scaling

Chapter 11: Sharding & Horizontal Scaling

Sharding is MongoDB's solution for horizontal scaling. It allows you to distribute a single logical dataset across multiple machines (Shards) to handle workloads that exceed the storage or I/O capacity of a single server. A sharded cluster consists of Shards (data storage), Config Servers (metadata), and Query Routers (mongos).

I. Shard Key Selection Strategy

The Shard Key is the most critical architectural decision. It determines how data is partitioned and how queries are routed.

  • High Cardinality: Choose a key with many unique values (e.g., user_id, email) to ensure fine-grained partitioning.
  • Write Distribution: Avoid monotonically increasing keys (like ObjectId or Timestamp) for ranged sharding, as they create a "Hot Shard" where all new writes hit a single node. Use Hashed Sharding for write-heavy workloads to distribute inserts uniformly.
  • Query Targeting: To avoid inefficient Broadcast (Scatter-Gather) queries, most application queries should include the shard key so the router can target a specific node.

II. Config Servers & Metadata Flow

The Config Servers store the cluster's "Source of Truth"—the mapping between data ranges (Chunks) and specific shards.

  • Consistency: Config servers are a replica set that uses w:majority to ensure metadata integrity.
  • Caching: Every mongos instance caches this metadata. When a chunk is moved, the config servers are updated, and the mongos instances are notified via a StaleConfig error on the next query.

mongosShard AShard BConfig RSCluster Metadata: config.chunks, config.shards

III. The Balancer & Jumbo Chunks

The Balancer is a background process that monitors the distribution of chunks across shards. If one shard has significantly more data, the balancer triggers a Chunk Migration (MoveChunk).

  • Jumbo Chunks: If a chunk grows too large and cannot be split (because all documents have the same shard key value), it becomes a Jumbo Chunk. The balancer cannot move jumbo chunks, leading to Data Skew and performance degradation.

IV. Production Anti-Patterns

  • Broadcast Storms: Sending queries without the shard key to a cluster with 50+ shards. This saturates the CPU and network of every node in the cluster simultaneously.
  • Unsharded Collections on Primary Shard: Keeping large, high-traffic collections unsharded. They will reside on the database's "Primary Shard," potentially overwhelming it while other shards remain idle.
  • Choosing a Low-Cardinality Key: Sharding on a status or is_active field. This results in very few chunks that quickly become jumbo and unmovable.

V. Performance Bottlenecks

  • Migration Contention: In high-write environments, background chunk migrations compete for the same disk I/O and network bandwidth as application writes, causing latency spikes.
  • Stale Config Refresh: When mongos encounters a StaleConfig error, it must block the query to refresh its metadata cache from the config servers, adding several hundred milliseconds of latency.
  • Cross-Shard Aggregate Merge: Performing a large $sort or $group in a sharded aggregation. All shards must send their results to a single node for final merging, creating a network and CPU choke point.
PreviousTake Quiz