Elección de una clave de shard: cardinalidad, frecuencia y monotonía

La clave de fragmentación es inmutable una vez establecida y no se puede cambiar sin desfragmentar y volver a fragmentar toda la colección, una operación costosa y disruptiva. Elegir una clave de fragmentación incorrecta provoca fragmentos calientes, un enrutamiento deficiente de las consultas y un desaprovechamiento del hardware. Debe evaluar las candidatas en tres dimensiones: cardinalidad, frecuencia y monotonicidad.

La cardinalidad es el número de valores distintos que puede adoptar la clave de fragmentación. Una cardinalidad alta (por ejemplo, userId, email, orderId) es beneficiosa: proporciona a MongoDB muchos límites de bloque posibles y permite que el balanceador distribuya los datos con precisión. Una cardinalidad baja (por ejemplo, status: 'active' | 'inactive' o country con 50 valores) crea bloques jumbo que no se pueden dividir ni migrar.

La frecuencia mide cuántos documentos comparten cada valor de la clave de fragmentación. Incluso las claves de alta cardinalidad pueden ser problemáticas si un pequeño número de valores aparece en la gran mayoría de los documentos. Por ejemplo, un campo countryCode podría tener 200 valores distintos, pero el 90 % de los usuarios podría proceder de un solo país, lo que crearía un bloque caliente enorme que no se puede dividir.

La monotonicidad indica si los valores de la clave de fragmentación aumentan (o disminuyen) siempre con el tiempo. Los campos como las marcas de tiempo createdAt y ObjectId (_id) son monótonamente crecientes. Esto resulta problemático porque todas las inserciones nuevas llegan al mismo bloque «máximo» de un fragmento, lo que crea un punto caliente de escritura incluso cuando los datos han estado distribuidos uniformemente históricamente.

La clave de fragmentación ideal tiene: alta cardinalidad: miles o millones de valores distintos. Poca asimetría de frecuencia: ningún valor domina. Distribución no monótona: los valores no aumentan siempre, o se usa fragmentación hash. Alineación con las consultas: coincide con los filtros de las consultas más frecuentes y sensibles a la latencia para permitir un enrutamiento dirigido.

Una clave de fragmentación compuesta combina dos campos para mejorar la distribución. Por ejemplo, { tenantId: 1, createdAt: 1 } distribuye los datos entre los tenants (alta cardinalidad) y permite consultas por rangos dentro de cada tenant. El primer campo determina la distribución general; el segundo proporciona una división más precisa. Las claves compuestas pueden satisfacer predicados de consulta con varios campos como consultas dirigidas.

Una clave de fragmentación hash aplica una función hash al valor del campo antes de asignarlo a un bloque. Esto convierte las claves monótonas (como ObjectId) en valores hash distribuidos aleatoriamente, eliminando los puntos calientes de escritura. La contrapartida es que las consultas por rangos sobre el campo se convierten en operaciones de dispersión y recopilación, ya que los valores hash no se almacenan en el orden original.

MongoDB permite la fragmentación por zonas, en la que se asignan rangos de claves de fragmentación a fragmentos específicos mediante etiquetas (zonas). Esto resulta útil para cumplir requisitos de residencia de datos: los datos de usuarios europeos pueden fijarse en fragmentos de la región de la UE y los datos de EE. UU., en fragmentos de EE. UU. La fragmentación por zonas requiere una clave de fragmentación compuesta cuyo primer componente sea un prefijo de región.

Al evaluar candidatas para la clave de fragmentación: 1) ejecute una comprobación de cardinalidad; db.col.distinct('field').length debería dar como resultado miles o más. 2) Compruebe la distribución de frecuencias mediante una agregación. 3) Determine si el campo es monótono (marcas de tiempo, incremento automático). 4) Revise sus 5 consultas más frecuentes: ¿aparece el campo candidato en su filtro?

Un valor predeterminado habitual y seguro para muchas cargas de trabajo es usar { _id: 'hashed' }. Los valores ObjectId de MongoDB, aunque son monótonos, se distribuyen uniformemente después de aplicarles un hash. Esto proporciona una distribución uniforme de las escrituras desde el principio. La principal limitación es que cualquier consulta por rangos sobre _id se convierte en una operación de dispersión y recopilación, pero para la mayoría de las cargas de trabajo de búsqueda a nivel de documento esto resulta aceptable.

MongoDB Atlas proporciona un Shard Key Advisor en Performance Advisor que analiza sus patrones de consulta y recomienda claves de fragmentación basándose en el uso real. Puede detectar claves monótonas, asimetrías de frecuencia e índices ausentes. Usar el asesor antes de fragmentar resulta especialmente útil para cargas de trabajo de producción cuyos patrones de consulta ya están establecidos.

En esta lección ha aprendido que: una buena clave de fragmentación tiene una cardinalidad alta, poca asimetría de frecuencia y evita los valores monótonos, las claves de fragmentación compuestas combinan cobertura para la distribución y el direccionamiento de consultas y la fragmentación hash neutraliza los puntos calientes de las claves monótonas a costa de la eficiencia de las consultas por rangos. A continuación, compararemos en detalle las estrategias de fragmentación por rangos y hash.