Estrategias de sharding por rangos frente a hash

MongoDB admite dos estrategias de fragmentación integradas: fragmentación por rangos y fragmentación hash. La fragmentación por rangos asigna rangos contiguos de valores de la clave de fragmentación a fragmentos específicos; la fragmentación hash aplica primero una función hash a la clave y distribuye los datos según el hash. Ambas tienen ventajas distintas, y la elección adecuada depende de sus patrones de acceso a los datos.

En la fragmentación por rangos, MongoDB divide el espacio de valores de la clave de fragmentación en rangos contiguos y asigna cada rango (bloque) a un fragmento. Por ejemplo, los usuarios con userId del 1 al 10.000 van al fragmento A, los del 10.001 al 20.000 al fragmento B, y así sucesivamente. Los documentos con valores cercanos de la clave de fragmentación se ubican conjuntamente en el mismo fragmento, lo que resulta ideal para las consultas por rangos.

La fragmentación por rangos destaca cuando su aplicación consulta con frecuencia rangos de valores: rangos de fechas, rangos de precios, rangos alfabéticos de nombres o resultados paginados ordenados por un ID numérico. Como los valores adyacentes se ubican conjuntamente, las consultas por rangos se convierten en consultas dirigidas que solo acceden a uno o unos pocos fragmentos, manteniendo una latencia baja.

La principal desventaja de la fragmentación por rangos son los puntos calientes de escritura cuando la clave de fragmentación aumenta monótonamente (marcas de tiempo, ID autoincrementales, ObjectId). Todos los documentos nuevos se concentran en el extremo superior del rango y llegan a un solo fragmento. Hasta que el balanceador migra los bloques, ese fragmento absorbe todo el tráfico de escritura mientras los demás permanecen inactivos.

En la fragmentación hash, MongoDB calcula un hash del valor de la clave de fragmentación y usa el hash para determinar el bloque. Los documentos se distribuyen según valores hash, que parecen aleatorios aunque las claves originales aumenten monótonamente. Esto garantiza una distribución inicial de las escrituras casi uniforme entre todos los fragmentos.

La fragmentación hash es la mejor opción cuando su objetivo principal es una distribución uniforme de las escrituras entre los fragmentos y no necesita realizar consultas por rangos sobre la clave de fragmentación. Es ideal para cargas de trabajo con una alta tasa de inserciones y claves monótonas (registros de eventos, datos de sensores IoT, mensajería), en las que cada fragmento debe absorber una parte igual del tráfico de escritura.

La contrapartida de la fragmentación hash es que las consultas por rangos sobre la clave de fragmentación se convierten en operaciones de dispersión y recopilación. Como los valores hash adyacentes se distribuyen entre distintos fragmentos, una consulta como { createdAt: { $gte: t1, $lte: t2 } } debe dirigirse a todos los fragmentos. Si las consultas por rangos son frecuentes y sensibles a la latencia, la fragmentación hash puede anular las mejoras de rendimiento obtenidas con la fragmentación.

Guía de decisión: fragmentación por rangos → su clave de fragmentación tiene una distribución natural (no es monótona) Y sus consultas principales son consultas por rangos sobre esa clave. Fragmentación hash → su clave de fragmentación es monótona O sus consultas principales son búsquedas puntuales (por igualdad) sobre un campo de alta cardinalidad. Si tiene dudas y el cuello de botella son las inserciones, prefiera la fragmentación hash.

Puede combinar ambas estrategias con una clave de fragmentación compuesta cuyo primer campo se distribuya por rangos y proporcione afinidad para las consultas, mientras que un segundo campo hash reparte la carga dentro de cada rango. Ejemplo: { tenantId: 1, _id: 'hashed' } ubica los datos conjuntamente por tenant para las consultas dirigidas y, al mismo tiempo, distribuye las escrituras entre los fragmentos de cada tenant.

Puede inspeccionar la configuración de fragmentación de una colección para determinar qué estrategia se está usando. Los metadatos del servidor de configuración almacenan la clave de fragmentación y si utiliza 'hashed'. Tanto el comando sh.status() como db.collection.stats() exponen esta información.

Al cargar datos en bloque en una colección recién fragmentada, todos los bloques se encuentran inicialmente en un solo fragmento y el balanceador debe migrarlos, lo que puede ser lento. La división previa crea un conjunto inicial de bloques vacíos distribuidos entre todos los fragmentos antes de la carga. Esto garantiza que se minimice el trabajo del balanceador y que las escrituras se distribuyan desde la primera inserción.

En esta lección ha aprendido que el sharding por rangos coloca conjuntamente valores de clave similares para realizar consultas por rangos de forma eficiente, pero crea puntos calientes con claves monotónicas, que el sharding hash distribuye los datos uniformemente entre los shards, pero hace que las consultas por rangos requieran scatter-gather y que las claves compuestas pueden combinar ambas ventajas. A continuación, exploraremos el zone sharding para fijar los datos en regiones específicas.