1. Uso de la API_mapping para recuperar información de campo

2. Uso de la API_search para mostrar los valores de los campos

3. Filtrado de campos usando el parámetrofields

4. Visualización de campos anidados

1. Uso de la API _mapping para recuperar información de campo

La API _mapping permite recuperar la definición de mapeo para un índice o varios índices. Esto incluye información sobre los campos, sus tipos de datos y otras propiedades. Para recuperar el mapeo de un índice específico, emplee la siguiente petición:

Por ejemplo, si tienes un índice llamado my_index, puedes recuperar su mapeo con la siguiente petición:

La respuesta incluirá la definición de mapeo para el índice, que contiene información sobre los campos y sus propiedades.

También es posible recuperar el mapeo de un campo específico. Esto puede ser útil si tu mapeo es bastante grande y solo quieres centrarte en un campo específico. Para recuperar el mapeo de un campo específico, emplee la siguiente petición:

También puedes recuperar los mapeos de varios campos separando sus nombres con comas, como en la siguiente petición:

2. Uso de la API _search para mostrar los valores de los campos

Para mostrar los valores de los campos en un índice de Elasticsearch, puedes usar la API _search . Por defecto, la API _search devuelve el campo _source , que contiene el documento JSON original que se indexó. Para mostrar solo campos específicos, puedes usar el parámetro _source en la solicitud de búsqueda.

Aquí tienes un ejemplo de una solicitud de búsqueda que devuelve los valores de los campos title y author para documentos en el índice my_index :

En este ejemplo, el parámetro _source especifica los campos que se deben devolver.

3. Filtrado de campos usando el parámetro de campos

También puedes usar el parámetro fields para filtrar los campos que aparecen en la respuesta de búsqueda. Esto puede ser útil si solo necesitas campos específicos y quieres reducir el tamaño de la respuesta. El parámetro fields acepta una matriz de nombres de campos o patrones comodines.

Por ejemplo, para devolver solo los campos title y author de los documentos en el índice de my_index , puedes usar la siguiente solicitud de búsqueda:

Ten en cuenta que el parámetro _source está configurado como falso para no devolver el documento fuente.

Para devolver todos los campos con un text tipo de dato, puedes usar un patrón comodín como este:

4. Visualización de campos anidados

Si tu índice contiene campos anidados, puedes usar la notación de puntos para especificar el camino de campo anidado en el parámetro fields . Por ejemplo, si tienes un campo anidado llamado address.city, puedes incluirlo en la respuesta de búsqueda así:

En este ejemplo, la respuesta de búsqueda incluirá los valores de los campos title, author address.city .

Conclusión

En conclusión, se puede lograr mostrar campos en un índice de Elasticsearch empleando la API _mapping para recuperar información de campos y la API _search para mostrar los valores de campo. Puedes filtrar los campos que aparecen en la respuesta de búsqueda usando los parámetros de _source o fields y mostrar los campos anidados usando la notación de puntos. Estas técnicas pueden ayudarte a entender la estructura de tus datos, identificar campos específicos y solucionar problemas.

Antecedentes sobre las marcas de agua

Hay varios umbrales de "marca de agua" en tu clúster de Elasticsearch que te ayudan a rastrear el espacio disponible en disco. A medida que el disco se llena en un nodo, el primer umbral que se cruzará será la "marca de agua de disco bajo". El segundo umbral será entonces el "umbral alto de marca de agua en disco". Finalmente, se alcanzará la "fase de inundación de disco". Una vez superado este umbral, el clúster bloqueará la escritura en TODOS los índices que tengan un fragmento (primario o réplica) en el nodo que pasó la marca de agua. Las lecturas (búsquedas) seguirán siendo posibles.

Cómo prevenir y manejar casos cuando el disco está demasiado lleno (sobreutilización)

Existen varios métodos para gestionar casos cuando tu disco de Elasticsearch está demasiado lleno:

1. Eliminar datos antiguos: Normalmente, los datos no deben conservar indefinidamente. Una forma de evitar y solucionar que el disco esté demasiado lleno es cerciorar de que, cuando los datos alcancen cierta edad, se archiven y eliminen de forma fiable. Una forma de hacerlo es usando ILM.

2. Agregar capacidad de almacenamiento: Si no puedes eliminar los datos, quizá quieras agregar más nodos de datos o aumentar el tamaño de los discos para conservar todos los datos sin afectar negativamente al rendimiento. Si necesitas agregar capacidad de almacenamiento al clúster, deberías considerar si necesitas agregar solo capacidad de almacenamiento, o tanto capacidad de almacenamiento como RAM y recursos de CPU en proporción (ver la sección sobre la proporción entre tamaño de disco, RAM y CPU más abajo).

Cómo agregar capacidad de almacenamiento a tu clúster de Elasticsearch

1. Aumentar el número de nodos de datos: Recuerda que los nuevos nodos deben tener el mismo tamaño que los nodos existentes y la misma versión de Elasticsearch.

2. Aumentar el tamaño de los nodos existentes: En entornos basados en la nube, suele ser fácil aumentar el tamaño del disco y la RAM/CPU en los nodos existentes.

3. Aumenta solo el tamaño del disco: En entornos basados en la nube, a menudo es relativamente fácil aumentar el tamaño del disco.

4. Instantánea y restauración: Si estás dispuesto a permitir que se recuperen datos antiguos a petición en un proceso automatizado desde copias de seguridad, puedes hacer instantáneas de índices antiguos, eliminarlos y restaurar datos temporalmente a petición de las instantáneas. 

5. Reducir réplicas por fragmento: Otra opción para reducir los datos es reducir el número de réplicas de cada fragmento. Para alta disponibilidad, te gustaría tener una réplica por fragmento, pero cuando los datos envejecen, podrías trabajar sin réplicas. Esto normalmente podría funcionar si los datos son persistentes o si tienes una copia de seguridad que restaurar si es necesario.

6. Crea alertas: Para evitar que los discos se llenen en el futuro y actuar de forma proactiva, deberías crear alertas basadas en el uso del disco que te avisen cuando el disco empiece a llenar. 

Cómo prevenir y gestionar casos en los que la capacidad del disco está infrautilizada

Si la capacidad de tu disco está infrautilizada, existen varias opciones para reducir el volumen de almacenamiento en tu clúster.

Cómo reducir el volumen de almacenamiento en un clúster de Elasticsearch

Existen varios métodos para reducir el volumen de almacenamiento de un clúster.

1. Reducir el número de nodos de datos

Si quieres reducir el almacenamiento de datos y también reducir los recursos de RAM y CPU en la misma proporción, esta es la estrategia más sencilla. Desmantelar nodos innecesarios probablemente suponga el mayor ahorro de costos.

