Fragmentos y réplicas de Elasticsearch: Una guía práctica

¿Todavía no conoces Elasticsearch? Únete a nuestro webinar de los Primeros pasos con Elasticsearch. También puedes iniciar una prueba gratuita en el cloud o prueba Elastic en tu máquina ahora mismo.

Elasticsearch potencia Lucene construyendo un sistema distribuido sobre él, que aborda los problemas de escalabilidad y tolerancia a fallos. También expone una API REST basada en JSON, lo que facilita mucho la interoperabilidad con otros sistemas.

Sistemas distribuidos como Elasticsearch pueden ser muy complejos, con muchos factores que pueden afectar su rendimiento y estabilidad. Los fragmentos son uno de los conceptos más fundamentales en Elasticsearch, y entender cómo funcionan te permitirá gestionar eficazmente un clúster de Elasticsearch.

Este artículo explica qué son los shards primarios y réplica, su impacto en un clúster de Elasticsearch y qué herramientas existen para ajustarlos a diferentes demandas.

Entendiendo fragmentos

Los datos en un índice de Elasticsearch pueden crecer a proporciones enormes. Para mantenerlo manejable, cada dato se almacena en un índice, y los índices son un índice dividido en varios fragmentos. Cada fragmento de Elasticsearch es un índice de Lucene Apache, donde cada índice individual de Lucene contiene un subconjunto de los documentos del índice de Elasticsearch. Dividir los índices de esta manera mantiene el uso de recursos bajo control. Un índice de Lucena apache tiene un límite de 2.147.483.519 (2³¹ - 129) documentos.

A veces, es necesario mover índices entre nodos para fines de reequilibrio. Dado que este proceso puede requerir tanto tiempo como recursos, los índices no deberían crecer demasiado, lo que ayuda a mantener el tiempo de recuperación manejable. Además, dado que los índices están compuestos por segmentos de Lucene que deben fusionar constantemente, es importante que los segmentos no se hagan demasiado grandes. Por estas razones, Elasticsearch divide los datos del índice en fragmentos más pequeños y manejables, llamados fragmentos primarios, que pueden distribuir más fácilmente entre varias máquinas. Los fragmentos réplica son simplemente una copia exacta de un fragmento primario correspondiente y repasaremos su función más adelante en este artículo.

Tener el número adecuado de fragmentos es importante para el rendimiento. Por tanto, es prudente planear con antelación. Cuando las consultas se ejecutan en diferentes fragmentos en paralelo, se ejecutan más rápido que un índice compuesto por un solo fragmento, pero solo si cada fragmento está ubicado en un nodo diferente y hay suficientes nodos en el clúster. Sin embargo, al mismo tiempo, los fragmentos consumen memoria y espacio en disco, tanto en términos de datos indexados como de metadatos de clúster. Tener demasiados fragmentos (también conocido como sobrefragmentación) puede ralentizar consultas, solicitudes de indexación y operaciones de gestión, por lo que mantener el equilibrio adecuado es fundamental.

El número de fragmentos primarios se define en el momento de la creación del índice para esa instancia específica del índice. Si necesitas un número diferente de fragmentos primarios más adelante, puedes usar las APIs de redimensionamiento: split (más shards primarios), shrink (menos shards primarios) o clone (el mismo número de shards primarios con nuevos ajustes para réplicas). Estas operaciones copian los segmentos de Lucene y evitan una reindexación completa de todos los documentos. Al crear un índice, puedes establecer el número de fragmentos primarios y réplica como ajustes del índice:

(Si no especificas el número de fragmentos o réplicas, el valor por defecto de ambos es 1, según Elasticsearch 7.0). El número ideal de fragmentos debe determinar en función de la cantidad de datos en un índice. Generalmente, un shard óptimo debe contener entre 10 y 50GB de datos, con menos de 200 millones de documentos por shard. Por ejemplo, si esperas acumular alrededor de 300GB de registros de aplicaciones en un día, tener alrededor de 10 fragmentos en ese índice sería razonable, siempre que tengas suficientes nodos para alojarlos.

Durante su vida, los fragmentos pueden pasar por varios estados, entre ellos:

• Inicializar: Un estado inicial antes de que se pueda usar el fragmento.
• Comenzó: Un estado en el que el fragmento está activo y puede recibir solicitudes.
• Reubicación: Un estado que ocurre cuando los fragmentos están en proceso de mover a otro nodo. Esto puede ser necesario bajo ciertas condiciones, por ejemplo, cuando el nodo en el que están se está quedando sin espacio en disco.
• No asignado: El estado de un fragmento que no fue asignado. Se proporciona una razón cuando esto ocurre, por ejemplo, si el nodo que aloja el fragmento ya no está en el clúster (NODE_LEFT) o debido a la restauración en un índice cerrado (EXISTING_INDEX_RESTORED).

Para ver todos los fragmentos, sus estados y otros metadatos, puedes usar la siguiente solicitud:

Para ver fragmentos de un índice específico, puedes agregar el nombre del índice a la URL, por ejemplo, sensor:

