Guía de Dimensionamiento de Shards en Elasticsearch: Equilibrando Rendimiento y Escalabilidad

Elasticsearch es un potente motor de búsqueda y análisis distribuido que sobresale en el manejo de grandes volúmenes de datos. Sin embargo, lograr un rendimiento y estabilidad óptimos depende significativamente de cómo estructures la distribución de tus datos, específicamente, el dimensionamiento de shards. Los shards son los bloques fundamentales de los índices de Elasticsearch; determinan cómo se particionan, replican y distribuyen los datos entre los nodos del clúster. Un dimensionamiento inadecuado de los shards puede provocar graves cuellos de botella en el rendimiento, un aumento en la sobrecarga operativa o, por el contrario, recursos infrautilizados.

Esta guía de dimensionamiento de shards de Elasticsearch te ofrece una forma práctica de elegir un número inicial de shards y validarlo con métricas de carga de trabajo reales. El objetivo no es un número perfecto; es una disposición de shards que se mantenga recuperable, buscable y asequible a medida que tus datos crecen.

Entendiendo los Shards de Elasticsearch

Antes de profundizar en el dimensionamiento, es esencial entender qué es un shard y cómo funciona dentro de la arquitectura del clúster. Un índice en Elasticsearch está compuesto por uno o más shards primarios. Cada shard primario es un índice independiente basado en Lucene que puede alojar datos.

Shards Primarios vs. Réplicas

Shards Primarios: Contienen los datos reales. Son responsables de las operaciones de indexación y búsqueda. Cuando defines el número de shards primarios para un índice, decides cómo se distribuirán los datos horizontalmente en el clúster.
Shards Réplica: Son copias de los shards primarios. Proporcionan redundancia (tolerancia a fallos) y aumentan el rendimiento de búsqueda al permitir que las consultas sean atendidas tanto por copias primarias como por réplicas.

El Impacto del Número de Shards

El número total de shards (Primarios + Réplicas) impacta directamente en la sobrecarga del clúster. Cada shard requiere memoria (espacio en el heap) y recursos de CPU para rastrear su estado y metadatos. Demasiados shards pequeños abruman al nodo maestro y aumentan la sobrecarga de gestión del clúster, lo que lleva a una degradación del rendimiento, incluso si los shards individuales son pequeños.

Restricciones Clave y Recomendaciones de Dimensionamiento

No existe un único "número mágico" para el tamaño del shard. El tamaño óptimo depende en gran medida de tu volumen de datos, tasa de indexación y patrones de consulta. Sin embargo, la documentación de Elasticsearch y las mejores prácticas de la comunidad ofrecen varias pautas cruciales.

1. Umbral de Tamaño: El Tamaño Óptimo del Shard

El factor más crítico es el tamaño de los datos contenidos en un solo shard.

Rango objetivo común: Muchos clústeres de producción apuntan a shards primarios en el rango de 10GB a 50GB.
Precaución con shards grandes: Los shards más grandes pueden funcionar para algunas cargas de trabajo de solo añadidura o de baja consulta, pero aumentan el tiempo de recuperación y hacen que la reubicación sea más costosa. Prueba antes de confiar en shards cercanos o superiores a 100GB.

¿Por qué el límite? Si un nodo falla, Elasticsearch debe reasignar (reubicar o replicar nuevamente) los shards almacenados en ese nodo. Los shards grandes aumentan significativamente el tiempo necesario para la recuperación, incrementando la ventana de resiliencia reducida. Además, Lucene funciona mejor cuando gestiona segmentos de tamaño mediano.

2. Umbral de Recuento de Documentos

Si bien el tamaño es primordial, el recuento de documentos también es relevante, especialmente para documentos muy pequeños.

No existe un recuento seguro universal de documentos por shard. Un shard con millones de documentos de registro diminutos puede comportarse bien, mientras que un shard con menos documentos grandes y muy analizados puede ser costoso. Realiza un seguimiento tanto del tamaño del almacenamiento del shard como del comportamiento de la carga de trabajo en lugar de confiar únicamente en el recuento de documentos.

3. Sobrecarga del Clúster y Número de Shards

Limita el número total de shards por nodo para gestionar eficazmente el consumo de recursos.

Las guías antiguas a menudo usaban reglas de shard por GB de heap. Trátalas como señales de advertencia aproximadas, no como límites estrictos. Elasticsearch moderno tiene una sobrecarga de heap por shard más baja que las versiones anteriores, pero demasiados shards aún aumentan el trabajo del estado del clúster, los identificadores de archivos, la sobrecarga de segmentos y la complejidad de la recuperación.

Metodología Práctica de Dimensionamiento de Shards

Utiliza los siguientes pasos para calcular el número apropiado de shards primarios para un nuevo índice basado en el tamaño total esperado de los datos.

Paso 1: Estimar el Tamaño Total del Índice