Antes de desactivar el nodo, deberías:

• Cerciorar de que el nodo a desmantelar no sea necesario como nodo MAESTRO. Siempre deberías tener al menos tres nodos con el rol de nodo MAESTRO.

• Migra los fragmentos de datos fuera del nodo para ser desmantelados.

2. Sustituir nodos existentes por nodos más pequeños

Si no puedes reducir aún más el número de nodos (normalmente 3 sería una configuración mínima), entonces quizá quieras reducir el tamaño de los nodos existentes. Recuerda que es recomendable cerciorar de que todos los nodos de datos tengan la misma memoria RAM y tamaño de disco, ya que los fragmentos se equilibran en función del número de fragmentos por nodo.

El proceso sería:

• Agregar nuevos nodos más pequeños al clúster

• Migra los fragmentos lejos de los nodos para ser desmantelados

• Apaga los nodos antiguos

3. Reducir el tamaño del disco en los nodos

Si SOLO quieres reducir el tamaño del disco en los nodos sin cambiar la RAM o la CPU total del clúster, entonces puedes reducir el tamaño del disco para cada nodo. Reducir el tamaño del disco en un nodo Elasticsearch no es un proceso trivial.

La forma más sencilla de hacerlo suele ser:

• Migrar fragmentos desde el nodo

• Detener el nodo

• Montar un nuevo volumen de datos en el nodo con el tamaño adecuado

• Copiar todos los datos del volumen de disco antiguo al volumen nuevo

• Desacoplar el antiguo volumen A

• Nodo inicial y migra fragmentos de vuelta a nodo

Esto requiere que tengas suficiente capacidad en los otros nodos para almacenar temporalmente los fragmentos extra del nodo durante este proceso. En muchos casos, el costo de gestionar este proceso puede superar los posibles ahorros en el uso del disco. Por esta razón, puede ser más sencillo reemplazar el nodo por completo por uno nuevo con el tamaño de disco deseado (ver "Sustituir nodos existentes por nodos más pequeños" arriba).

Al pagar por recursos innecesarios, el costo obviamente puede reducir optimizando la utilización de los recursos.

La relación entre el tamaño del disco, la RAM y la CPU

La proporción ideal de capacidad de disco respecto a RAM en tu clúster dependerá de tu caso de uso particular. Por esta razón, al considerar cambios en tu capacidad de almacenamiento, también deberías considerar si las relaciones actuales de disco/RAM/CPU están adecuadamente equilibradas y si, como consecuencia, necesitas agregar o reducir RAM y CPU en la misma proporción.

Los requisitos de RAM y CPU dependen del volumen de actividad de indexación , el número y tipo de consultas, y también de la cantidad de datos que se están buscando y agregando. Esto suele ser proporcional a la cantidad de datos almacenados en el clúster y, por tanto, también debe estar relacionado con el tamaño del disco.

La proporción entre la capacidad del disco y la RAM puede cambiar según el caso de uso. Consulta algunos ejemplos aquí:

Actividad en el índice

Retención

Actividad de búsqueda

Capacidad del disco

CARNERO

Aplicación de búsqueda empresarial

Ingestión moderada de logarítmic

Largo

Luz

2TB

32GB

Monitorización de aplicaciones

Ingesta intensiva de troncos

Corto

Luz

1TB

32GB

Comercio electrónico

Indexación de datos de luz

Indefinido

Pesado

500GB

32GB

Recuerda que modificar la configuración de las máquinas de nodos debe hacer con cuidado, ya que puede implicar tiempo de inactividad de nodos y debes cerciorarte de que los fragmentos no empiecen a migrar a otros nodos ya sobreextendidos.

El papel de las réplicas en Elasticsearch

En Elasticsearch, un índice es una colección de documentos que se dividen en múltiples fragmentos primarios. Cada fragmento primario es un índice Apache Lucene autosuficiente, y los documentos dentro de un índice se distribuyen entre todos los fragmentos primarios. Para garantizar una alta disponibilidad y redundancia de datos, Elasticsearch permite que cada fragmento tenga una o más copias, conocidas como réplicas. La configuración number_of_replicas controla el número de fragmentos réplica (copias) que Elasticsearch crea para cada fragmento principal en un índice. Por defecto, Elasticsearch crea una réplica para cada shard primario, pero esto puede cambiar según los requisitos de tu sistema.

Configuración de la number_of_replicas

La configuración de number_of_replicas puede configurar en el momento de la creación del índice o actualizar más adelante. Así es como puedes configurarlo durante la creación del índice:

En este ejemplo, Elasticsearch creará dos réplicas para cada fragmento primario en el índice de my_index .

Para actualizar la configuración de number_of_replicas de un índice existente, puedes usar la API _settings :

Este comando actualizará el índice de my_index para tener tres réplicas por cada fragmento primario.

Participaciones del entorno number_of_replicas

La configuración number_of_replicas tiene un impacto significativo en el rendimiento y la resiliencia de tu clúster de Elasticsearch. Aquí tienes algunos puntos clave a tener en cuenta:

1. Redundancia y disponibilidad de datos: Aumentar la number_of_replicas mejora la disponibilidad de tus datos creando más copias de cada fragmento. Si un nodo falla, Elasticsearch aún puede servir datos de los fragmentos réplica en los nodos restantes.

2. Rendimiento en la búsqueda: Los fragmentos réplica pueden atender solicitudes de lectura, por lo que tener más réplicas puede mejorar el rendimiento de búsqueda al distribuir la carga entre más fragmentos.

3. Escribe la interpretación: Sin embargo, cada operación de escritura debe realizar en cada copia de un fragmento. Por lo tanto, un number_of_replicas mayor puede ralentizar el rendimiento de la indexación , ya que aumenta el número de operaciones que deben realizar por cada escritura.

4. Requisitos de almacenamiento: Más réplicas significan más espacio de almacenamiento. Debes cerciorarte de que tu clúster tenga suficiente capacidad para almacenar las réplicas adicionales.

5. Resiliencia ante el fallo de nodos: El number_of_replicas debería establecer teniendo en cuenta el número de nodos en tu clúster. Si el number_of_replicas es igual o mayor que el número de nodos, tu clúster puede tolerar el fallo de varios nodos sin pérdida de datos.

Mejores prácticas para establecer number_of_replicas

La configuración óptima de number_of_replicas depende de los requisitos específicos de tu sistema. Sin embargo, aquí tienes algunas buenas prácticas generales:

• Para un clúster de un solo nodo, number_of_replicas debe estar en 0, ya que no hay otros nodos que almacenen réplicas.

• Para un clúster multinodo, number_of_replicas debe estar configurado al menos en 1 para garantizar redundancia de datos y alta disponibilidad.