Este comando produce una salida, como en el siguiente ejemplo. Por defecto, las columnas que aparecen incluyen el nombre del índice, el nombre (es decir, número) del fragmento, si es un fragmento principal o una réplica, su estado, el número de documentos, el tamaño en disco, así como la dirección IP y el ID del nodo donde se encuentra el fragmento.

Comprensión de réplicas

Aunque cada fragmento contiene una única copia de los datos, un índice puede contener varias copias del fragmento. Por tanto, existen dos tipos de fragmentos: el fragmento principal y una copia, o réplica. Cada réplica de un fragmento primario siempre se encuentra en un nodo diferente, lo que garantiza una alta disponibilidad de tus datos en caso de fallo de un nodo. Además de la redundancia y su papel en la prevención de la pérdida de datos y el tiempo de inactividad, las réplicas también pueden ayudar a mejorar el rendimiento de búsqueda al permitir que las consultas se procesen en paralelo con el shard primario y, por tanto, más rápido.

Existen diferencias importantes en el comportamiento de los fragmentos primarios y réplica. Aunque ambos son capaces de procesar consultas, las solicitudes de indexación (es decir, Agregar datos al índice) debe pasar primero por los fragmentos primarios antes de poder replicar en los fragmentos réplica. Como se indicó antes, si un fragmento primario deja de estar disponible—por ejemplo, debido a una desconexión de nodo o fallo de hardware—se promueve una réplica para asumir su función.

Aunque las réplicas pueden ayudar en caso de fallo de un nodo, es importante no tener demasiadas porque consumen memoria, espacio en disco y potencia de cálculo al indexar. Otra diferencia entre los fragmentos primarios y las réplicas es que, aunque el número de fragmentos primarios no puede cambiar una vez creado el índice, el número de réplicas puede modificar dinámicamente en cualquier momento actualizando la configuración del índice.

Otro factor a considerar con las réplicas es el número de nodos disponibles. Las réplicas siempre se colocan en nodos diferentes del fragmento primario, ya que dos copias de los mismos datos en el mismo nodo no ofrecerían protección si el nodo fallara. Como resultado, para que un sistema soporte n réplicas, debe haber al menos n + 1 nodos en el clúster. Por ejemplo, si hay dos nodos en un clúster y un índice está configurado con seis réplicas, solo se asignará una réplica. Por otro lado, un sistema con siete nodos es perfectamente capaz de manejar un fragmento principal y seis réplicas.

Optimización de fragmentos y réplicas

Incluso después de que se creó un índice con el equilibrio adecuado entre fragmentos primarios y réplica, estos deben ser monitorizados, ya que la dinámica alrededor de un índice cambia con el tiempo. Por ejemplo, al tratar con datos de seriales temporales, los índices con datos recientes suelen estar más activos que los más antiguos. Sin ajustar estos índices, todos consumirían la misma cantidad de recursos, a pesar de sus requisitos muy diferentes.

La API de índices de rollover puede usar para separar índices más nuevos y antiguos. Se puede configurar para crear automáticamente un nuevo índice una vez alcanzado cierto umbral—el tamaño del índice en el disco, el número de documentos o la antigüedad. Esta API también es útil para mantener bajo control el tamaño de los fragmentos. Dado que el número de fragmentos no puede modificar fácilmente tras la creación del índice, los fragmentos seguirán acumulando datos si no se cumplen las condiciones de rollover. Para índices antiguos que solo requieren acceso poco frecuente, reducir y forzar la fusión de un índice son dos formas diferentes de reducir su huella de memoria y disco. La primera reduce el número de fragmentos en un índice, mientras que la segunda reduce el número de segmentos Lucene y libera espacio empleado por documentos que fueron eliminados.

Fragmentos primarios y réplica como base de Elasticsearch

Elasticsearch construyó una estable reputación como plataforma distribuida de almacenamiento, búsqueda y análisis para enormes volúmenes de datos. Sin embargo, al operar a tal escala, inevitablemente surgen desafíos. Por eso entender cómo funcionan los fragmentos primarios y réplica es tan importante y fundamental para Elasticsearch, ya que esto puede ayudar a optimizar la fiabilidad y el rendimiento de la plataforma.

Saber cómo funcionan y cómo optimizarlos es fundamental para lograr un clúster de Elasticsearch más robusto y eficiente. Si experimentas respuestas lentas o cortes de información con regularidad, este conocimiento puede ser la clave para superar estos obstáculos.

Sigue la documentación oficial de Elasticsearch para saber más sobre clústeres, nodos y fragmentos, cómo dimensionar tus fragmentos, asignación y recuperación de fragmentos.

Este tema también está disponible como curso introductorio en el canal de YouTube de Elastic Community.

Por último, pero no menos importante: si no quieres preocuparte por nodos, fragmentos o réplicas, puedes probar Elastic Cloud Serverless. Esta oferta de Elastic Cloud está completamente gestionada por Elastic y automatizada para escalar con tu carga de trabajo. Una prueba gratis puede ayudarte a familiarizarte con otros beneficios del enfoque sin servidor.