Determina la cantidad total de datos que esperas que este índice almacene durante su vida operativa (por ejemplo, 6 meses o 1 año).

Ejemplo: Anticipamos almacenar 2 TB de datos para nuestro índice logs-2024.

Paso 2: Definir el Tamaño Objetivo del Shard

Selecciona un tamaño objetivo seguro basado en las pautas (por ejemplo, 40GB).

Ejemplo: Tamaño objetivo del shard = 40 GB.

Paso 3: Calcular los Shards Primarios Requeridos

Divide el tamaño total estimado por el tamaño objetivo del shard. Siempre redondea al número entero más cercano.

$$\text{Shards Primarios} = \text{Techo} \left( \frac{\text{Tamaño Total del Índice}}{\text{Tamaño Objetivo del Shard}} \right)$$

Ejemplo de Cálculo (2 TB = 2048 GB): $$\text{Shards Primarios} = \text{Techo} \left( \frac{2048 \text{ GB}}{40 \text{ GB}} \right) = \text{Techo}(51.2) = 52$$

En este escenario, debes crear el índice con 52 shards primarios.

Paso 4: Determinar el Número de Réplicas

Decide el número de réplicas según tus necesidades de resiliencia y volumen de búsqueda.

Resiliencia: Establece number_of_replicas en al menos 1 (para alta disponibilidad).
Rendimiento de Búsqueda: Si el tráfico de búsqueda es intenso, usa 2 o más réplicas.
Ejemplo: Elegimos 1 réplica para tolerancia a fallos estándar.

Configuración Final del Índice: 52 shards primarios y 1 réplica (104 shards en total).

Paso 5: Distribuir entre Nodos

Asegúrate de que tu clúster tenga suficientes nodos, heap, disco y capacidad de E/S para alojar estos shards de manera efectiva. Con réplicas, Elasticsearch debe poder colocar cada réplica en un nodo diferente al de su primario.

Gestión del Ciclo de Vida del Índice y Redimensionamiento

Elasticsearch no te permite cambiar index.number_of_shards directamente en un índice existente. Puedes usar flujos de trabajo de división, reducción o reindexación, pero cada uno tiene requisitos y costos operativos.

El Rol de la Gestión del Ciclo de Vida del Índice (ILM)

Para datos de series temporales (logs, métricas), la mejor práctica es aprovechar la Gestión del Ciclo de Vida del Índice (ILM) y la función Rollover.

En lugar de crear un índice masivo y difícil de gestionar, creas un alias de rollover que apunta a una plantilla.

Fase Hot: Los datos se escriben en el índice activo actual. ILM monitorea este índice según el tamaño o la antigüedad (por ejemplo, hacer rollover cuando alcance los 40GB).
Rollover: Cuando se cumple el umbral, Elasticsearch crea automáticamente un nuevo índice basado en la plantilla (con el número calculado de shards primarios) y cambia el alias para que apunte al nuevo índice. El índice antiguo pasa a una fase diferente (Warm/Cold).

Este enfoque te permite mantener shards de tamaño constante y con un rendimiento óptimo a lo largo del ciclo de vida de tus datos.

Cuándo es Necesario Re-shardear (Avanzado)

Si un índice existente crece mucho más allá de la recomendación de 50GB debido a patrones de datos imprevistos, debes emplear la API de Reindexación para corregir la distribución de shards:

Crea un nuevo índice con la configuración de shards corregida (óptima).
Usa la API de Reindexación para copiar todos los datos del índice antiguo y mal dimensionado al nuevo.
Actualiza los alias para que apunten al nuevo índice.
Elimina el índice antiguo.

Advertencia sobre la Reindexación: La reindexación es una operación intensiva en recursos. Debe programarse durante períodos de bajo tráfico y requiere suficientes recursos del clúster para manejar la carga simultánea de indexación y copia.

Resumen de Mejores Prácticas

Área	Mejor Práctica / Pauta
Tamaño Individual del Shard	Mantén los shards primarios entre 10GB y 50GB (máximo 100GB).
Recuento de Documentos	Observa el recuento de documentos como una señal secundaria, pero valida con métricas de consulta e indexación.
Sobrecarga del Clúster	Mantén el número de shards lo suficientemente bajo para que la presión del heap, las actualizaciones del estado del clúster y la recuperación se mantengan saludables.
Gestión de Índices	Usa la Gestión del Ciclo de Vida del Índice (ILM) y Rollover para datos de series temporales para asegurar un dimensionamiento óptimo continuo.
Redimensionamiento	No intentes cambiar el número de shards primarios en índices en vivo; usa la API de Reindexación para migrar datos a un nuevo índice correctamente dimensionado.

Comienza con un tamaño objetivo de shard, calcula los shards primarios a partir del volumen de datos esperado, luego valida con pruebas de carga y métricas de producción. Para datos de series temporales, el rollover de ILM suele ser la forma más limpia de mantener los tamaños de shard predecibles sin intervención manual constante.