• Si el rendimiento en las búsquedas es una prioridad, considera aumentar la number_of_replicas. Sin embargo, ten en cuenta el equilibrio entre el rendimiento de escritura y los requisitos de almacenamiento.

• Cerciórate siempre de que tu clúster tenga suficiente capacidad para almacenar las réplicas adicionales.

En este artículo, hablaremos de las razones por las que excluye campos de la indexación, cómo configurar Elasticsearch para excluir campos específicos y algunas buenas prácticas a seguir al hacerlo.

Razones para excluir campos de la indexación

1. Rendimiento: Indexar todos los campos de un documento puede aumentar el tiempo de indexación y ralentizar el rendimiento de búsqueda. Excluyendo campos que no son necesarios para búsqueda o agregación, puedes mejorar el rendimiento general de tu clúster de Elasticsearch.

2. Almacenamiento: Los campos de indexación consumen espacio de almacenamiento. Excluir campos que no son necesarios para búsqueda o agregación puede ayudar a reducir los requisitos de almacenamiento de tu clúster de Elasticsearch.

3. Tamaño del índice: El tamaño de un índice de Elasticsearch está directamente relacionado con el número de campos indexados. Al excluir campos innecesarios, puedes minimizar el tamaño de tu índice, lo que puede llevar a un rendimiento de búsqueda e indexación más rápido.

Configuración de Elasticsearch para excluir campos

Para excluir un campo de la indexación en Elasticsearch, puedes usar la propiedad "index" en el mapeo del campo. Al poner la propiedad "index" en "false", Elasticsearch no indexará el campo, y no será buscable ni estará disponible para agregaciones.

Aquí tienes un ejemplo de cómo excluir un campo de la indexación usando el mapeo Elasticsearch:

En este ejemplo, estamos creando un nuevo índice llamado "my_index" con un solo campo llamado "field_to_exclude". Al poner la propiedad "index" en "false", le decimos a Elasticsearch que no indexe este campo. Sin embargo, el campo seguirá estando disponible en el documento fuente.

Mejores prácticas para excluir campos de la indexación

1. Analiza tus datos: Antes de excluir campos de la indexación, es esencial analizar tus datos y entender qué campos son necesarios para la búsqueda y agregación. Esto te ayudará a tomar decisiones informadas sobre qué campos excluir.

2. Prueba tus cambios: Al excluir campos de la indexación, es fundamental probar tus cambios para cerciorarte de que la funcionalidad de búsqueda y agregación sigue funcionando como se espera. Esto puede ayudarte a evitar problemas inesperados o de rendimiento.

3. Rendimiento del monitor: Luego de excluir campos de la indexación, monitoriza el rendimiento de tu clúster de Elasticsearch para cerciorarte de que los cambios tuvieron el efecto deseado. Esto puede ayudarte a identificar posibles optimizaciones adicionales que puedan ser necesarias.

4. Emplea filtrado de fuente: Si necesitas almacenar un campo en Elasticsearch pero no quieres que sea buscable ni disponible para agregaciones, considera usar filtrado de fuente. Esto te permite almacenar el campo en el campo _source pero excluirlo del índice.

Conclusión

Excluir campos de la indexación en Elasticsearch puede ayudar a mejorar el rendimiento, reducir los costos de almacenamiento y minimizar el tamaño total de tu índice. Analizando cuidadosamente tus datos y entendiendo qué campos son necesarios para la búsqueda y agregación, puedes tomar decisiones informadas sobre cuáles excluir. Prueba siempre tus cambios y monitoriza el rendimiento de tu clúster de Elasticsearch para cerciorarte de que tus optimizaciones tienen el efecto deseado.

Método 1: Uso de la API de actualización

La API de actualización te permite actualizar un documento mediante un script que modifica el código fuente del documento. Puedes usar esta API para eliminar un campo de un documento al configurarlo como nulo. Aquí tienes una guía paso a paso sobre cómo hacerlo:

1. Identifica el índice, el tipo de documento (si se emplea Elasticsearch 6.x o anterior) y el ID del documento que se desea actualizar.

2. Usar la API Update con un script que ponga el campo en null, o mejor aún, que lo elimine del documento fuente. El siguiente ejemplo demuestra cómo eliminar el campo "field_to_delete" de un documento con ID "1" en el índice "my_index":

3. Ejecutar la solicitud. Si tiene éxito, Elasticsearch devolverá una respuesta indicando que el documento fue actualizado.

Nota: Este método solo elimina el campo del documento especificado. El campo seguirá existiendo en el mapeo y en otros documentos del índice.

Método 2: Reindexación con una fuente modificada

Si deseas eliminar un campo de todos los documentos de una indexación, puedes usar la API de reindexación para crear una indexación nueva con la fuente modificada. Aquí te explicamos cómo hacerlo:

1. Crear un nuevo índice con los mismos ajustes y asignaciones que el índice original. Puedes usar la API Get Index para recuperar la configuración y mapeo del índice original.

2. Emplear la API Reindex para copiar documentos del índice original al nuevo índice, eliminando el campo del código fuente. El siguiente ejemplo demuestra cómo eliminar el campo "field_to_delete" de todos los documentos en el índice "my_index":

3. Verificar que el nuevo índice contiene los documentos correctos con el campo eliminado.

4. Si todo parece bien, puedes eliminar el índice original y, si es necesario, agregar un alias al nuevo índice con el nombre del índice original.

Método 3: Actualización del mapping y la reindexación

Si quieres eliminar un campo del mapeo y todos los documentos de un índice, puedes actualizar el mapeo y luego volver a indexar los documentos. Así es como se hace:

1. Crear un nuevo índice con la misma configuración que el índice original.

2. Recuperar los mapeos del índice original usando la API Get Mapping.

3. Modifica los mapeos eliminando el campo que quieres eliminar.

4. Aplicar los mapeos modificados al nuevo índice usando la API de Put Maping.

5. Emplear la API Reindex para copiar documentos del índice original al nuevo índice, como se describe en el Método 2.

6. Verificar que el nuevo índice contiene los documentos correctos sin eliminar el campo y que el campo no esté presente en el mapeo.

7. Si todo se ve bien, puedes eliminar la indexación original y, si es necesario, agregar un alias a la indexación nueva con el nombre de la original.

Conclusión

En este artículo, discutimos tres métodos para eliminar un campo de un documento en Elasticsearch: usar la API Update, reindexar con un código fuente modificado y actualizar el mapeo y el reindexado. Cada método tiene sus propios casos de uso y compromisos, así que elige el que mejor se adapte a tus necesidades. Recuerda siempre probar tus cambios y verificar los resultados antes de aplicarlos a entornos de producción.

Mecanismos de puntaje en Elasticsearch

