Nivel 3 · 30 min

Sharding

El sharding distribuye datos en múltiples servidores (shards) para escalar más allá de la capacidad de un solo nodo. Elegir la shard key correcta es la decisión más crítica en sharding: una elección incorrecta es difícil y costosa de revertir.

Selección de Shard Key

Una shard key determina cómo se distribuyen los documentos entre shards. Criterios para una buena shard key: alta cardinalidad (muchos valores distintos), distribución uniforme de escrituras (ningún shard recibe escrituras desproporcionadas), aislamiento de queries (las queries pueden apuntar a un shard específico vs scatter-gather). Las targeted queries incluyen la shard key en el filtro: mongos enruta al shard específico. Las scatter-gather queries no incluyen la shard key: mongos transmite a todos los shards y mergea resultados (costoso). Malas shard keys: campos de baja cardinalidad, campos monótonamente crecientes.

Hash vs Range Sharding

El range sharding distribuye chunks basándose en rangos de valores de shard key. Valores de shard key adyacentes van al mismo shard. Pros: queries de rango eficientes. Cons: las claves monótonamente crecientes (ObjectId, timestamp) crean write hotspots. El hash sharding aplica una función hash a la shard key antes de distribuir. Pros: distribución uniforme de escrituras incluso para claves monótonamente crecientes. Cons: las range queries se dispersan por todos los shards. El zone sharding (basado en tags) asigna rangos de shard key a shards específicos.

Gestión de Chunks y Balancing

Los datos se distribuyen como chunks (default 128 MB). Cada chunk cubre un rango contiguo de valores de shard key. El balancer migra automáticamente chunks entre shards cuando la distribución se vuelve desigual (umbral: 8 chunks de diferencia). Los chunk splits ocurren cuando un chunk crece más allá del tamaño máximo. Jumbo chunks: chunks que no pueden dividirse porque todos los documentos tienen el mismo valor de shard key — síntoma de baja cardinalidad. Los jumbo chunks no pueden migrarse por el balancer, causando imbalance permanente.

Puntos clave

La shard key no puede cambiarse después del sharding (MongoDB 5.0+ permite resharding limitado). Elegí cuidadosamente de antemano: modelá tus patrones de query antes de seleccionar.
Las shard keys monótonamente crecientes (timestamp, ObjectId) causan write hotspots con range sharding. Usá hashed sharding para distribución uniforme de escrituras.
Los jumbo chunks son señal de baja cardinalidad de shard key. No pueden balancearse, causando distribución desigual permanente. Prevenirlos eligiendo shard keys de alta cardinalidad.

Code example

// Enable sharding on a database\nsh.enableSharding('myapp')\n\n// Shard a collection with hashed shard key (avoids hotspot)\nsh.shardCollection(\n  'myapp.events',\n  {tenantId: 1, _id: 'hashed}\n)\n\n// Check shard distribution\ndb.events.getShardDistribution()\n\n// Check for jumbo chunks\ndb.getSiblingDB('config').chunks.find({jumbo: true}).count()