MongoDB
Explica cómo elegir una shard key según cardinalidad, frecuencia, distribución, consultas dirigidas, crecimiento y riesgo de hotspots.
La determina dónde se almacena cada documento y cómo enruta queries, updates y deletes. Es una decisión simultánea de distribución, localidad y acceso; una key con buena cardinalidad puede seguir siendo mala si no aparece en las consultas críticas.
mongosDebe tener suficientes valores distintos para repartir datos y permitir divisiones útiles. Una key como country con pocos valores concentra grandes rangos.
La distribución de documentos por valor debe ser razonablemente equilibrada. Alta cardinalidad no evita que un valor dominante concentre la mayoría del tráfico.
Una key creciente como timestamp puro dirige nuevas escrituras al extremo más reciente del espacio y puede crear un hotspot.
Las queries frecuentes deben incluir la key o un prefijo que permita targeting. Una distribución uniforme con consultas scatter-gather sigue siendo un mal resultado.
Preserva localidad de valores cercanos:
{ businessId: 1, createdAt: 1 }Ventajas:
Riesgos:
{ userId: 'hashed' }Distribuye valores de alta cardinalidad con mayor uniformidad. A cambio, pierde localidad para range queries sobre ese campo.
Es útil cuando predominan accesos por igualdad y el objetivo principal es distribuir writes. No asumas que “hashed” corrige baja cardinalidad o un único valor caliente.
Permiten combinar aislamiento y distribución:
{ businessId: 1, orderId: 'hashed' }Conceptualmente, businessId mantiene routing por tenant y la parte hashed puede repartir un tenant grande. La compatibilidad y sintaxis exacta dependen de versión; valida el servidor objetivo.
Otra alternativa:
{ businessId: 1, createdAt: 1, _id: 1 }Conserva rangos temporales y desempate, pero puede mantener concentración de writes recientes.
businessId es atractivo en SaaS porque muchas queries incluyen tenant. Pero si un negocio crece más que un shard, un valor único no puede repartirse libremente.
Analiza:
Puede necesitarse una key compuesta o zones para tenants específicos.
En colecciones sharded, los índices unique tienen restricciones relacionadas con la shard key. Si la identidad lógica es {businessId, sku}, la key y el índice deben diseñarse juntos.
No habilites sharding antes de saber qué duplicados deben ser imposibles globalmente.
Una shard key debería ser estable. Cambiarla puede implicar mover el documento entre shards y tiene requisitos dependientes de versión.
No uses un campo como status:
pending → confirmed → deliveredporque cambia frecuentemente, tiene baja cardinalidad y distribuye mal.
Una key grande aumenta cada índice relacionado, metadata y coste de routing. Prefiere valores compactos, tipados y consistentes.
String y ObjectId para la misma identidad crean rangos distintos y queries no coincidentes.
Antes de shardear:
Utiliza herramientas de análisis de shard key disponibles en la versión, profiler, sampled queries y explain. No elijas basándote solo en un diagrama del schema.
Métricas:
_id hashed automáticamente;La shard key controla tanto distribución como routing. Evalúala por cardinalidad, frecuencia, monotonicidad y query isolation. Range conserva localidad; hashed distribuye igualdad; compound equilibra fuerzas. La mejor key nace del workload y sus outliers, no del campo más obvio.
Balancer y distribución.