Elasticsearch emplea por defecto un modelo de puntaje llamado Practical Scoring Function (BM25). Este modelo se basa en la teoría probabilística de recuperación de información y tiene en cuenta factores como la frecuencia de términos, la frecuencia inversa de documentos y la normalización longitud-campo. Hablemos brevemente de estos factores:

1. Frecuencia de término (TF): Esto representa el número de veces que un término aparece en un documento. Una mayor frecuencia de término indica una relación más fuerte entre el término y el documento.

2. Frecuencia inversa del documento (IDF): Este factor mide la importancia de un término en toda la colección documental. Un término que aparece en muchos documentos se considera menos importante, mientras que un término que aparece en menos documentos se considera más importante.

3. Normalización de longitud de campo: Este factor tiene en cuenta la longitud del campo en el que aparece el término. Los campos más cortos tienen más peso, ya que el término se considera más significativo en un campo más corto.

Usando la API Explain

La API Explain en Elasticsearch es una herramienta valiosa para entender el proceso de puntaje. Proporciona una explicación detallada de cómo se calculó el puntaje de un documento específico. Para usar la API Explic, necesitas enviar una solicitud GET al siguiente endpoint:

En el cuerpo de la solicitud, debes proporcionar la consulta para la que quieres entender el puntaje. Aquí tienes un ejemplo:

La respuesta de la API Explain incluirá un desglose detallado del proceso de puntaje, incluyendo los factores individuales (TF, IDF y la normalización de la longitud del campo) y sus contribuciones al puntaje final. Aquí tienes una respuesta de ejemplo:

En este ejemplo, la respuesta muestra que el puntaje de 1,2 es un producto del valor IDF (2,2) y el valor tfNorm (0,5). La explicación detallada ayuda a entender los factores que contribuyen al puntaje y puede ser útil para afinar la relevancia en la búsqueda.

Conclusión

El puntaje de elasticsearch es un aspecto fundamental para proporcionar resultados de búsqueda relevantes. Al comprender los mecanismos de puntaje y emplear la API Explice, puedes obtener información sobre los factores que afectan a los resultados de búsqueda y optimizar tus consultas para mejorar la relevancia y el rendimiento.

• Las definiciones de mapeo especifican el esquema de datos.

• Los ajustes ajustan el tamaño del fragmento y las frecuencias de refresco. 

• Se emplean alias para dar nombres alternativos al índice.

Cuando indexamos un documento por primera vez o creamos un índice vacío usando la API Create Index, el índice se creará con la configuración predeterminada, sin esquema de datos y sin alias. Estos valores por defecto funcionan bastante bien en entornos de desarrollo y pruebas, pero puede que necesitemos personalizar nuestros índices para entornos de producción.

Trabajar con los mapeos y ajustes predeterminados en producción puede resultar en un índice y un rendimiento de búsqueda deficientes. Instanciar índices manualmente es un proceso tedioso y que consume mucho tiempo. Recrear tales índices en cualquier entorno es especialmente poco práctico si disponemos de un esquema de mapeo elaborado, así como de configuraciones y alias personalizados.

Por suerte, Elasticsearch nos proporciona una herramienta para aplicar automáticamente una configuración predefinida al crear índices en forma de plantillas de índices .

Plantillas de índice

Las plantillas de índice nos permiten crear índices con una configuración definida por el usuario. Un índice puede extraer la configuración de estas plantillas, por ejemplo un número determinado de fragmentos y réplicas o mapeos de campos, durante su instanciación. Se definirá una plantilla con un patrón de nombre y alguna configuración en él. Si el nombre del índice coincide con el patrón de nombres de la plantilla, el nuevo índice se creará con la configuración definida en la plantilla.

Elasticsearch mejoró su funcionalidad de plantillas en la versión 7.8 con plantillas componibles. Esta versión más reciente ofrece plantillas de índice mucho más reutilizables, como se demuestra en este artículo.

Tipos de plantillas de indexación

Las plantillas de índice pueden clasificar en dos categorías:

• Plantillas de índice (o plantillas de índice composable): Las plantillas de índice componibles pueden existir por sí solas o estar compuestas por no tener o más plantillas componentes (ver la segunda categoría).

• Plantillas de componentes: La plantilla de componentes es una plantilla reutilizable por sí sola que define la configuración requerida. Normalmente se espera que la plantilla de componentes esté asociada a una plantilla de índice. Cada una de las plantillas de componentes puede anexar con una o varias plantillas de índice. 

Como puedes ver en la imagen de abajo, las plantillas índice A y B comparten entre sí las plantillas de componentes (en este caso solo una, la Plantilla 3). Una plantilla de índice puede consistir en ninguna o muchas plantillas de componentes y cada una de las plantillas de componentes puede asociar a ninguna o a muchas plantillas de índice. Ambos tipos de plantillas pueden existir por separado, sin embargo, las plantillas de componentes no sirven a menos que estén adjuntas a una plantilla de índice.

La idea general es desarrollar un catálogo de plantillas de componentes para que una organización las emplee para diversas necesidades (por ejemplo, especificar las distintas plantillas de componentes para entornos individuales) y anexarlas a varios índices mediante las plantillas de índices componibles.

Cómo crear plantillas componibles (indexadas)

Elasticsearch proporciona un punto final _index_template para gestionar plantillas de índice. El usuario proporciona todos los mapeos, ajustes y alias necesarios junto con un patrón de nombres de índice en esta plantilla. Vamos a repasar un ejemplo de cómo crear una plantilla para una aplicación de microservicios client-order-service que es responsable de la lógica de generación de pedidos. 

Supongamos que nuestro requisito es crear una plantilla para pedidos de clientes, representada con un patrón que incluye comodines: *pedidos. Se espera que esta plantilla tenga ciertos mapeos y configuraciones, como el campo order_date, así como fragmentos y números de réplica.

Cualquier índice que se empareje con esta plantilla durante su creación hereda las configuraciones definidas en esta plantilla. Por ejemplo, un índice de black_friday_orders tendrá el campo order_date, los fragmentos se pondrán en 5 y las réplicas en 2. Además, todos los índices creados a partir de esta plantilla heredan también un único nombre de alias . Creemos este orders_template con un patrón de índice definido como *orders y con un esquema de mapeo que consiste en un solo campo de oder_date con un formato de fecha predefinido dd-MM-yyyy. El código que aparece a continuación muestra cómo crear esta plantilla de índice.

Cuando ejecutas esta consulta en DevTools de Kibana, la plantilla se crea con el patrón índice *orders junto con el mapeo predefinido, los ajustes y un alias. El index_patterns es una variedad de patrones de coincidencia; cualquier índice que coincida con este patrón derivará la configuración de la plantilla. Puedes ejecutar lo siguiente para recuperar la plantilla persistente que debería reiterar lo que hicimos:

También hay una prioridad, un número positivo, definido al crear el atributo de plantilla definido en la plantilla: cada plantilla se define con una prioridad para que cualquier cambio conflictivo de diferentes plantillas se resuelva usando este valor con precedencia dada al valor de mayor prioridad. A continuación profundizaremos en la prioridad de las plantillas.

Crear un índice con la plantilla

Ahora que tenemos una plantilla – un plano para crear índices – el siguiente paso es crear un índice. Cuando el nombre del índice coincide con el patrón dado, las configuraciones con plantilla se aplican automáticamente. Para demostrar el punto, como muestra el código de abajo, creemos un índice completamente nuevo llamado: blackfriday_orders:

Como el nombre del índice (blackfriday_orders) coincide con el patrón de nombres definido en la plantilla (es decir, *órdenes), el índice debería obtener todas las configuraciones derivadas de la plantilla. Recuperemos este índice recién creado y compruebemos si esto es realmente cierto ejecutando el siguiente código:

Esto debería volver:

Como indica la respuesta, la configuración del blackfriday_orders fue heredada de la plantilla. Podemos probar con varias combinaciones de los índices que hereden con éxito la configuración plantillada:

Sin embargo, los siguientes índices no heredarán la configuración ya que el nombre no coincidirá con el patrón:

Algo importante a recordar es que todos los índices derivados de una plantilla tienen el mismo alias – all_orders – en este caso. Existe un beneficio en tener este alias: podemos consultar simplemente con este único alias en lugar de en múltiples índices.

Aunque creamos una plantilla para *pedidos, se espera que cualquier índice coincidente adopte la configuración de la plantilla. Normalmente, consciente o inconscientemente, los equipos pueden crear algunas plantillas más por diversas razones. Esto significa que a veces el nombre del índice puede coincidir con dos patrones de plantilla diferentes. Elasticsearch tiene que decidir cuál de las configuraciones de esas plantillas debe aplicar. Afortunadamente, este dilema puede resolver usando la prioridad de la plantilla.

Cómo crear plantillas de componentes

Aprendimos sobre las plantillas de índice en la parte anterior de este artículo. Hay un par de desventajas al crear las plantillas con la configuración incorporada; una de ellas es que la configuración no es exportable para otras plantillas. Si queremos tener una configuración similar, por ejemplo para plantillas relacionadas con clientes (*clientes), puede que tengamos que recrear toda la plantilla. Eso significa que podemos estar creando docenas de ellos en una organización típica (además puede que tengas algunos más según los entornos).

Como siempre esperamos la reutilización, Elasticsearch rediseñó las plantillas teniendo en cuenta la reutilización. Las plantillas de componentes cumplen con ese requisito. Si vienes de un entorno DevOps, lo más probable es que tengas que crear índices con una configuración preestablecida para cada uno de los entornos. En lugar de aplicar manualmente cada una de estas configuraciones, puedes crear una plantilla de componentes para cada uno de los entornos.

Una plantilla de componentes no es más que un bloque reutilizable de configuraciones que podemos usar para crear más plantillas de índice. Ten en cuenta que las plantillas de componentes no tienen valor a menos que estén agrupadas con plantillas de índice. Se exponen a través de un punto final _component_template. Veamos cómo encaja todo esto.

Configuraciones en una plantilla de índice

Vamos a extraer los ajustes que definimos en nuestra plantilla de índice antes y crear una plantilla de componente a partir de ella. Se espera que el settings_component_template tenga cinco fragmentos principales con dos réplicas por fragmento principal. El primer paso, como muestra la lista de código a continuación, es declarar y ejecutar una plantilla de componente con esta configuración.

Como muestra el código anterior, usamos el punto final _component_template para crear una plantilla de componentes. El cuerpo de la solicitud contiene la información de la plantilla en un objeto plantilla. El settings_component_template ya está disponible para su uso en otras partes de las plantillas del índice. Una diferencia notable es que esta plantilla no define ningún patrón de índice; Simplemente es un bloque de código que configura algunas propiedades para nosotros.

Plantilla de mapeo

De la misma manera, creemos otra plantilla. Esta vez, extraigamos el esquema de mapeo que definimos antes en las plantillas de índice independientes. El código siguiente muestra el guion:

Plantilla de alias

Siguiendo el mismo flujo, también podemos tener una plantilla de componentes con los alias – dos alias (all_orders y sales_orders):

Plantilla de índice componible

Ahora que tenemos estas tres plantillas de componentes, el siguiente paso es ponerlas en práctica. Podemos hacerlo dejando que una plantilla de índice para, por ejemplo, christmas_orders, la emplee:

La etiqueta composed_of es una colección de todas las plantillas de componentes que conforman esta plantilla. En este caso, elegimos las plantillas de componentes de configuración, mapeo y alias. También estamos subiendo la prioridad, así que esta plantilla supera a cualquier otra. Una vez que la plantilla está lista, cualquier índice que coincida con el patrón *orders heredará la configuración de estas tres plantillas componentes.

Dicho esto, si deseamos crear una nueva plantilla, por ejemplo clientes, con solo una de las plantillas existentes (settings_component_template) y una nueva (aliases_component_template – ver más abajo), podemos hacerlo con:

La plantilla del índice es la siguiente:

¿Viste que el settings_component_template se ha (re)empleado en dos plantillas diferentes? Ese es el poder de las plantillas de componentes.

Prioridad de la plantilla de indexación

Existe la posibilidad de que los desarrolladores creen múltiples plantillas de índice sin mirar el stock existente. Es importante establecer una prioridad en cada una de estas plantillas para que se emplee la de mayor prioridad. Por ejemplo, el my_orders_template_1 anula la my_orders_template_2 en el siguiente fragmento de código:

Cuando tienes varias plantillas que coinciden con los índices que se están creando, Elasticsearch aplica todas las configuraciones de todas las plantillas coincidentes pero anula cualquier cosa que tenga mayor prioridad.

Precedencia de plantillas

Por último, puede que te preguntes por la precedencia de las plantillas: ¿la configuración definida en la plantilla de componentes anula la que aparece en la plantilla principal del índice? ¿O al revés? Bueno, hay algunas reglas:

• Un índice creado con configuraciones tiene prioridad explícita sobre todo; esto significa que si creas un índice con configuración explícita, no esperes que las plantillas las sobreescriban.

• Las plantillas heredadas (plantillas creadas antes de la versión 7.8) tienen una prioridad inferior a las plantillas componibles.

Resumen

• Un índice contiene mapeos, configuraciones y alias: los mapeos definen el esquema de campos, los ajustes establecen los parámetros del índice como el número de fragmentos y réplicas, y los alias dan nombres alternativos al índice.

• Las plantillas nos permiten crear índices con configuraciones predefinidas. Nombrar un índice con un nombre que coincida con el patrón de índice definido en una plantilla específica configurará automáticamente ese índice según la plantilla.

• Elasticsearch introdujo plantillas de índice componibles en la versión 7.8. Las plantillas de índice componibles permiten modularidad y versionado de las plantillas.

• Las plantillas componibles consisten en no tener o más plantillas de componentes.

• Una plantilla de índice también puede tener su propia configuración definida.

• Una plantilla de componente es una plantilla reutilizable con configuración predefinida, igual que una plantilla de índice componible.

• Sin embargo, se espera que las plantillas de componentes formen parte de una plantilla de índice; No sirven de nada si no están "compuestas" en una plantilla de índice.

• Las plantillas de componentes no tienen un patrón de índice definido, lo que es otra razón por la que se "espera" que formen parte de una plantilla de índice.

• Cada una de las plantillas tiene una prioridad: un número positivo. Cuanto mayor sea el número, mayor es la precedencia para que se aplique esa plantilla.

Técnicas avanzadas para realizar búsquedas en dos campos

1. Consulta multi-coincidencia

Una consulta multi-coincidencia te permite buscar una sola cadena de consulta en varios campos. Esto es útil cuando quieres encontrar documentos que contengan la cadena de consulta dada en cualquiera de los dos campos. Aquí tienes un ejemplo de consulta multi-coincidencia que busca el término "ejemplo" en los campos "título" o "descripción":

2. Consulta de bool

Una consulta bool permite combinar varias consultas usando lógica booleana. Puedes usar la cláusula "debería" para buscar documentos que coincidan con la consulta en cualquiera de los dos campos. Aquí tienes un ejemplo de consulta bool que busca el término "ejemplo" en los campos "título" y "descripción":

3. Aumento de campos en tiempo de consulta

A veces, puede que quieras dar más importancia a un campo que a otro durante la búsqueda. Puedes conseguirlo aplicando un factor de mejora al campo en el momento de la consulta. Un valor de aumento más alto da más peso al campo, haciendo que sea más probable que influya en el puntaje final de búsqueda. Aquí tienes un ejemplo de consulta multi-coincidencia con un factor de impulso aplicado al campo "título":

En este ejemplo, el campo "título" tiene un factor de mejora de 3, lo que lo hace tres veces más importante que el campo "descripción" para determinar el puntaje de búsqueda.

4. Combinar consultas con diferentes factores de impulso

También puedes combinar varias consultas con diferentes factores de boost usando una consulta bool. Esto te permite afinar la importancia de cada campo en los resultados de búsqueda. Aquí tienes un ejemplo de consulta bool con diferentes factores de boost aplicados a los campos "título" y "descripción":

En este ejemplo, el campo "título" tiene un factor de mejora de 3, mientras que el campo de "descripción" tiene un factor de aumento de 1.

Conclusión

La búsqueda mediante dos campos en Elasticsearch se puede lograr mediante técnicas avanzadas como consultas multi-coincidencia, consultas bool y aumento de campos en tiempo de consulta. Combinando estas técnicas, puedes crear resultados de búsqueda más precisos y relevantes para tus usuarios. Experimenta con diferentes combinaciones de consultas y factores de mejora para encontrar la configuración óptima de búsqueda para tu caso de uso específico.

A partir de la versión 7.11, Elasticsearch por defecto establece automáticamente el tamaño del montón de la JVM en función de los roles y la memoria total de un nodo. Se recomienda usar el tamaño por defecto para la mayoría de entornos de producción. Sin embargo, si quieres configurar manualmente el tamaño del montón de tu JVM, como regla general deberías poner -Xms y -Xmx al MISMO valor, que debería ser el 50% de tu RAM disponible total, sujeto a un máximo (aproximadamente) 31GB.

Un tamaño de heap mayor le dará a tu nodo más memoria para las operaciones de indexación y búsqueda. Sin embargo, tu nodo también requiere memoria para la caché, así que usar el 50% mantiene un equilibrio saludable entre ambos. Por esta misma razón, en producción deberías evitar usar otros procesos que consumen mucho memoria en el mismo nodo que Elasticsearch.

Normalmente, el uso del montón sigue un patrón de dientes de sierra, oscilando entre alrededor del 30 y el 70% del montón máximo empleado. Esto se debe a que la JVM aumenta de forma constante el porcentaje de uso del montón hasta que el proceso de recogida de basura libera memoria de nuevo. El alto uso del montón ocurre cuando el proceso de recogida de basura no puede seguir el ritmo. Un indicador de un alto uso del montón es cuando la recolección de basura no es capaz de reducir el uso del montón a alrededor del 30%.

En la imagen de arriba, puedes ver un diente de sierra normal del montón de JVM.

También verás que hay dos tipos de recogida de basura: GC joven y vieja.

En una JVM saludable, la recogida de basura debería cumplir idealmente las siguientes condiciones:

• El GC joven se procesa rápidamente (en menos de 50 ms).

• La GC joven no se ejecuta con frecuencia (unos 10 segundos).

• El GC antiguo se procesa rápidamente (en menos de 1 segundo).

• El GC antiguo no se ejecuta con frecuencia (una vez cada 10 minutos o más).

Cómo resolver cuando el uso de memoria del heap es demasiado alto o cuando el rendimiento de la JVM no es óptimo

Puede haber varias razones por las que el uso de memoria heap puede aumentar:

Fragmentación de fragmentos

Por favor, consulta el documento sobre sobrefragmentación aquí.

Grandes tamaños de agregación

Para evitar grandes tamaños de agregación, mantén al mínimo el número de cubos de agregación (tamaño) en tus consultas.

Puedes usar el registro lento de consultas (registros lentos) e implementarlo en un índice específico usando lo siguiente.

Las consultas que tardan mucho en devolver los resultados suelen ser las que requieren muchos recursos.

Tamaño excesivo del índice de volumen

Si envías peticiones grandes, esto puede ser una causa de un alto consumo de heaps. Prueba a reducir el tamaño de las solicitudes de índice masivo.

Problemas de cartografía

En individuo, si usas "fielddata: true", entonces puede ser un usuario importante de tu montón JVM.

Tamaño del montón incorrectamente configurado

El tamaño del heap puede definir manualmente por:

Establecer la variable de entorno:

Editar el archivo jvm.options en tu directorio de configuración de Elasticsearch:

La configuración de la variable ambiental tiene prioridad sobre la configuración de archivo.

Es necesario resetear el nodo para tener en cuenta la configuración.

Nuevo ratio de JVM configurado incorrectamente

Generalmente NO es necesario establecer esto, ya que Elasticsearch establece este valor por defecto. Este parámetro define la proporción de espacio disponible para objetos de "nueva generación" y "generación antigua" en la JVM.

Si ves que el antiguo GC se está volviendo muy frecuente, puedes probar a establecer específicamente este valor en el archivo jvm.options de tu directorio de configuración de Elasticsearch.

¿Cuáles son las mejores prácticas para gestionar el uso del tamaño del heap y la recogida de basura de la JVM en un gran clúster de Elasticsearch?

Las mejores prácticas para gestionar el uso del tamaño del heap y la recolección de basura de la JVM en un gran clúster de Elasticsearch son cerciorar que el tamaño del heap esté fijado en un máximo del 50% de la RAM disponible, y que la configuración de recogida de basura de la JVM esté optimizada para el caso de uso específico. Es importante monitorizar el tamaño del montón y las métricas de recogida de basura para cerciorar de que el clúster funciona de forma óptima. En concreto, es importante monitorizar el tamaño del montón de la JVM, el tiempo de recogida de basura y las pausas en la recogida. Además, es importante controlar el número de ciclos de recogida de basura y el tiempo dedicado a la recogida. Al monitorizar estas métricas, es posible identificar posibles problemas con el tamaño del montón o la configuración de recogida de basura y tomar medidas correctivas si es necesario.

La API _split suele ser un método más rápido que la API _reindex. La indexación debe detener antes de ambas operaciones, de lo contrario, el source_index y el target_index el recuentos de documentos variarán.

Método 1 – usando la API dividida

La API dividida se emplea para crear un nuevo índice con el número deseado de fragmentos primarios copiando los ajustes y mapeando un índice existente. El número deseado de fragmentos primarios puede establecer durante la creación. Se deben comprobar las siguientes configuraciones antes de implementar la API de división:

1. El índice de origen debe ser de solo lectura. Esto significa que el proceso de indexación debe detener.

2. El número de fragmentos primarios en el índice objetivo debe ser un múltiplo del número de fragmentos primarios en el índice fuente. Por ejemplo, si el índice fuente tiene 5 fragmentos primarios, los fragmentos primarios del índice objetivo pueden establecer en 10, 15, 20, y así sucesivamente.

Nota: Si solo es necesario cambiar el número principal del fragmento, se prefiere la API dividida porque es mucho más rápida que la API de Reindex.

Implementación de la API de división

Crea un índice de prueba:

El índice fuente debe ser de solo lectura para poder dividir:

Los ajustes y mapeos se copiarán automáticamente desde el índice fuente:

Puedes consultar el progreso con:

Como los ajustes y mapeos se copian de los índices fuente, el índice destino es de solo lectura. Activemos la operación de escritura para el índice objetivo:

Consulta el índice de origen y destino docs.count antes de eliminar el índice original:

El nombre del índice y el nombre del alias no pueden ser iguales. Necesitas eliminar el índice fuente y agregar el nombre del índice fuente como alias al índice objetivo:

Luego de agregar el alias test_split_source al índice de test_split_target , deberías probarlo con:

Método 2 – usando la API de reindex

Al crear un nuevo índice con la API Reindex, se puede obtener cualquier número de conteos de fragmentos primarios. Tras crear un nuevo índice con el número previsto de fragmentos primarios, todos los datos del índice fuente pueden reindexar a este nuevo índice.

Además de las funciones de API dividida, los datos pueden manipular usando el ingest_pipeline en el AP de reindexación. Con la tubería de ingest, solo los campos especificados que encajen con el filtro se indexarán en el índice objetivo usando la consulta. El contenido de los datos puede modificar usando un script sencillo, y varios índices pueden fusionar en un solo índice.

Implementación de la API de reindex

Crea un reindexado de prueba:

Copia la configuración y los mapeos del índice fuente:

Crea un índice objetivo con ajustes, mapeos y el número de fragmentos deseado:

*Nota: ajustar number_of_replicas: 0 y refresh_interval: -1 aumentará la velocidad de reindexación.

Inicia el proceso de reindexación. Configurar requests_per_second=-1 y slices=auto ajustará la velocidad de reindexación.

Verás el task_id cuando ejecutes la API de reindex. Cópila y comprueba con _tasks API:

Actualiza la configuración después de que termine el reindexado:

Consulta el índice fuente y destino docs.count antes de borrar el índice original, debería ser el mismo:

El nombre del índice y el nombre del alias no pueden ser iguales. Elimina el índice fuente y agrega el nombre del índice fuente como alias al índice objetivo:

Luego de agregar el alias test_split_source al índice de test_split_target, pruébalo usando:

Resumen

Si quieres aumentar el recuento de fragmentos primarios de un índice existente, necesitas recrear los ajustes y asignaciones a un nuevo índice. Hay 2 métodos principales para hacerlo: la API de reindex y la API de split. La indexación activa debe detener antes de usar cualquiera de los dos métodos.

Las desventajas de ese enfoque son que requiere cierta duplicación de hardware y podría crear dificultades al intentar transferir y sincronizar sin problemas todos los datos.

También puede ser necesario realizar un procedimiento similar si necesita migrar aplicaciones de un centro de datos a otro.

En este artículo, analizaremos y detallaremos tres formas de transferir datos entre clústeres de Elasticsearch.

¿Cómo migrar datos entre clusters de Elasticsearch?

Hay 3 formas de transferir datos entre clústeres de Elasticsearch:

1. Reindexación desde un clúster remoto

2. Transferencia de datos mediante instantáneas

3. Transferencia de datos mediante Logstash

El uso de instantáneas suele ser la forma más rápida y confiable de transferir datos. Sin embargo, tenga en cuenta que solo puede restaurar una instantánea en un clúster de una versión igual o superior y nunca con una diferencia de más de una versión principal. Esto significa que puede restaurar una instantánea 6.x en un clúster 7.x, pero no en un clúster 8.x.

Si necesita aumentar en más de una versión principal, deberá volver a indexar o usar Logstash.

Ahora, veamos en detalle cada una de las tres opciones para transferir datos entre clústeres de Elasticsearch.

1. Reindexación de datos de un clúster remoto

Antes de comenzar a volver a indexar, recuerde que deberá configurar asignaciones adecuadas para todos los índices del nuevo clúster. Para ello, debe crear los índices directamente con las asignaciones adecuadas o emplear plantillas de índice.

Reindexación desde remoto: se requiere configuración

Para poder reindexar desde remoto, debe agregar la siguiente configuración al archivo elasticseearch.yml para el clúster que recibe los datos, que, en los sistemas Linux, generalmente se encuentra aquí: /etc/elasticsearch/elasticsearch.yml. La configuración a agregar es la siguiente:

Si emplea SSL, debe agregar el certificado de CA a cada nodo e incluir lo siguiente en el comando para cada nodo de elasticsearch.yml:

Alternativamente, puede agregar la siguiente línea a todos los nodos de Elasticsearch para deshabilitar la verificación SSL. Sin embargo, ese enfoque es menos recomendable ya que no es tan seguro como la opción anterior:

Deberá realizar estas modificaciones en cada nodo y realizar un resetear continuo. Para obtener más información sobre cómo hacerlo, consulte nuestra guía.

Comando de reindexación

Luego de definir el host remoto en el archivo elasticsearch.yml y agregar los certificados SSL si es necesario, puede comenzar a reindexar datos con el siguiente comando:

Al hacerlo, es posible que se enfrente a errores de tiempo de espera, por lo que puede ser útil establecer valores generosos para los tiempos de espera en lugar de depender de los valores predeterminados.

Ahora, echemos un vistazo a algunos otros errores comunes que puede encontrar al reindexar desde el control remoto.

Errores comunes al reindexar desde el control remoto

1. Reindexación no incluida en la lista blanca

Si encuentra este error, muestra que no definió la dirección IP del host remoto o el nombre DNS del nodo en Elasticsearch como se describió anteriormente u olvidó resetear los servicios de Elasticsearch.

Para solucionar eso para el clúster de Elasticsearch, debe agregar el host remoto a todos los nodos de Elasticsearch y resetear los servicios de Elasticsearch.

2. Excepción de protocolo de enlace SSL

Este error significa que olvidó agregar el reindex.ssl.certificate_authorities a elasticsearch.yml como se describió anteriormente. Para agregarlo:

2. Transferencia de datos mediante instantáneas

Recuerde, como se mencionó anteriormente, solo puede restaurar una instantánea en un clúster de una versión igual o superior y nunca con una diferencia de más de una versión principal

Si necesita aumentar en más de una versión principal, deberá volver a indexar o usar Logstash.

Se requieren los siguientes pasos para transferir datos a través de instantáneas:

Paso 1. Agregar el complemento del repositorio al primer clúster de Elasticsearch: para transferir datos entre clústeres a través de instantáneas, debe cerciorar de que se pueda acceder al repositorio tanto desde los clústeres nuevos como desde los antiguos. Los repositorios de espacio en la nube como AWS, Google y Azure son generalmente ideales para esto. Para tomar instantáneas, consulte nuestra guía y siga los pasos que describe.

Paso 2. Resetear el servicio Elasticsearch (resetear continuo).

Paso 3. Crea un repositorio para el primer cluster de Elasticsearch.

Paso 4- Agrega el plugin del repositorio al segundo clúster de Elasticsearch.

Paso 5: Agregar repositorio como de solo lectura al segundo clúster de Elasticsearch: deberá agregar un repositorio repitiendo los mismos pasos que realizó para crear el primer clúster de Elasticsearch.

Nota importante: Al conectar el segundo clúster de Elasticsearch al mismo repositorio de AWS S3, debe definir el repositorio como un repositorio de solo lectura:

Esto es importante porque desea evitar el riesgo de mezclar versiones de Elasticsearch dentro del mismo repositorio de instantáneas.

Paso 6- Restauración de datos en el segundo clúster de Elasticsearch: luego de seguir los pasos anteriores, puede restaurar los datos y transferirlos al nuevo clúster. Siga los pasos descritos en este artículo para restaurar los datos en el nuevo clúster. 

3. Transferencia de datos mediante Logstash

Antes de comenzar a transferir los datos con logstash, recuerde que deberá configurar las asignaciones adecuadas para todos los índices del nuevo clúster. Para ello, deberá crear los índices directamente o emplear plantillas de índice.

Para transferir datos entre dos clústeres de Elasticsearch, puedes configurar un servidor temporal de Logstash y usarlo para transferir tus datos entre dos clústeres. Para clústeres pequeños, una instancia de RAM de 2 GB debería ser suficiente. Para clústeres más grandes, puede usar CPU de cuatro núcleos con 8 GB de RAM.

Para obtener orientación sobre la instalación de Logstash, consulte aquí.

Configuración de Logstash para transferir datos de un clúster a otro

Una configuración básica para copiar un solo índice del clúster A al clúster B es:

Para elasticsearch seguro, puede usar la siguiente configuración:

Metadatos de índice

Los comandos anteriores escribirán en un único índice con nombre. Si desea transferir varios índices y conservar los nombres de índice, deberá agregar la siguiente línea a la salida de Logstash:

Además, si desea conservar la identificación original del documento, deberá agregar:

Tenga en cuenta que configurar el ID del documento hará que la transferencia de datos sea significativamente más lenta, así que solo conserve el ID original si es necesario.

Sincronización de actualizaciones

Todos los métodos descritos anteriormente tardarán un periodo de tiempo relativamente largo y es posible que los datos del clúster original se actualizaron mientras espera que se complete el proceso.

Existen varias estrategias para habilitar la sincronización de cualquier actualización que pueda ocurrir durante el proceso de transferencia de datos, y debe pensar en estos problemas antes de iniciar ese proceso. En individuo, debe pensar en:

• ¿Qué método tiene para identificar cualquier dato que se actualizó/agregado desde el inicio del proceso de transferencia de datos (por ejemplo, un campo "last_update_time" en los datos)?

• ¿Qué método puede emplear para transferir el último dato?

• ¿Existe el riesgo de que se dupliquen los registros? Por lo general, lo hay, a menos que el método que está empleando establezca el ID del documento durante la reindexación en un valor conocido).

A continuación se describen los diferentes métodos para habilitar la sincronización de actualizaciones.

1. Uso de sistemas de colas

Algunos sistemas de ingesta/actualización emplean colas que permiten "reproducir" las modificaciones de datos recibidas en los últimos x días. Eso puede proporcionar un medio para sincronizar cualquier cambio realizado.

2. Reindexar desde remoto

Repita el proceso de reindexación para todos los elementos en los que "last_update_time" > hace x días. Para ello, agregue un parámetro "query" a la solicitud de reindexación.

3. Logstash

En la entrada de Logstash, puede agregar una consulta para filtrar todos los elementos donde "last_update_time" > hace x días. Sin embargo, este proceso provocará duplicados en los datos que no sean de seriales temporales a menos que estableció el document_id.

4. Instantáneas

No es posible restaurar solo una parte de un índice, por lo que tendría que usar uno de los otros métodos de transferencia de datos descritos anteriormente (o un script) para actualizar los cambios que se produjeron desde que se llevó a cabo el proceso de transferencia de datos.

Sin embargo, la restauración de instantáneas es un proceso mucho más rápido que la reindexación/Logstash, por lo que puede ser posible suspender las actualizaciones durante un breve periodo de tiempo mientras se transfieren las instantáneas para evitar el problema por completo.