ECK requiere mucho más esfuerzo que las soluciones Elastic Cloud basadas en el Marketplace, pero es más automatizado que desplegar VMs por tu cuenta, porque el operador Kubernetes se encargará de la orquestación del sistema y el escalado de nodos.

Esta vez, vamos a trabajar con el Azure Kubernetes Service (AKS), usando Automático. En los otros artículos aprenderás a usar Azure VM y Azure Marketplace.

¿Qué es AKS Automático?

Azure Kubernetes Service (AKS) gestiona automáticamente la configuración del clúster, asigna dinámicamente los recursos e integra las mejores prácticas de seguridad mientras preserva la flexibilidad de Kubernetes, permitiendo a los desarrolladores pasar de la imagen del contenedor a la aplicación desplegada en cuestión de minutos.

AKS Automatic elimina la mayor parte de la gestión del cluster y logra un buen equilibrio entre simplicidad y flexibilidad. La elección correcta depende de tu caso de uso, pero la decisión es más fácil si planeas:

• Despliega un entorno de pruebas: El despliegue es rápido y sencillo, lo que lo hace ideal para experimentos rápidos o clústeres de corta duración.

• Trabajar sin requisitos estrictos de máquinas virtuales, almacenamiento o redes: AKS Automatic ofrece valores predeterminados, así que si esos se ajustan a tus necesidades, te ahorra más configuraciones.

• Empieza por Kubernetes por primera vez: Al gestionar gran parte de la configuración del clúster, AKS Automatic reduce la curva de aprendizaje y permite a los equipos centrar en sus aplicaciones.

Para Elasticsearch, vamos a usar Elastic Cloud on Kubernetes (ECK), que es el operador oficial de Elastic Kubernetes que simplifica la orquestación de despliegues de Kubernetes en Elastic Stack.

Cómo configurar AKS Automatic

1. Iniciar sesión en el Portal Microsoft Azure.

2. En la parte superior derecha, haz clicen el botón Cloud Shell para acceder a la consola y desplegar el clúster AKS desde allí. Alternativamente, puedes usar Azure Cloud Shell.

Recuerda actualizar el ID del proyecto con el tuyo durante el tutorial.

Abrir el AKS debería ver como en la captura de pantalla de arriba.

3. Instalar la extensión aks-preview de Azure CLI. Esta versión previa nos permitirá seleccionar --sku automatic en la creación del clúster, lo que habilita la función AKS Automática.

Si ves este mensaje, significa que la extensión AKS se instaló correctamente.

4. Registrar banderas de características usando el comando az feature register

Veréis los detalles sobre la subscripción a la función que acabamos de crear:

Verifica el estado del registro hasta que cambie de "Registrado" a "Registrado". Puede tardar unos minutos en terminar el registro.

Ejecuta az provider register para propagar los cambios.

5. Crear un grupo de recursos

Un grupo de recursos es un grupo lógico de recursos Azure que deben gestionar y desplegar.

6. Crear un clúster de Autopilot. Lo llamaremos myAKSAutomaticCluster y usaremos el grupo de recursos que acabamos de crear. Cerciórate de tener disponibles 16 vCPUs en cualquiera de los siguientes tamaños de VM: Standard_D4pds_v5, Standard_D4lds_v5, Standard_D4ads_v5, Standard_D4ds_v5, Standard_D4d_v5, Standard_D4d_v4, Standard_DS3_v2 Standard_DS12_v2 para que AKS asigne recursos.

* Si aparecen MissingSubscriptionRegistration errores, vuelve al paso 4 con las subscripciones que faltan. Por ejemplo, The subscription is not registered to use namespace 'microsoft.insights' requiere correr az provider register --namespace Microsoft.Insights.

Sigue el inicio de sesión interactivo:

Aparecerá un mensaje pidiendo ejecutar "az login". Tienes que ejecutar ese comando y luego esperar.

7. Esperar a que esté listo. Tarda unos 10 minutos en crear.

8. Configurar el acceso en línea de comandos de kubectl.

Ten en cuenta que la extensión que instalamos está habilitando AKS Automatic.

9. Confirmar que los nodos se desplegaron.

Verás un mensaje de error prohibido; copia el ID de usuario del error.

10. Agregar a tu usuario al control de acceso de AKS.

Consigue el ID AKS. Copia la salida del comando.

Crea una asignación de roles usando el ID AKS y el ID principal de tu usuario.

11. Intenta confirmar que los nodos se desplegaron de nuevo.

12. Instalar la Nube Elástica en el operador Kubernetes (ECK).

13. Vamos a crear una instancia de Elasticsearch de un solo nodo con los valores predeterminados.

Desactivamos nmap porque la máquina AKS predeterminada tiene un valor de vm.max_map_count demasiado bajo. No se recomienda desactivarlo para la producción, pero sí aumentar el valor de vm.max_map_count. Puedes leer más sobre cómo hacerlo aquí.

14. Desplieguemos también un clúster Kibana de un solo nodo. Para Kibana, agregaremos un balanceador de carga, que nos dará una IP externa que podremos usar para llegar a Kibana desde nuestro dispositivo.

Por defecto, AKS Automatic configurará el balanceador de carga como público; Puedes cambiar el comportamiento configurando la anotación de metadatos:

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

15. Comprueba que tus cápsulas estén funcionando.

16. También puedes ejecutar kubectl get elasticsearch y kubectl get kibana para estadísticas más específicas como la versión de Elasticsearch, nodos y salud.

17. Accede a tus servicios.

Esto te mostrará la URL externa de Kibana bajo EXTERNAL-IP. Puede que el balanceador de carga tarde unos minutos en provisionarse. Copia el valor de EXTERNAL-IP.

18. Consigue la contraseña de Elasticsearch para el usuario 'elastic':

19. Accede a Kibana desde tu navegador:

a. URL: https://<EXTERNAL_IP>:5601

b. Nombre de usuario:elastic

c. Contraseña:c44A295CaEt44D6xIzN6Zs5m (del paso anterior)

20. Al acceder a Elastic Cloud desde tu navegador, verás la pantalla de bienvenida.

Si quieres cambiar las especificaciones del clúster de Elasticsearch, como cambiar o redimensionar nodos, puedes volver a aplicar el manifiesto YML con la nueva configuración:

En este ejemplo, vamos a agregar un nodo más y modificar la RAM y la CPU. Como puedes ver, ahora kubectl get elasticsearch muestra 2 nodos:

Lo mismo ocurre con Kibana:

Podemos ajustar la CPU/RAM del contenedor y también el uso de Node.js memoria (máximo-tamaño de espacio antiguo)

Ten en cuenta que las reclamaciones de volumen existentes no pueden reducir. Tras aplicar la actualización, el operador realizará los cambios con un tiempo de interrupción mínimo.

Recuerda eliminar el clúster cuando termines de hacer pruebas para evitar costos innecesarios.

Conclusión

Emplear Azure AKS Automatic con ECK proporciona una solución equilibrada para desplegar Elasticsearch y Kibana: reduce la complejidad operativa, garantiza escalado y actualizaciones automatizadas, y aprovecha la flexibilidad de Kubernetes. Este enfoque es ideal para equipos que buscan un proceso de despliegue fiable, repetible y manteniendo sin gestionar manualmente cada detalle de la infraestructura, lo que lo convierte en una opción práctica tanto para entornos de pruebas como de producción.

Pasos siguientes

Si quieres leer más sobre Kubernetes, puedes consultar la documentación oficial aquí:

• Nube elástica en Kubernetes | Documentos elásticos

• Introduction to Azure Kubernetes Service (AKS) Automatic (preview)

• AKS Automatic - Blog de ingeniería de AKS

¿Qué es el chunking recursivo?

El fragmento recursivo iterará a través de una lista de secciones proporcionadas que separan patrones para dividir progresivamente un documento en segmentos más pequeños hasta alcanzar el tamaño máximo deseado del fragmento.

¿Cómo configuro el chunking recursivo?

A continuación se presentan los valores configurables proporcionados por el usuario para el fragmento recursivo:

• (requerido) max_chunk_size: El número máximo de palabras en un bloque.

• Cualquiera de:

  • separators: Una lista de patrones de cadenas regex que se usarán para dividir el documento en bloques.

  • separator_group: Una cadena que se mapea a una lista predeterminada de separadores definida por Elastic para usar en tipos específicos de documentos. Actualmente, hay markdown y plaintext disponibles.

¿Cómo funciona el chunking recursivo?

El proceso de fragmentación recursiva dado un documento de entrada, una max_chunk_size (medida en palabras) y una lista de cadenas de separadores es el siguiente:

1. Si el documento de entrada ya está dentro del tamaño máximo del bloque, devuelva un solo bloque que cubra toda la entrada.

2. Divide el texto en posibles fragmentos según la aparición del separador. Para cada segmento potencial:

   1. Si el chunk potencial está dentro del tamaño máximo del chunk, agrégalo a la lista de chunks para devolverlos al usuario.

   2. De lo contrario, repite desde el paso 2, usando solo el texto del posible fragmento y dividiendo usando el siguiente separador de la lista. Si ya no quedan separadores por probar, recurre a fragmentos basados en frases.

Ejemplos de configuración del chunking recursivo

Además del tamaño del bloque, la configuración principal para el fragmento recursivo es seleccionar qué separadores deben usar para dividir tus documentos. Si no sabes por dónde empezar, Elasticsearch ofrece algunos grupos de separadores por defecto que se pueden usar en casos de uso comunes.

Utilización de grupos separadores

Para emplear un grupo separador, simplemente indica el nombre del grupo que quieres usar al configurar la configuración de fragmentos. Por ejemplo:

Esto te dará una estrategia de fragmentación recursiva que emplea la lista de separadores ["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")]. Esto funciona bien para aplicaciones genéricas de texto plano, dividiendo en 2 caracteres de nueva línea, seguidos de 1 carácter de nueva línea.

También ofrecemos un grupo de separadores markdown que empleará la lista de separadores:

Esta lista de separadores funcionará bien para casos generales de reducción de categorías, dividiendo en cada uno de los 6 niveles de encabezado y en los caracteres que rompen secciones.

Al crear un recurso (extremo de inferencia/campo de texto semántico), la lista de separadores correspondiente al grupo de separadores en ese momento se almacenará en tus configuraciones. Si el grupo separador se actualiza más adelante, no cambiará el comportamiento de los recursos ya creados.

Empleando una lista de separadores personalizada

Si uno de los grupos de separadores predefinidos no funciona para tu caso de uso, puedes definir una lista personalizada de separadores que se adapte a tus necesidades. Ten en cuenta que las expresiones regulares pueden proporcionar dentro de la lista de separadores. A continuación se muestra un ejemplo de configuración de fragmentación configurada con separadores personalizados:

La estrategia de fragmentación anterior se dividirá en 2 caracteres de nueva línea, seguidos de 1 carácter de nueva línea y, por último, en una cadena “<my-custom-separator>”.

Un ejemplo de fragmentación recursiva en acción

Veamos un ejemplo de fragmentación recursiva en acción. Para este ejemplo, usaremos los siguientes ajustes de fragmentación con una lista personalizada de separadores que dividen un documento markdown usando los dos niveles superiores de cabecera:

Veamos un documento sencillo de Markdown sin fragmentos:

Ahora usemos los ajustes de fragmentación definidos arriba para fragmentar el documento:

Nota: La nueva línea al final de cada bloque (excepto el Fragmento 3) no está resaltada, pero sí se incluye dentro de los límites reales del bloque.

¡Empieza hoy mismo con el chunking recursivo!

Para más información sobre cómo emplear esta función, consulta la documentación sobre cómo configurar la configuración de fragmentos.

Además, estos casos de uso suelen ser sensibles al tiempo, y pasar por las etapas típicas de desarrollo (crear una rama de código y luego esperar una nueva versión) es un proceso que consume mucho tiempo.

Entonces, ¿y si pudiéramos hacer todo este proceso solo con una llamada a la API, o mejor aún, con solo unos clics en Kibana?

Interfaz de Reglas de Consulta

Elasticsearch 8.10 introdujo Reglas de Consulta y Retriever de Reglas. Estas son herramientas diseñadas para inyectar resultados fijados en las consultas sin afectar la clasificación de los resultados orgánicos según reglas. Solo agregan lógica de negocio encima de los resultados de forma declarativa y sencilla.

Algunos casos de uso comunes para las Reglas de Consulta son:

• Destacar anuncios u ofertas promocionadas: Mostrar artículos en oferta o patrocinados en la parte superior.

• Excluyendo por contexto o geolocalización: ocultar ciertos objetos cuando la normativa local no permite mostrarlos.

• Priorizar los resultados clave: Cerciorar de que las búsquedas populares o fijas estén siempre en la cima, independientemente del ranking orgánico.

Para acceder a la interfaz e interactuar con estas herramientas, necesitas hacer clic en el menú lateral de Kibana e ir a Reglas de consulta, en Relevancia:

Cuando aparezca el menú de reglas de consulta, haz clic en Crear tu primer conjunto de reglas:

A continuación, tienes que nombrar tu conjunto de normas.

La forma para definir cada regla tiene tres componentes clave:

• Criterios: Las condiciones que deben cumplir para que la norma se aplique. Por ejemplo, "cuando el campo query_string contiene el valor Christmas" o "cuando el campo del país es CO."

• Acción: Esto es lo que quieres que ocurra cuando se cumplan las condiciones. Puede fijar (fijar un documento a los resultados superiores) o excluir (ocultar un documento).

• Metadatos: Estos son los campos que acompañan la consulta cuando se ejecuta. Pueden incluir la información del usuario (como ubicación o idioma), así como datos de búsqueda (query_string). Estos son los valores que emplean los criterios para decidir si aplicar o no una regla.

Ejemplo: objetos populares

Imaginemos que tenemos un sitio de comercio electrónico con diferentes artículos. Al analizar las métricas, observamos que uno de los artículos más vendidos en la categoría de consolas es el "DualShock 4 Wireless Controller", especialmente cuando los usuarios buscan las palabras clave "PS4" o "PlayStation 4". Así que decidimos poner este producto encima de los resultados cada vez que un usuario busque esas palabras clave.

Primero, indexemos los documentos de cada elemento usando una solicitud Bulk API:

Si no intervenimos en la consulta, el elemento suele aparecer en cuarto lugar. Aquí está la pregunta:

Y aquí están los resultados

Vamos a crear una regla de consulta para cambiar esto. Primero, vamos a agregarlo al reglamento de esta manera:

O solicitud API equivalente:

Para usar el conjunto de reglas en nuestra consulta, debemos usar un tipo de regla de consulta. Este tipo de consulta se compone de dos partes principales:

• match_criteria: Estos son los metadatos que se emplean para comparar con la consulta del usuario. En este ejemplo, el conjunto de reglas se activa cuando el campo query_string tiene el valor "PlayStation 4."

• Consulta: La consulta real que se usará para buscar y obtener los resultados orgánicos.

De este modo, primero ejecutas la consulta orgánica y luego Elasticsearch aplica las reglas de tu conjunto de reglas:

Ejemplo: metadatos basados en el usuario

Otra aplicación interesante de las Reglas de Consulta es usar metadatos para mostrar documentos específicos basar en información contextual del usuario o del sitio web.

Por ejemplo, imaginemos que queremos destacar artículos o ventas personalizadas basándonos en el nivel de fidelidad del usuario, representado como un valor numérico.

Podemos hacerlo ingiriendo estos metadatos directamente en la consulta para que las reglas se activen cuando dicho valor cumple ciertos criterios.

Primero, indexaremos un documento que solo los usuarios con un alto nivel de lealtad puedan ver:

Ahora, creemos una nueva regla dentro del mismo conjunto de reglas para que cuando el loyalty_level sea igual o superior a 80, el elemento aparezca encima de los resultados.

Almacena la regla y el reglamento.

Aquí está la solicitud REST equivalente:

Ahora, al ejecutar una consulta, necesitamos incluir el nuevo parámetro loyalty_level en los metadatos. Si se cumple la condición de la regla, el nuevo documento aparecerá encima de los resultados.

Por ejemplo, al enviar una consulta donde el loyalty_level es 80:

Veremos el documento de lealtad encima de los resultados:

En el caso siguiente, dado que el nivel de lealtad es 70, la regla no se cumple y el objeto no debería aparecer arriba:

Aquí están los resultados:

Ejemplo: exclusión inmediata

Supongamos que nuestro mando inalámbrico DualShock 4 (ID 2) está temporalmente indisponible y no puede vender. Así que, en lugar de eliminar manualmente el documento o esperar a que algún proceso de datos se active, el equipo de negocio decide eliminarlo de los resultados de búsqueda mientras tanto.

Usaremos un proceso similar al que acabamos de aplicar a los objetos populares, pero esta vez en lugar de seleccionar Fijado, elegiremos Excluir. Esta regla funciona como una especie de lista negra. Cambia los criterios a Siempre para que la exclusión funcione cada vez que se ejecute la consulta.

La regla debería ser así:

Almacena la regla y el conjunto de reglas para aplicar los cambios. Aquí está la solicitud REST equivalente:

Ahora, cuando ejecutamos la consulta de nuevo, verás que el elemento ya no aparece en los resultados, aunque la regla anterior sea fijarlo. Esto se debe a que las exclusiones tienen prioridad sobre los resultados de fijación.

Conclusión

Las Reglas de Consulta facilitan mucho ajustar la relevancia sin ningún cambio en el código. La nueva interfaz Kibana tepermite realizar estos cambios en cuestión de segundos, dándote a ti y a tu equipo empresarial más control sobre los resultados de búsqueda.

Más allá del comercio electrónico, las Reglas de Consulta pueden impulsar muchos otros escenarios: destacar guías de resolución de problemas en portales de soporte, mostrar documentos internos clave en bases de conocimiento, promover noticias de última hora en sitios de noticias o filtrar ofertas de empleo o contenido caducado. Incluso pueden hacer cumplir normas de cumplimiento, como ocultar material restringido por rol de usuario o región.

Vamos a usar Elastic Cloud Service en AWS, que es el servicio oficial gestionado de Elasticsearch que simplifica el despliegue y la orquestación de todos los componentes de Elastic Stack a través de la infraestructura nativa de AWS.

Si quieres aprender a instalar y configurar Elasticsearch en AWS EC2, echa un vistazo a este blog.

¿Qué es AWS Marketplace?

Elastic en AWS Marketplace ofrece una experiencia de búsqueda y análisis totalmente gestionada, en la que AWS se encarga de la provisión de infraestructura, seguridad y el escalado, mientras los desarrolladores se centran en crear aplicaciones de búsqueda. Esto permite a los equipos desplegar clústeres de Elasticsearch de nivel empresarial en cuestión de minutos con integraciones de AWS integradas.

¿Cuándo usar Elastic en AWS Marketplace?

Elastic en AWS Marketplace es más adecuado para organizaciones con una infraestructura AWS existente que buscan desplegar Elasticsearch con servicios gestionados, seguridad integrada e integraciones fluidas de AWS sin sobrecarga operativa.

Cómo configurar Elastic Cloud en AWS Marketplace

Paso 1: Accede a AWS Marketplace

1. Inicia sesión en AWS

• En la barra de búsqueda, busca AWS Marketplace

2. En el panel de navegación izquierdo, haz clic en Descubrir productos, luego haz una búsqueda de Elasticsearch.

3. Haz clic en Elastic Cloud (Elasticsearch Service).

Paso 2: Suscríbete al servicio

1. Selecciona opciones de compra o haz clic en Pruébalo gratis

2. Revisa Detalles de precios, Términos y condiciones y Detalles de compra

3. Haz clic en el botón Suscribirse

4. Ahora hay que configurar la cuenta de Elastic. Sigue los pasos de AWS

a. Haz clic en el botón Habilitar integración.

b. Haz clic en el botón Iniciar sesión o crear una cuenta de proveedor

c. Haz clic en el botón Lanzar plantilla

d. Haz clic en el botón Iniciar software

Paso 3. Configura tu cuenta nueva en Elastic

1. Crea tu cuenta de Elastic

2. Valida tu dirección de correo electrónico

3. Introduce tu nombre e información de la empresa

4. Completa una rápida encuesta de Elastic

5. Selecciona la región en la que quieres hospedar Elastic Cloud. De forma predeterminada, se seleccionará tu región real de AWS

6. Espera a que Elastic se despliegue

7. Tu despliegue está conectado a tu suscripción de AWS Marketplace

Cancelar tu suscripción

Para cancelar tu suscripción

1. Ve a la consola de AWS

Haz una búsqueda de AWS Marketplace en la barra de búsqueda. Haz clic en AWS Marketplace

2. Haz clic en suscripción a Elastic Cloud

3. Haz clic en el botón Actions, luego haz clic en Cancelar suscripción

4. Confirma la cancelación, luego haz clic en Sí y en el botón Cancelar suscripción.

5. Aparecerá un mensaje de confirmación en la parte superior de la página

Pasos siguientes

Comienza tu experiencia con Elastic Cloud con una prueba gratuita de 7 días que incluye un único despliegue y tres proyectos Elastic Cloud (Elasticsearch Service). Simplemente inicia sesión en tu cuenta de AWS y haz clic en "Ver opciones de compra" para empezar a usar la Plataforma de búsqueda de IA de Elastic inmediatamente en Elastic Cloud (Elasticsearch Service). La prueba proporciona acceso completo a soluciones de búsqueda, seguridad y observabilidad sin ninguna carga de gestión de infraestructura.

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.

• bg_count (recuento de fondo): Número de documentos encontrados en el conjunto de datos principal

• doc_count: Número de documentos encontrados en el conjunto de datos resultante

Por ejemplo, en un conjunto de datos de ventas de teléfonos, podemos buscar términos significativos en las ventas del iPhone 16 como este:

Luego, la respuesta nos da:

Houston no está entre las 10 principales ciudades de todo el conjunto de datos ni la ciudad principal para el iPhone 16. Sin embargo, la agregación significativa de términos mostró que el iPhone 16 se está comprando de forma desproporcionada en esta ciudad en comparación con el resto de datos. Vamos a profundizar en los números:

• En el nivel superior:

  • doc_count: 122 — La consulta coincidió con un total de 122 documentos

  • bg_count: 424 — El conjunto de antecedentes (todos los documentos de ventas) contiene 424 documentos

• En el grupo de Houston:

  • doc_count: 12 — Houston aparece en 12 de los 122 resultados de consulta

  • bg_count: 14 — Houston aparece en 14 de los 424 documentos totales del conjunto de datos de fondo

Esto nos indica que, de un total de 424 compras, solo 14 ocurrieron en Houston; Eso supone el 3,3% de todas las compras. Sin embargo, si solo miramos las ventas del iPhone 16, vemos que 12 de 122 ocurrieron en Houston, lo que supone un 9,8%, tres veces más que en todo el conjunto de datos; ¡Eso es significativo!

Así es como se ve eso en una visualización: ventas totales por city_region.

Podemos ver que hay 14 ventas en Houston, lo que la convierte en la 14ª ciudad con más ventas en el conjunto de datos.

Ahora, si aplicamos un filtro para mirar solo las ventas del iPhone 16, tenemos 12 ventas en Houston, lo que la convierte en la segunda ciudad con más ventas para este modelo específico:

Comprensión de la agregación de términos significativos

Según la documentación de Elastic, los términos significativos agregación:

"(Encuentra) términos que experimentaron un cambio significativo de popularidad medido entre un conjunto de primer plano y un de fondo."

Esto significa que emplea métricas estadísticas para comparar la frecuencia de un término en un subconjunto de datos (el conjunto de primer plano) con la frecuencia del mismo término en el conjunto padre de datos (el conjunto de fondo). De este modo, el puntaje refleja la significación estadística en lugar de la frecuencia con la que aparece un término en los datos.

Las principales diferencias entre una agregación de términos significativos y una agregación de términos normales son:

• Los términos significativos comparan un subconjunto de los datos, mientras que la agregación de términos solo funciona sobre el conjunto de datos resultante de la consulta.

• Los resultados de una agregación de términos son los más comunes en el conjunto de datos, mientras que los resultados de términos significativos ignoran los términos comunes para encontrar qué hace único el conjunto de datos.

• Los términos significativos pueden tener un mayor impacto en el rendimiento, dado que necesitan obtener datos del disco en lugar de de la memoria, como ocurre con los términos agregación.

Aplicación práctica (análisis del comportamiento del consumidor)

Preparación de datos para el análisis

Para este análisis, generamos un conjunto de datos de ventas de teléfonos sintéticos que incluye precio, especificaciones del teléfono, demografía del comprador y opiniones. También generamos incrustaciones a partir de la retroalimentación del usuario para poder ejecutar una consulta semántica más adelante. Usamos el modelo pequeño multilingüe e5, disponible de fábrica en Elasticsearch.

Para usar este conjunto de datos en Elasticsearch:

1. Sube el archivo CSV (descargable desde aquí) usando la función de Upload de archivos de datos de Kibana.

2. Configura un campo semántico, como se muestra en este blog, llamado "embedding", que emplea el multilingual-e5-small model

3. Termina la importación con los valores predeterminados del tipo de campo (palabra clave para todos los campos excepto purchase_date y user_feedback). Cerciórate de agregar el nombre del índice phone_sales_analysis para poder ejecutar las consultas que se presentan aquí tal cual.

El objetivo principal de este análisis es descubrir "¿Qué diferencia a los compradores del iPhone 16 frente a otros segmentos de la población?" y segmentar a los compradores con fines de marketing. 

Este es un documento de ejemplo del conjunto de datos:

Comprensión de los patrones demográficos

Aquí, vamos a hacer un análisis sobre la población general y compararlo con hallazgos interesantes de las agregaciones significativas de términos para usuarios de iPhone 16.

Patrones normales

Para entender los patrones normales de compra, podemos agregar datos de todos los documentos de diferentes campos. Para simplificar, nos centraremos en explorar las ocupaciones de las personas que compraron un teléfono. Podemos hacer esto con una solicitud a Elasticsearch.

Esto nos indica que las principales ocupaciones en el conjunto de datos (por número de registros) son:

Patrones de los usuarios del iPhone 16

Para entender qué diferencia la gente que compró un iPhone 16, hagamos una agregación de términos en el mismo campo con un filtro para encontrar a las personas de la consulta, así:

Así que, para los usuarios del iPhone 16, las principales ocupaciones son:

Podemos ver que los usuarios del iPhone 16 tienen patrones de ocupación diferentes en comparación con los de otros modelos de teléfono. Usemos Kibana para visualizar fácilmente los resultados:

En este gráfico, podemos ver que la tendencia del iPhone 16 es diferente a la de toda la población.

Podemos saltarnos todo este análisis para ver qué diferencia a los usuarios del iPhone 16 de la población general mediante una agregación significativa de términos:

En resumen, obtenemos esta respuesta:

Valores de las ocupaciones para el iPhone 16

doc_count

bg_count

occupation_distribution (nivel superior)

122

424

Sector Médico y Sanitario

45

57

La respuesta sugiere claramente que los usuarios del iPhone 16 tienen un caso poco común (¡leer, significativo!) número de personas en el ámbito médico y sanitario en comparación con la población general. Veamos qué significan los números de la respuesta:

• En el nivel superior:

  • doc_count: 122 — La consulta coincidió con un total de 122 documentos

  • bg_count: 424 — El conjunto de antecedentes (todos los documentos de ventas) contiene 424 documentos

• En el ámbito Médico y Sanitario:

  • doc_count: 45 — "Medical & Healthcare" aparece en 45 de los 122 resultados de consulta

  • bg_count: 57 — "Médico y Salud" aparece en 57 de los 424 documentos totales del conjunto de datos de antecedentes

De 424 compradores, 57 trabajan en el ámbito médico y sanitario — o el 13,44%. Pero cuando miramos a los compradores del iPhone 16, 45 de 122 trabajan en el ámbito médico y sanitario — eso supone el 36,88%. ¡Esto significa que tenemos el doble de probabilidades de encontrar a alguien trabajando en el ámbito médico y sanitario entre los usuarios del iPhone 16!

Podemos aplicar este mismo análisis a otros campos (edad, ubicación, rango de ingresos, etc.) para encontrar más información sobre qué hace único a los usuarios del iPhone 16. 

Segmentación del consumidor

Podemos emplear los términos agregación significativa para extraer información sobre las relaciones entre productos, categorías y segmentos de clientes. Para ello, construimos una agregación madre para la categoría que nos interesa explorar. También usamos términos significativos y una subagregación de términos normales para encontrar ideas interesantes sobre esa categoría y compararlas con lo que la mayoría de las personas en esa ocupación usan.

Por ejemplo, veamos qué prefieren las personas en algunos campos laborales:

1. Para aclarar el análisis, limitemos nuestra búsqueda a 3 campos de trabajo: ["Administrativo y Soporte", "Tecnología y Datos", "Médico y Sanidad"]

2. En el lado de las agregaciones, comenzamos con una agregación por ocupación

3. Agrega una subagregación: términos por modelo de teléfono—para descubrir qué modelos están comprando los usuarios que trabajan en cada campo

4. Agregar una segunda subagregación: términos significativos por modelos de teléfono, para encontrar qué modelos son especiales en cada campo de trabajo

Desglosemos los resultados de la agregación:

Ocupación: Administrativa y de Apoyo

Agregación de términos

Agregación de términos significativa

De esta tabla, podemos inferir que no hay diferencias significativas entre la tendencia de esta ocupación y la tendencia de toda la población

Ocupación: Tecnología y Datos

Agregación de términos

Agregación de términos significativa

Total de documentos: 424

Documentos de esta ocupación: 71

Modelo de teléfono

doc_count (este modelo en esta ocupación)

bg_count (este modelo en todos los documentos)

% en todos los documentos

% en esta ocupación

Google Pixel 8

12

22

5.19%

16.90%

OnePlus 11

9

14

3.30 %

12.68%

OnePlus 12 Pro

3

3

0.71 %

4.23%

Google Pixel 8 Pro

9

21

4.95%

12.68%

Nothing Phone 2

5

8

1.89%

7.04%

Samsung Galaxy Z Fold5

4

6

1.42%

5.63%

OnePlus 12

8

20

4.72%

11.27 %

Ocupación: Medicina y Sanidad

Agregación de términos

Agregación de términos significativa

Total de documentos: 424

Documentos en esta ocupación: 57

Modelo de teléfono

doc_count (este modelo en esta ocupación)

bg_count (este modelo en todos los documentos)

% en todos los documentos

% en esta ocupación

iPhone 16

45

122

28.77%

78.95%

iPhone 15 Pro Max

3

13

3.07 %

5.26%

iPhone 15

7

40

9.43%

12.28%

Veamos qué historia nos cuentan estos datos:

• Los profesionales sanitarios prefieren el iPhone 16 y suelen estar muy inclinados a usar teléfonos Apple en general.

• Los profesionales de tecnología y datos prefieren teléfonos Android de gama alta, pero no necesariamente usan la marca Samsung. También hay una tendencia considerable para los iPhones en esta categoría.

• Los profesionales administrativos y de soporte prefieren los teléfonos Samsung y Google, pero no tienen una tendencia fuerte y única.

Agregación de términos significativos y búsqueda híbrida

La búsqueda híbrida combina la búsqueda por texto y resultados semánticos para ofrecer una experiencia de búsqueda mejorada. En este contexto, una agregación significativa de términos puede aportar información sobre los resultados de una búsqueda consciente del contexto al responder a la pregunta: ¿Qué tiene de especial este conjunto de datos en comparación con todos los documentos?Para demostrar esta característica, veamos qué modelos están sobrerrepresentados cuando los usuarios hablan de buen rendimiento:

• Vamos a construir una consulta semántica donde encontramos la mejor retroalimentación de los usuarios más cerca de la entrada de "buen rendimiento" en comparación con la incrustación de campos

• También usaremos una búsqueda de texto con los mismos términos sobre el campo de texto user_feedback

• También agregaremos una consulta significativa de términos para encontrar modelos telefónicos que se encuentren con más frecuencia entre estos resultados que en el conjunto de datos completo

Veamos un ejemplo de los documentos que coinciden:

Esta es la respuesta que recibimos:

Esto nos indica que, aunque un iPhone 15 se encuentra 40 veces de un total de 424 documentos (el 9,4% de los documentos), puede encontrar 5 veces en los 20 documentos que coinciden con la búsqueda semántica de "buen rendimiento" (el 25% de los documentos). Por tanto, podemos sacar una conclusión: un iPhone 15 tiene 2,7 veces más probabilidades de encontrar cuando se habla de buen rendimiento que por casualidad.

Conclusión

Los términos significativos agregación pueden descubrir detalles únicos de un conjunto de datos comparándolo con el universo de documentos. Esto puede revelar relaciones inesperadas en nuestros datos, que van más allá del conteo de ocurrencias. Podemos aplicar términos significativos en diversos casos de uso que permiten características muy interesantes, por ejemplo:

• Encuentra patrones al trabajar en la detección de fraude — identifica transacciones comunes de tarjetas de crédito robadas.

• Información sobre la calidad de la marca a partir de opiniones de usuarios — detecta una marca con un número desproporcionado de malas valoraciones.

• Documentos mal clasificados — documentos puntuales que pertenecen a una categoría (filtro de términos) que usan palabras poco comunes para la categoría en una descripción (agregación significativa de términos).

Para Elasticsearch, vamos a emplear Elastic Cloud on Kubernetes (ECK), que es el operador oficial de Elasticsearch Kubernetes que simplifica la orquestación de despliegues de Kubernetes de todos los componentes de Elastic Stack.

Para obtener más información sobre cómo desplegar clústeres de Elasticsearch en diferentes infraestructuras de GCP, puedes leer nuestros artículos de introducción sobre Google Cloud Compute y Google Cloud Marketplace.

Esfuerzo de despliegue de Elasticsearch

¿Qué es GKE Autopilot?

Google Kubernetes Engine (GKE) Autopilot ofrece una experiencia Kubernetes totalmente gestionada donde Google se encarga de la configuración del clúster, la gestión de nodos, la seguridad y el escalado, mientras los desarrolladores se centran en desplegar aplicaciones, lo que les permite a los equipos pasar del código a la producción en minutos con las mejores prácticas integradas.

¿Cuándo usar el ECK en Google Cloud?

Elastic Cloud on Kubernetes (ECK) es el más adecuado para organizaciones con infraestructura existente de Kubernetes que buscan desplegar Elasticsearch con características avanzadas como roles de nodo dedicados, alta disponibilidad y automatización.

¿Cómo configurar ECK en Google Cloud?

1. Inicia sesión en Google Cloud Console.

2. En la parte superior derecha haz clicen el botón Cloud Shell para acceder a la consola y desplegar el clúster de GKE desde allí. Alternativamente, puedes usar la CLI de gcloud.

Recuerda actualizar el identificador del proyecto con el tuyo durante el tutorial.

3. Habilita la API de Google Kubernetes Engine.

Haz clic en Siguiente.

Ahora, la API de Kubernetes Engine debería mostrarse habilitada al buscar la API de Kubernetes Engine.

4. En Cloud Shell, crea un clúster de Autopilot. Lo llamaremos autopilot-cluster-1, y también reemplazaremos autopilot-test por el id de tu proyecto.

5. Espera hasta que esté listo. Tarda unos 10 minutos en crearse.

Aparecerá un mensaje de confirmación después de configurar correctamente el clúster.

6. Configura el acceso a la línea de comandos de kubectl.

Deberías ver:

Entrada de kubeconfig generada para autopilot-cluster-1.

7. Instala el operador Elastic Cloud on Kubernetes (ECK).

8. Creemos una instancia de Elasticsearch de un solo nodo con los valores por defecto.

Si deseas consultar algunas recetas para diferentes configuraciones, puedes visitar este enlace.

Ten en cuenta que si no especificas un storageClass, ECK usará el que se configura por defecto, que para GKE es standard-rwo y usa el controlador CSI de disco persistente de Compute Engine, y creará un volumen de 1GB con él.

Deshabilitamos nmap porque la máquina GKE predeterminada tiene un valor vm.max_map_count demasiado bajo. No se recomienda desactivarlo para la producción, pero sí aumentar el valor de vm.max_map_count. Puedes leer más sobre cómo hacerlo aquí.

9. También despleguemos un clúster de un solo nodo Kibana. Para Kibana, agregaremos un LoadBalancer que nos dará una IP externa que podemos usar para acceder a Kibana desde nuestro dispositivo.

Nota la anotación:

cloud.google.com/l4-rbs: "enabled"

Es muy importante porque le indica a Autopilot que proporcione un LoadBalancer orientado al público. Si no se configura, el LoadBalancer será interno.

10. Verifica que tus pods estén en ejecución

11. También puedes run kubectl get elasticsearch y kubectl get kibana para obtener estadísticas más específicas como la versión de Elasticsearch, nodos y salud.

12. Accede a tus servicios.

Esto te mostrará la URL externa de Kibana bajo EXTERNAL-IP. Puede que el LoadBalancer tarde unos minutos en provisionar. Copia el valor de EXTERNAL-IP.

13 Obtén la contraseña de Elasticsearch para el usuario ‘elastic’:

14. Accede a Kibana desde tu navegador:

• URL:<EXTERNAL_IP> https://:5601

• Nombre de usuario: elastic

• Contraseña: 28Pao50lr2GpyguX470L2uj5 (del paso anterior)

15. Al acceder desde tu navegador, verás la pantalla de bienvenida.

Si quieres cambiar las especificaciones del clúster de Elasticsearch, como cambiar o redimensionar nodos, puedes volver a aplicar el manifesto yml con los nuevos ajustes:

En este ejemplo, vamos a agregar un nodo más y modificar la RAM y la CPU. Como puedes ver, ahora kubectl get elasticsearch muestra 2 nodos:

Lo mismo aplica para Kibana:

Podemos ajustar la CPU/RAM del contenedor y también el uso de memoria de Node.js (max-old-space-size).

Ten en cuenta que las solicitudes de volumen existentes no pueden reducirse. Después de aplicar la actualización, el operador realizará los cambios con el mínimo tiempo de interrupción.

Recuerda eliminar el clúster cuando termines de probar para evitar costos innecesarios.

Pasos siguientes

Si quieres saber más sobre Kubernetes y el motor de Google Kubernetes, consulta estos artículos:

• Elastic Cloud en Kubernetes | Elastic Docs

• Presentamos GKE Autopilot | Blog de Google Cloud

• Visión general del piloto automático | Google Kubernetes Engine (GKE)

Revisaremos:

• Mejores prácticas de producción

  • Manejo de errores

  • Pruebas

• Entornos sin servidor

  • Ejecutando el cliente en Elastic Serverless

  • Ejecutando el cliente en un entorno de función como servicio

Puedes consultar el código fuente con los ejemplos aquí.

Mejores prácticas de producción

Manejo de errores en Elasticsearch

Una característica útil del cliente Elasticsearch en Node.js es que expone objetos para los posibles errores en Elasticsearch, de modo que puedes validarlos y manejarlos de diferentes maneras.

Para verlos todos, pon esto: 

Volvamos al ejemplo de búsqueda y tratemos algunos de los posibles errores:

ResponseError en individuo, ocurrirá cuando la respuesta sea 4xx o 5xx, lo que significa que la solicitud es incorrecta o el servidor no está disponible.

Podemos probar este tipo de error generando consultas erróneas, como intentar hacer una consulta de términos en un campo de tipo texto:

Error por defecto:

Error personalizado:

También podemos capturar y manejar cada tipo de error de una manera determinada. Por ejemplo, podemos agregar lógica de reintentos en un TimeoutError.

Pruebas

Las pruebas son clave para garantizar la estabilidad de la aplicación. Para probar el código de forma aislada de Elasticsearch, podemos usar la biblioteca elasticsearch-js-mock al crear nuestro clúster.

Esta biblioteca nos permite instanciar un cliente muy similar al real, pero que responderá a nuestra configuración reemplazando solo la capa HTTP del cliente por una mock, manteniendo el resto igual que el original.

Instalaremos la biblioteca de simulacros y AVA para los exámenes automatizados.

npm install @elastic/elasticsearch-mock

npm install --save-dev ava

Configuraremos el archivo package.json para ejecutar las pruebas. Cerciórate de que se vea así:

Ahora creemos un archivo test.js e instalemos nuestro cliente simulado:

Ahora, agrega un simulacro para la búsqueda semántica:

Ahora podemos crear una prueba para nuestro código, cerciorándonos de que la parte de Elasticsearch siempre devolverá los mismos resultados:

Hagamos las pruebas.

npm run test

¡Hecho! A partir de ahora, podemos probar nuestra app centrándonos al 100% en el código y no en factores externos.

Entornos sin servidor

Cómo ejecutar el cliente en Elastic Serverless

Cubrimos la ejecución de Elasticsearch en la nube o local; sin embargo, el cliente Node.js también soporta conexiones a Elastic Cloud Serverless.

Elastic Cloud Serverless te permite crear un proyecto donde no tienes que preocuparte por la infraestructura, ya que Elastic se encarga de eso internamente, y solo tienes que preocuparte por los datos que quieres indexar y cuánto tiempo quieres tener acceso a ellos.

Desde la perspectiva del uso, los servidores sin servidor desacoplan el cálculo del almacenamiento, proporcionando funciones de escalado automático tanto para búsqueda como para indexación. Esto te permite solo hacer crecer los recursos que realmente necesitas.

El cliente realiza las siguientes adaptaciones para conectarse a Serverless:

• Apaga el olfateo e ignora cualquier opción relacionada con el olfateo

• Ignora todos los nodos que pasan en la configuración excepto el primero, e ignora cualquier filtrado de nodos y seleccionando opciones

• Activa la compresión y el 'TLSv1_2_method' (igual que cuando se configura para Elastic Cloud)

• Agrega un encabezado HTTP 'elastic-api-version' a todas las solicitudes

• Emplea 'CloudConnectionPool' por defecto en lugar de 'WeightedConnectionPool'

• Desactiva los encabezados 'content-type' y 'accept' que venden en favor de los tipos MIME estándar

Para conectar tu proyecto serverless, necesitas usar el parámetro serverMode: serverless.

Cómo ejecutar el cliente en un entorno de función como servicio

En el ejemplo, usamos un servidor Node.js, pero también puedes conectarte usando un entorno de función como servicio con funciones como AWS Lambda, GCP Run, etc.

Otro ejemplo es conectarse a servicios como Vercel, que también es sin servidor. Puedes consultar este ejemplo completo de cómo hacerlo, pero la parte más relevante del endpoint de búsqueda es la siguiente:

Este endpoint reside en la carpeta /api y se ejecuta desde el lado del servidor, de modo que el cliente solo tiene control sobre el parámetro "texto" que corresponde al término de búsqueda.

La participación de usar función como servicio es que, a diferencia de un servidor que funciona 24/7, las funciones solo activan la máquina que ejecuta la función y, una vez terminada, la máquina entra en modo reposo para consumir menos recursos.

Esta configuración puede ser conveniente si la aplicación no recibe demasiadas solicitudes; De lo contrario, los costos pueden ser elevados. También tienes que considerar el ciclo de vida de las funciones y los tiempos de ejecución (que en algunos casos pueden ser solo segundos).

Conclusión

En este artículo, aprendimos a manejar errores, algo crucial en entornos de producción. También cubrimos pruebas de nuestra aplicación simulando el servicio Elasticsearch, que proporciona pruebas fiables independientemente del estado del clúster y nos permite centrarnos en nuestro código.

Finalmente, demostramos cómo crear una pila totalmente serverless aprovisionando tanto Elastic Cloud Serverless como una aplicación Vercel.

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.

En esta primera parte, repasaremos:

• Medio ambiente

  • ¿Frontend, backend o serverless?

  • Conexión del cliente

• Indexación de documentos

  • Cliente Elasticsearch

  • Aplicaciones semánticas

  • Ayudante a granel

• Búsqueda de datos

  • Consulta léxica

  • Consulta semántica

  • Consulta híbrida

Puedes consultar el código fuente con los ejemplos aquí.

¿Qué es el cliente de Node.js Elasticsearch?

El cliente Elasticsearch Node.js es una biblioteca de JavaScript que introduce las llamadas HTTP REST de la API Elasticsearch a JavaScript. Esto facilita la gestión y cuenta con ayudas que simplifican tareas como indexar documentos en lotes.

Medio ambiente

¿Frontend, backend o serverless?

Para crear nuestra aplicación de búsqueda usando el cliente JavaScript, necesitamos al menos dos componentes: un clúster Elasticsearch y un entorno de ejecución en JavaScript para ejecutar el cliente.

El cliente JavaScript soporta todas las soluciones Elasticsearch (Cloud, local y Serverless), y no hay diferencias importantes entre ellas ya que el cliente gestiona todas las variaciones internamente, así que no tienes que preocuparte por cuál usar.

Sin embargo, el tiempo de ejecución de JavaScript debe ejecutar desde el servidor y no directamente desde el navegador.

Esto se debe a que, al llamar a Elasticsearch desde el navegador, el usuario puede obtener información sensible como la clave de la API del clúster, el host o la propia consulta. Elasticsearch recomienda no exponer nunca el clúster directamente a Internet y usar una capa intermedia que abstraiga toda esta información para que el usuario solo pueda ver los parámetros. Puedes leer más sobre este tema aquí.

Sugerimos usar un esquema como este:

En este caso, el cliente solo envía los términos de búsqueda y una clave de autenticación para tu servidor mientras este tiene el control total de la consulta y la comunicación con Elasticsearch.

Conexión del cliente

Empieza creando una clave API siguiendo estos pasos.

Siguiendo el ejemplo anterior, crearemos un servidor Express sencillo y nos conectaremos a él usando un cliente de un servidor Node.JS.

Inicializaremos el proyecto con NPM e instalaremos el cliente Elasticsearch y Express. Esta última es una biblioteca para abrir servidores en Node.js. Usando Express, podemos interactuar con nuestro backend vía HTTP.

Inicialemos el proyecto:

npm init -y

Dependencias de instalación:

npm install @elastic/elasticsearch express split2 dotenv

Déjame explicártelo:

• @elastic/elasticsearch: Es el cliente oficial de Node.js

• express: Nos permitirá montar un servidor nodejs ligero para exponer Elasticsearch

• split2: Divide líneas de texto en un flujo. Útil para procesar nuestros archivos de ndjson línea a línea

• dotenv: Permítenos gestionar variables de entorno usando un .env archivo

Crea un .env archiva en la raíz del proyecto y agrega las siguientes líneas:

De esta manera, podemos importar esas variables usando el paquete dotenv .

Crea un archivo server.js :

Este código configura un servidor de Express.js básico que escucha en el puerto 3000 y se conecta a un clúster Elasticsearch usando una clave API para autenticación. Incluye un punto final /ping que, al acceder mediante una solicitud GET, consulta al clúster de Elasticsearch información básica empleando el método .info() del cliente Elasticsearch. 

Si la consulta tiene éxito, devuelve la información del clúster en formato JSON; de lo contrario, devuelve un mensaje de error. El servidor también emplea middleware de parser corporal para gestionar los cuerpos de las solicitudes JSON.

Ejecuta el archivo para abrir el servidor:

node server.js

La respuesta debería ser la siguiente:

Y ahora, consultemos el /ping endpoint para comprobar el estado de nuestro clúster de Elasticsearch.

Indexación de documentos

Una vez conectados, podemos indexar documentos usando mapeos como semantic_text para búsqueda semántica y texto para consultas de texto completo. Con estos dos tipos de campos, también podemos hacer búsqueda híbrida.

Crearemos un nuevo archivo load.js para generar los mapeos y subir los documentos.

Cliente Elasticsearch

Primero necesitamos instanciar y autenticar al cliente:

Aplicaciones semánticas

Crearemos un índice con datos sobre un hospital veterinario. Almacenaremos la información del dueño, la mascota y los detalles de la visita.

Los datos sobre los que queremos realizar la búsqueda en texto completo, como nombres y descripciones, se almacenarán como texto. Los datos de categorías, como la especie o raza del animal, se almacenarán como palabras clave.

Además, copiaremos los valores de todos los campos en un campo semantic_text para poder ejecutar una búsqueda semántica también con esa información.

Ayudante a granel

Otro beneficio del cliente es que podemos usar el helper de mayor volumen para indexar en lotes. El helper en bulk nos permite gestionar fácilmente cosas como la concurrencia, los intentos y qué hacer con cada documento que pasa por la función y que tiene éxito o fracasa.

Una característica atractiva de este asistente es que puedes trabajar con streams. Esta función te permite enviar un archivo línea por línea en lugar de almacenar el archivo completo en la memoria y enviarlo a Elasticsearch de una sola vez.

Para subir los datos a Elasticsearch, crea un archivo llamado data.ndjson en la raíz del proyecto y agrega la información que aparece a continuación (alternativamente, puedes descargar el archivo con el conjunto de datos desde aquí):

Usamos split2 para transmitir las líneas de archivo mientras el asistente masivo las envía a Elasticsearch.

El código anterior dice un .ndjson archivo línea por línea y en volumen indexa cada objeto JSON en un índice Elasticsearch especificado usando el método helpers.bulk . Transmite el archivo usando createReadStream y split2, establece metadatos de indexación para cada documento y registra cualquier documento que no se procese. Una vez completado, registra el número de elementos indexados con éxito.

Alternativamente a la función indexData , puedes subir el archivo directamente a través de la interfaz usando Kibana y usar la interfaz de archivos de datos de subida.

Ejecutamos el archivo para subir los documentos a nuestro clúster de Elasticsearch.

node load.js

Búsqueda de datos en Elasticsearch

Volviendo a nuestro archivo server.js , crearemos diferentes endpoints para realizar búsquedas léxicas, semánticas o híbridas.

En resumen, este tipo de búsquedas no son mutuamente excluyentes, sino que dependerán del tipo de pregunta que necesites responder.

Tipo de consulta

Caso de uso

Pregunta de ejemplo

Consulta léxica

Las palabras o raíces de palabras en la pregunta probablemente aparecerán en los documentos del índice. Similitud de token entre la pregunta y los documentos.

Busco una camiseta deportiva azul.

Consulta semántica

Las palabras de la pregunta probablemente no aparecerán en los documentos. Similitud conceptual entre la pregunta y los documentos.

Busco ropa para el frío.

Búsqueda híbrida

La pregunta contiene componentes léxicos y/o semánticos. Similitud de tokens y semántica entre la pregunta y los documentos.

Estoy buscando un vestido talla S para una boda en la playa.

Las partes léxicas de la pregunta probablemente formarán parte de títulos y descripciones, o nombres de categorías, mientras que las partes semánticas son conceptos relacionados con esos campos. El azul probablemente será un nombre de categoría o parte de una descripción, y la boda en la playa probablemente no lo sea, pero puede estar semánticamente relacionada con la ropa de lino.

Consulta léxica (/search/lexic?q=<query_term>)

La búsqueda léxica, también llamada búsqueda de texto completo, significa búsqueda basada en la similitud de los tokens; es decir, tras un análisis, se devolverán los documentos que incluyan los tokens en la búsqueda.

Puedes consultar nuestro tutorial práctico de búsqueda léxica aquí.

Probamos con: corte de uñas

Respuesta:

Consulta semántica (/search/semantic?q=<query_term>)

La búsqueda semántica, a diferencia de la búsqueda léxica, encuentra resultados similares al significado de los términos de búsqueda mediante la búsqueda vectorial.

Puedes consultar nuestro tutorial práctico de búsqueda semántica aquí.

Hacemos la prueba con: ¿Quién se hizo una pedicura?

Respuesta:

Consulta híbrida (/search/hybrid?q=<query_term>)

La búsqueda híbrida nos permite combinar la búsqueda semántica y léxica, obteniendo así lo mejor de ambos mundos: se obtiene la precisión de buscar por token, junto con la proximidad de significado de la búsqueda semántica.

Hacemos pruebas con "¿Quién se hizo pedicura o tratamiento dental?"

Respuesta:

Conclusión

En esta primera parte de nuestro serial, explicamos cómo configurar nuestro entorno y crear un servidor con diferentes endpoints de búsqueda para consultar los documentos de Elasticsearch siguiendo las mejores prácticas cliente/servidor. Consulta la segunda parte de nuestro serial, en la que aprenderás las mejores prácticas de producción y cómo ejecutar el cliente de Node.js Elasticsearch en entornos serverless.

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.

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.

Históricamente, muchas personas usaban el tipo de campo nestedcomo un mecanismo para unir diferentes índices. Sin embargo, fue limitado debido a consultas costosas y soporte incompleto en Kibana, específicamente visualizaciones de Lens.

Este artículo profundizará en el proceso de unir dos índices en Elasticsearch, centrar en los siguientes enfoques:

1. Uso de la consulta terms

2. Uso del procesador enrich en canalizaciones de ingesta

3. Complemento de filtro elasticsearch Logstash

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

Uso de la consulta de términos

La consulta de términos es una de las formas más efectivas de unir dos índices en Elasticsearch. Esta consulta se emplea para recuperar documentos que contienen uno o más términos exactos en un campo específico. Aquí discutimos cómo usarlo para unir dos índices.

En primer lugar, debe recuperar los datos necesarios del primer índice. Esto se puede hacer usando una simple solicitud GET y extrayendo los valores del atributo _source .

Una vez que tenga los datos del primer índice, puede usarlos para consultar el segundo índice. Esto se hace mediante la consulta terms , donde se especifica el campo y los valores que desea que coincidan.

Aquí hay un ejemplo:

En este ejemplo, field_in_second_index es el campo del segundo índice que desea hacer coincidir con los valores del primer índice. value1_from_first_index y value2_from_first_index son los valores del primer índice que desea que coincidan en el segundo índice.

La consulta de términos también proporciona soporte para realizar los dos pasos anteriores de una sola vez mediante una técnica denominada búsqueda de términos. Elasticsearch se encargará de recuperar de forma transparente los valores para que coincidan con otro índice. Por ejemplo, si tiene un índice de equipos que contiene una lista de jugadores:

Es posible consultar un índice de personas para todas las personas que juegan en team1, como se muestra a continuación:

En el ejemplo anterior, Elasticsearch recuperará de forma transparente los nombres de los jugadores del documento con id team1 en el índice de equipos (es decir, "John", "Bill" y "Michael") y busque todos los documentos en el índice de personas que contengan cualquiera de esos valores en su campo de nombre.

Para aquellos que tienen curiosidad, la consulta SQL equivalente sería:

Uso del procesador enrich

El procesador enriches otra herramienta poderosa que se puede usar para unir dos índices en Elasticsearch. Este procesador enriquece los datos de los documentos entrantes agregando datos de un índice de enriquecimiento predefinido.

A continuación, le indicamos cómo puede usar el procesador de enriquecimiento para unir dos índices:

1. Primero, debe crear una política de enriquecimiento. Esta directiva define qué índice usar para el enriquecimiento, en qué campo coincidir y qué campos usar para enriquecer los documentos entrantes.

Aquí hay un ejemplo:

2. Una vez creada la política, debe ejecutarla para crear el índice de enriquecimiento a partir de la política recién creada:

Esto creará un nuevo índice enriquecido oculto que se usará durante el enriquecimiento. En función del tamaño del índice de origen, esta operación puede tardar algún tiempo. Cerciorar de que la política de enriquecimiento esté completamente desarrollada antes de continuar con el siguiente paso.

3. Una vez creada la directiva de enriquecimiento, puede emplear el procesador de enriquecimiento en una canalización de ingesta para enriquecer los datos de los documentos entrantes:

En este ejemplo, field_in_second_index es el campo del segundo índice que debe coincidir con el match_field del primer índice. enriched_field es el nuevo campo del segundo índice que contendrá los datos enriquecidos de la enrich_fields del primer índice.

Un inconveniente de este enfoque es que si los datos cambian en first_index, la política de enriquecimiento debe volver a ejecutar. El índice enriquecido no se actualiza ni sincroniza automáticamente desde el índice de origen a partir del cual se creó. Sin embargo, si first_index es relativamente estable, entonces este enfoque funciona bien.

Complemento de filtro Logstash elasticsearch

Si usa Logstash, otra opción similar al procesador de enrich descrito anteriormente es usar el complemento de filtro elasticsearch para agregar campos relevantes al evento en función de una consulta específica. La configuración de nuestra canalización de Logstash residiría en un archivo .conf , como my-pipeline.conf.

Imaginemos que nuestra canalización está extrayendo registros de Elasticsearch usando el complemento de entrada elasticsearch, con una consulta para reducir la selección:

Si queremos enriquecer estos mensajes con información de un índice determinado, podemos usar el complemento de filtro elasticsearchen la sección filter para enriquecer nuestros registros:

El código anterior buscará los documentos del índice index_name donde se inicia type y el campo de operación coincide con el opidespecificado y, a continuación, copiará el valor del campo @timestamp en un nuevo campo denominado started.

Los documentos enriquecidos se enviarían a la fuente de salida adecuada, en este caso a Elasticsearch mediante el complemento de salida elasticsearch:

Si ya está empleando Logstash, esta opción puede ser útil para consolidar su lógica de enriquecimiento en un solo lugar y procesar a medida que ingresan nuevos eventos. Sin embargo, si no lo está, agrega complejidad a su solución y otro componente que necesita ejecutar y mantener.

ES|ENRIQUECER QL

La introducción de ES|QL, que pasó a ser GA en la versión 8.14, es un lenguaje de consulta canalizado compatible con Elasticsearch que permite filtrar, transformar y analizar datos. El uso del comando de procesamiento ENRICH nos permite agregar datos de índices existentes mediante una política de enriquecimiento.

Tomando la misma my_enrich_policy de políticas del ejemplo original del procesador de enriquecimiento, el ES|El ejemplo de QL se vería así:

También es posible anular los campos de coincidencia y enriquecimiento, que en nuestro ejemplo son field_in_first_index y field_to_enrich respectivamente:

Si bien la limitación obvia es que primero debe especificar una política de enriquecimiento, ES|QL proporciona la flexibilidad para ajustar los campos según sea necesario.

ES|UNIÓN DE BÚSQUEDA DE QL

Elasticsearch 8.18 presenta una nueva forma de unir índices en Elasticsearch, a saber, el comando LOOKUP JOIN . Este comando funciona como una LEFT OUTER JOIN de estilo SQL empleando el nuevo modo de índice de búsqueda en el lado derecho de la unión.

Revisando nuestro ejemplo anterior, la nueva consulta es la siguiente, donde match_field debe estar presente tanto en first_index como en second_index:

El beneficio de LOOKUP JOIN sobre los otros enfoques es que no requiere ninguna directiva de enrich y, por lo tanto, el procesamiento adicional asociado con la configuración de la directiva. Es útil cuando se trabaja con datos de enriquecimiento que cambian con frecuencia, a diferencia de los otros enfoques que se analizan en este artículo.

Conclusión

En conclusión, si bien Elasticsearch no admite operaciones de unión tradicionales, proporciona varias características que se pueden usar para lograr resultados similares. Específicamente, cubrimos cómo lograr operaciones de unión usando:

1. La consulta terms

2. El procesador enrich en canalizaciones de ingesta

3. Complemento de filtro elasticsearch Logstash

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

Es importante tener en cuenta que estos métodos tienen sus limitaciones y deben usar juiciosamente según los requisitos específicos y la naturaleza de los datos.

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.

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.

Todas las consultas y salidas completas mencionadas en este artículo se pueden encontrar en nuestro repositorio de código de Elasticsearch Labs.

¿Por qué implementar Better Binary Quantization (BBQ) en tu caso de uso?

Aunque las matemáticas son interesantes, son cruciales si quieres comprender completamente por qué tus búsquedas vectoriales siguen siendo precisas. En última instancia, todo esto se reduce a la compresión, ya que resulta que con los algoritmos actuales de búsqueda vectorial estás limitado por la velocidad de lectura de los datos. Por lo tanto, si puedes meter todos esos datos en la memoria, obtienes un aumento significativo de velocidad en comparación con leer desde el almacenamiento (la memoria es aproximadamente 200 veces más rápida que los SSD).

Hay algunas cosas a tener en cuenta:

• Los índices basados en gráficos como HNSW (Hierarchical Navigable Small World) son los más rápidos para la recuperación de vectores.

  • HNSW: Un algoritmo de búsqueda aproximado del vecino más cercano que construye una estructura de gráficos multicapa para permitir búsquedas eficientes de similitud de alta dimensión.

• HNSW está fundamentalmente limitado en velocidad por la velocidad de lectura de datos de la memoria o, en el peor de los casos, del almacenamiento.

  • Idealmente, desea poder cargar todos sus vectores almacenados en la memoria.

• Los modelos de incrustación generalmente producen vectores con precisión float32, 4 bytes por número de punto flotante.

• Y finalmente, dependiendo de cuántos vectores y / o dimensiones tenga, puede quedar sin memoria muy rápidamente para mantener todos sus vectores.

Dando esto por sentado, ve que surge un problema rápidamente una vez que comienza a ingerir millones o incluso miles de millones de vectores, cada uno con potencialmente cientos o incluso miles de dimensiones. La sección titulada "Números aproximados en las relaciones de compresión" proporciona algunos números aproximados.

¿Qué necesitas para empezar?

Para comenzar, necesitará lo siguiente:

• Si usas Elastic Cloud o en las instalaciones, necesitarás una versión de Elasticsearch superior a la 8.18. Si bien BBQ se introdujo en 8.16, en este artículo, usará vector_rescore, que se introdujo en 8.18.

• Además, también deberá cerciorar de que haya un nodo de aprendizaje automático (ML) en el clúster. (Nota: se necesita un nodo de ML con un mínimo de 4 GB para cargar el modelo, pero es probable que necesite nodos mucho más grandes para cargas de trabajo de producción completas).

• Si emplea Serverless, deberá seleccionar una instancia optimizada para vectores.

• También necesitará un nivel básico de conocimiento sobre bases de datos vectoriales. Si aún no estás familiarizado con los conceptos de búsqueda vectorial en Elastic, es posible que desees consultar primero los siguientes recursos:

  • Navegación por una base de datos vectorial elástica

  • Las grandes ideas detrás de la generación aumentada de recuperación

Mejor implementación de cuantización binaria (BBQ)

Para simplificar este blog, empleará funciones integradas cuando estén disponibles. En este caso, tienes el modelo de incrustación de vectores .multilingual-e5-small que se ejecutará directamente dentro de Elasticsearch en un nodo de aprendizaje automático. Tenga en cuenta que puede reemplazar el modelo text_embedding con el incrustador de su elección (OpenAI, Google AI Studio, Cohere y muchos más). Si su modelo preferido aún no está integrado, también puede traer sus propias incrustaciones de vectores densos).

En primer lugar, deberá crear un punto de enlace de inferencia para generar vectores para un fragmento de texto determinado. Ejecutarás todos estos comandos desde la consola de herramientas de desarrollo de Kibana. Este comando descargará el .multilingual-e5-small. Si aún no existe, configurará su punto final; Esto puede tardar un minuto en ejecutar. Puede ver la salida esperada en el archivo 01-create-an-inference-endpoint-output.json en la carpeta Salidas.

Una vez que esto regresó, su modelo se configurará y podrá probar que el modelo funciona como se espera con el siguiente comando. Puede ver el resultado esperado en el archivo 02-embed-text-output.json en la carpeta Salidas.

Si tiene problemas relacionados con el modelo capacitado que no se asigna a ningún nodo, es posible que deba iniciar el modelo manualmente.

Ahora vamos a crear una nueva asignación con 2 propiedades, un campo de texto estándar (my_field) y un campo vectorial denso (my_vector) con 384 dimensiones para que coincida con la salida del modelo de incrustación. También anulará el index_options.type to bbq_hnsw. Puede ver el resultado esperado en el archivo 03-create-byte-qauntized-index-output.json en la carpeta Salidas.

Para cerciorarte de que Elasticsearch genere tus vectores, puedes usar una canalización de ingesta. Esta canalización requerirá 3 cosas: el punto final, (model_id), el input_field para el que desea crear vectores y el output_field en el que almacenar esos vectores. El primer comando siguiente creará una canalización de ingesta de inferencia, que usa el servicio de inferencia en segundo plano, y el segundo probará que la canalización funciona correctamente. Puede ver la salida esperada en el archivo 04-create-and-simulate-ingest-pipeline-output.json en la carpeta Salidas. 

Ahora está listo para agregar algunos documentos con los primeros 2 comandos a continuación y para probar que sus búsquedas funcionan con el 3er comando. Puede desproteger el resultado esperado en el archivo 05-bbq-index-output.json en la carpeta Salidas. 

Como se recomienda en esta publicación, se recomienda volver a puntuar y sobremuestrear cuando se escala a cantidades no triviales de datos porque ayudan a mantener una alta precisión de recuperación mientras se benefician de los beneficios de la compresión. A partir de la versión 8.18 de Elasticsearch, puedes hacerlo de esta manera usando rescore_vector. La salida esperada se encuentra en el archivo 06-bbq-search-8-18-output.json en la carpeta Outputs.

¿Cómo se comparan estos puntajes con los que obtendría por los datos sin procesar? Si vuelves a hacer todo lo anterior pero con index_options.type: hnsw, verás que los puntajes son muy comparables. Puede ver el resultado esperado en el archivo 07-raw-vector-output.json en la carpeta Salidas.

Números aproximados en las relaciones de compresión

Los requisitos de almacenamiento y memoria pueden convertir rápidamente en un desafío importante cuando se trabaja con la búsqueda vectorial. El siguiente desglose ilustra cómo las diferentes técnicas de cuantificación reducen significativamente la huella de memoria de los datos vectoriales.

Vectores (V)

Dimensiones (D)

sin procesar (V x P x 4)

int8 (V x (D x 1 + 4))

int4 (V x (D x 0.5 + 4))

asado (V x (D x 0.125 + 4))

10,000,000

384

14,31 GB

3,61 GB

1,83 GB

0,58 GB

50,000,000

384

71,53 GB

18,07 GB

9,13 GB

2,89 GB

100,000,000

384

143,05 GB

36,14 GB

18,25 GB

5,77 GB

Conclusión

BBQ es una optimización que puede aplicar a sus datos vectoriales para la compresión sin sacrificar la precisión. Funciona convirtiendo vectores en bits, lo que le permite buscar los datos de manera efectiva y le permite escalar sus flujos de trabajo de IA para acelerar las búsquedas y optimizar el almacenamiento de datos.

Aprendizaje adicional

Si está interesado en obtener más información sobre el asado, cerciorar de consultar los siguientes recursos:

• Cuantificación binaria (BBQ) en Lucene y Elasticsearch

• Mejor cuantización binaria (BBQ) frente a cuantificación de productos

• Cuantización escalar optimizada: cuantificación binaria aún mejor

• Mejor cuantificación binaria (BBQ): De bytes a BBQ, el secreto para una mejor búsqueda vectorial por Ben Trent

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.

Este blog explora cómo los grandes modelos de lenguaje (LLMs) pueden usar para identificar y generar sinónimos automáticamente, permitiendo que estos términos se carguen programáticamente en la API de sinónimos de Elasticsearch.

¿Cuándo usar sinónimos?

El uso de sinónimos puede ser una solución más rápida y rentable en comparación con la búsqueda vectorial. Su implementación es más sencilla ya que no requiere un conocimiento profundo de embeddings ni un proceso complejo de ingestión vectorial.

Además, el consumo de recursos es menor, ya que la búsqueda vectorial exige mayor capacidad de almacenamiento y memoria para incrustar, indexar y recuperar.

Otro aspecto importante es la regionalización de la búsqueda. Con los sinónimos, es posible adaptar términos según el idioma y las costumbres locales. Esto es útil en situaciones donde las incrustaciones pueden no coincidir con expresiones regionales o términos específicos de cada país. Por ejemplo, algunas palabras o siglas pueden tener significados diferentes según la región, pero los usuarios locales los tratan naturalmente como sinónimos. En Brasil, esto es bastante común. "Abacaxi" y "ananás" son la misma fruta (piña), pero el segundo término se usa más comúnmente en algunas regiones del noreste. De manera similar, el conocido "pão francês" en el sudeste puede ser conocido como "pão careca" en el noreste.

¿Cómo usar los LLMs para generar sinónimos?

Para obtener sinónimos automáticamente, podemos usar LLMs, que analizan el contexto de un término y sugieren variaciones apropiadas. Este enfoque permite expandir dinámicamente los sinónimos, cerciorando una búsqueda más amplia y precisa sin depender de un diccionario fijo.

En esta demostración, emplearemos un LLM para generar sinónimos de productos de comercio electrónico. Muchas búsquedas demuestran pocos o ningún resultado debido a las variaciones en los términos consultados. Con sinónimos, podemos resolver este problema. Por ejemplo, una búsqueda de "smartphone" puede abarcar diferentes modelos de teléfonos móviles, cerciorando que los usuarios encuentren los productos que buscan.

Prerrequisitos

Antes de empezar, necesitamos configurar el entorno y definir las dependencias necesarias. Emplearemos la solución proporcionada por Elastic para ejecutar Elasticsearch y Kibana localmente en Docker. El código estará escrito en Python, v3.9.6, con las siguientes dependencias:

Creación del índice de productos

Inicialmente, crearemos un índice de productos sin soporte de sinónimos. Esto nos permitirá validar consultas y luego compararlas con un índice que incluya sinónimos.

Para crear el índice, cargamos en masa un conjunto de datos de producto usando el siguiente comando en Kibana DevTools:

Generación de sinónimos con LLM

En este paso, emplearemos un LLM para generar sinónimos dinámicamente. Para lograrlo, integraremos la API de OpenAI, definiendo un modelo y un prompt apropiados. El LLM recibirá la categoría y el nombre del producto, cerciorando que los sinónimos sean relevantes en el contexto.

A partir del índice de productos creados, recuperaremos todos los artículos de la categoría "Electrónica" y enviaremos sus nombres al LLM. La salida esperada será algo así:

Con los sinónimos generados, podemos registrarlos en Elasticsearch usando la API de Sinónimos.

Gestión de sinónimos con la API de Sinónimos

La API de Sinónimos proporciona una forma eficiente de gestionar conjuntos de sinónimos directamente dentro del sistema. Cada conjunto de sinónimos consiste en reglas de sinónimos, donde un grupo de palabras se considera equivalente en las búsquedas.

Ejemplo de creación de un conjunto de sinónimos

Esto crea un conjunto llamado "mis-sinónimos-conjunto", donde "hola" y "hola" se tratan como equivalentes, así como "adiós" y "adiós".

Implementación de la creación de sinónimos para el catálogo de productos

A continuación se muestra el método responsable de construir un conjunto de sinónimos e insertarlo en Elasticsearch. Las reglas de sinónimos se generan a partir del mapeo de sinónimos sugerido por el LLM. Cada regla tiene un ID, correspondiente al nombre del producto en formato slug, y a la lista de sinónimos calculada por el LLM.

A continuación se muestra la carga útil de la solicitud para crear el conjunto de sinónimos:

Con el conjunto de sinónimos creado en el clúster, podemos pasar al siguiente paso, que es crear un nuevo índice con soporte de sinónimos usando el conjunto definido.

El código completo en Python con los sinónimos generados por LLM y la creación de conjuntos de sinónimos definida por la API de Sinónimos es el siguiente:

Creación de un índice con soporte de sinónimos

Se creará un nuevo índice donde todos los datos del índice de products serán reindexados. Este índice usará la synonyms_filter, que aplica la products-synonyms-set creada anteriormente.

A continuación se muestra el mapeo de índices configurado para usar sinónimos:

Reindexando el índice de products

Ahora, usaremos la API Reindex para migrar los datos del índice de products al nuevo índice de products_02 , que incluye soporte para sinónimos. El siguiente código se ejecutó en Kibana DevTools:

Tras la migración, el índice de products_02 estará llenado y listo para validar búsquedas usando el conjunto de sinónimos configurado.

Validación de la búsqueda con sinónimos

Comparemos los resultados de búsqueda entre los dos índices. Ejecutaremos la misma consulta en ambos índices y validaremos si los sinónimos se están empleando para obtener resultados.

Buscar en el índice de products (sin sinónimos)

Emplearemos a Kibana para realizar búsquedas y analizar los resultados. En el menú de Analítica > Descubrimiento, crearemos una Vista de Datos para visualizar los datos de los índices que creamos.

Dentro de Discovery, haz clic en Vista de datos y define un nombre y un patrón de índice. Para el índice de "productos", usaremos el patrón de "productos". Luego, repetiremos el proceso para crear una nueva Vista de Datos para el índice "products_02", usando el patrón "products_02".

Con las Vistas de Datos configuradas, podemos volver a Analytics > Discovery y comenzar las validaciones.

Aquí, tras seleccionar productos DataView y buscar el término "tablet", no obtenemos resultados, aunque sabemos que existen productos como "Kindle Paperwhite" y "Apple iPad Air".

Buscar en el índice de products_02 (sinónimos de soporte)

Al realizar la misma consulta en la Vista de Datos "products_synonyms", que soporta sinónimos, los productos se recuperaron con éxito. Esto demuestra que el conjunto de sinónimos configurado funciona correctamente, cerciorando que diferentes variaciones de los términos buscados devuelvan los resultados esperados.

Podemos lograr el mismo resultado ejecutando la misma consulta directamente en Kibana DevTools. Simplemente busca en el índice de products_02 usando la API de búsqueda de Elasticsearch:

Conclusión

La implementación de sinónimos en Elasticsearch mejoró la precisión y cobertura de las búsquedas en catálogos de productos. El diferenciador clave era el uso de un LLM, que generaba sinónimos automáticamente y contextualmente, eliminando la necesidad de listas predefinidas. El modelo analizó nombres y categorías de productos, cerciorando sinónimos relevantes para el comercio electrónico.

Además, la API de Sinónimos simplificó la gestión de diccionarios, permitiendo modificar dinámicamente los conjuntos de sinónimos. Con este enfoque, la búsqueda se volvió más flexible y adaptable a diferentes patrones de consulta de usuario.

Este proceso puede mejorar continuamente con nuevos datos y ajustes de modelos, cerciorando una experiencia de investigación cada vez más eficiente.

Referencias

Ejecuta Elasticsearch localmente

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

Sinónimos API

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

Hoy, anunciamos la disponibilidad general del nuevo modo de índice de Elasticsearch, logsdb, que reduce la huella de almacenamiento de los datos de registro hasta en un 65% en comparación con las versiones recientes de Elasticsearch sin logsdb. Esta mejora sustancial permite a los equipos de observabilidad y seguridad ampliar la visibilidad sin exceder su cotización, al tiempo que mantienen todos los datos accesibles de inmediato para su análisis.

Logsdb optimiza el ordenamiento de los datos, elimina la duplicación al reconstruir los valores de los campos no almacenados sobre la marcha con synthetic _source y mejora la compresión con algoritmos y códecs avanzados, lo que aprovecha el almacenamiento columnar dentro de Elasticsearch para un almacenamiento y recuperación de logs eficientes.

Mejora el análisis y reduce los costos mejorando la eficiencia del almacenamiento con el modo de índice logsdb

Los logs proporcionan señales críticas para detectar y remediar problemas de observabilidad y seguridad, y su utilidad está aumentando a medida que los avances en AI facilitan el análisis de datos basados en texto, por lo que el almacenamiento eficiente y el acceso de alto rendimiento son más importantes que nunca.

Lamentablemente, el creciente volumen de logs generado por la infraestructura y las aplicaciones está aumentando los costos, lo que obliga a compromisos que dificultan el análisis: limitar la recopilación, reducir la retención o relegar los datos nuevos a niveles de archivo en silos.

Logsdb aborda directamente estos desafíos. Con una mayor eficiencia de almacenamiento, puedes recopilar más datos y evitar la molestia del filtrado complicado de datos. Puedes conservar los logs por más tiempo para apoyar la búsqueda de amenazas, la respuesta a incidentes y los requisitos de cumplimiento. Y porque todos los datos siempre se pueden buscar, puedes obtener información rápida, sin importar cuánto crezca tu set de datos.

Innovación técnica detrás del modo de índice logsdb

El modo de índice de logsdb reduce drásticamente la huella de disco de los datos de logs con clasificación de índices inteligente, synthetic _source y compresión avanzada. Implementarlo puede reducir las necesidades de almacenamiento de logs hasta en un 65 %, en comparación con versiones recientes de Elasticsearch sin logsdb. Aunque logsdb actualmente utiliza más CPU durante la indexación, su almacenamiento eficiente reduce los costos generales para la mayoría de los clientes. Para los clientes que necesitan retención a largo plazo, esperamos reducciones del costo total de propiedad (TCO) de hasta un 50 %.

La clasificación inteligente de índices mejora la eficiencia del almacenamiento hasta en un 30% y reduce la latencia de las consultas en algunos conjuntos de datos de registro al ubicar datos similares muy juntos. De forma predeterminada, ordena los índices por host.name y @timestamp. Si los datos tienen campos más adecuados, puede especificarlos en su lugar.

La compresión avanzada reduce significativamente los requisitos de almacenamiento para datos con mucho texto, como registros a través de la compresión Zstandard (Zstd), la codificación delta, la codificación de longitud de ejecución y otros códecs inteligentes que se eligen automáticamente. Los valores de documento, que se almacenan en un formato de columnas optimizado para la compresión y el rendimiento, permiten el almacenamiento y la recuperación eficientes de valores de campo para ordenar, agregar y crear secuencias de comandos.

El _source sintético permite a las organizaciones recortar las necesidades de almacenamiento en otro 20-40% al descartar el campo _source y reconstruirlo total o parcialmente bajo demanda. Si bien la función a veces requiere más computación para la indexación y la recuperación, las pruebas muestran que ofrece mejoras medibles en la eficiencia neta. Synthetic _source se basa en casi dos años de uso de producción con métricas, con numerosas mejoras para los registros, incluida la compatibilidad con casi todos los tipos de campos.

Los ahorros de almacenamiento resultantes se propagan a través de las fases del ciclo de vida del índice. Una reducción del 65 % en el almacenamiento del nivel caliente tendrá como resultado la misma reducción en los niveles tibio, frío y congelado, así como reducirá el espacio ocupado para almacenar snapshots en el almacenamiento en cubetas.

No se compromete la visibilidad: Conservar todos los logs para la observabilidad y la seguridad

Los logs son la base de la visibilidad en la infraestructura y las aplicaciones, proporcionando la señal más simple y esencial para el monitoreo y la solución de problemas. Sin embargo, los costos aumentan a medida que crecen los volúmenes de logging. Este desafío está obligando a los clientes a implementar políticas complejas de filtrado y gestión, eliminar datos antes de tiempo y dejar los logs relevantes en almacenes que requieren de un día o más para rehidratarse antes del análisis. Sin un set de datos completo, fácil de buscar y accesible, encontrar y resolver problemas es sustancialmente más desafiante.

El modo de índice de Logsdb se basa en capacidades innovadoras de Elasticsearch, como snapshots con capacidad de búsqueda e importación automática , para abordar estos puntos débiles para los equipos de operaciones y seguridad:

Reducir costos: Logsdb reduce la huella de almacenamiento de los registros hasta en un 65%, lo que permite a las organizaciones reducir los gastos de almacenamiento mientras retienen más datos. Esto se traduce en ahorros de costos en todos los niveles de almacenamiento, desde caliente hasta congelado, y una mayor productividad para los equipos de observabilidad y seguridad que emplean estos datos.

Conserve los datos valiosos: Logsdb mantiene todos sus datos de registro y mejora la eficiencia operativa sin depender de herramientas adicionales o filtros complicados. Con características como la _source sintética, conserve el valor de los datos sin almacenar todo el documento de origen.

Ampliar visibilidad: Logsdb proporciona un acceso eficiente a todos los datos en una plataforma, sin aislamiento separado para la observabilidad, la seguridad y los datos históricos. Para los ingenieros de confiabilidad del sitio (SRE), acelera la resolución de problemas al permitir el análisis de registros junto con métricas, seguimientos y datos comerciales. Del mismo modo, para los equipos del centro de operaciones de seguridad (SOC), acelera la investigación y la corrección al eliminar los puntos ciegos.

Optimice el acceso a los datos: Logsdb permite a los equipos de SRE retener de manera eficiente datos procesables para la resolución de problemas, tendencias y análisis. Del mismo modo, los equipos de SOC pueden buscar rápidamente todos sus datos para la investigación y la búsqueda de amenazas sin incurrir en costos exorbitantes.

Logsdb está listo para su entorno

El modo de índice de logsdb de Elasticsearch está disponible de forma general para los clientes alojados y autogestionados de Elastic Cloud a partir de la versión 8.17 y está habilitado de forma predeterminada para los logs en Elastic Cloud Serverless.

Las capacidades básicas de logsdb (incluida la clasificación de índices inteligente y la compresión avanzada) están disponibles para organizaciones con licencias Estándar, Oro y Platino. Las capacidades completas de logsdb que reducen aún más los requisitos de almacenamiento (incluido synthetic _source) están disponibles para los clientes sin servidor y las organizaciones con una licencia Empresarial.

Elasticsearch logsdb en acción

Logsdb te permite mantener todos tus datos de logs y mejorar la eficiencia operativa sin limitar la recopilación, descartar o aislar datos. Con capacidades como la clasificación de índices inteligente, la compresión avanzada y synthetic _source, conserva y analiza los datos que necesitas dentro de un presupuesto que funcione para ti.

¿Quieres experimentarlo por ti mismo? Prueba Elastic sin costo.

El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a exclusivo criterio de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.

Muchos sitios web de comercio electrónico están interesados en mejorar su experiencia de búsqueda de recetas. La búsqueda semántica, cuando se aplica correctamente, permite a los clientes encontrar rápidamente los ingredientes necesarios basar en consultas más naturales, como "algo para Santo Valentín" o "comidas de Acción de Gracias".

En este artículo, demostraremos cómo usar Elasticsearch para implementar una búsqueda semántica que soporte este tipo de consultas. Configuraremos un índice para almacenar el catálogo de ingredientes y productos de un supermercado y demostraremos cómo este índice puede emplear para mejorar la búsqueda de recetas. A lo largo del artículo, explicaremos cómo crear esta estructura de datos y aplicar técnicas de procesamiento de lenguaje natural para proporcionar resultados relevantes alineados con la intención del cliente.

Todo el código presentado en este artículo fue desarrollado en Python y está disponible en GitHub. Puedes acceder al repositorio para revisar el código fuente, hacer ajustes según sea necesario e implementar las soluciones directamente en tu entorno de desarrollo.

Inicio de la implementación de la búsqueda semántica

Para empezar a implementar la búsqueda semántica, primero necesitamos definir el modelo del lenguaje natural. Elastic proporciona su propio modelo, ELSER, pero también ofrece soporte para integrar modelos de PLN de varios proveedores, como Hugging Face. Esta flexibilidad te permite elegir la opción que mejor se adapte a tus necesidades.

En este artículo, emplearemos ELSER, que reduce la complejidad de desplegar y gestionar modelos de PLN. Además, Elastic ofrece la función semantic_text , que simplifica mucho el proceso. Con semantic_text, todo el proceso de generación de incrustaciones se vuelve sencillo y automatizado. Simplemente necesitas definir un punto de inferencia y especificar el campo que recibirá las incrustaciones en tu mapeo de índice. Durante la indexación de documentos, se generarán incrustaciones que se asociarán automáticamente con el campo especificado.

Pasos de preparación

A continuación se muestran los pasos para crear un índice con soporte para búsqueda semántica. Siguiendo estas instrucciones, tendrás un índice configurado y listo para búsquedas semánticas:

1. Crea el punto de inferencia.

2. Crea el índice, configurando el campo de descripción como semantic_text para que pueda recibir las incrustaciones.

3. Indexa los datos en el índice de catálogos de supermercados, que almacenará un catálogo de productos. Este catálogo se obtuvo a partir de un conjunto de datos disponible aquí.

Aplicación de la búsqueda semántica en supermercados

Ahora que tenemos el índice lleno de datos de productos de supermercados, estamos probando y validando consultas para mejorar los resultados de búsqueda usando búsqueda semántica. Nuestro objetivo es ofrecer una experiencia de búsqueda más inteligente que entienda el contexto y la intención del usuario, ofreciendo resultados más relevantes y precisos.

Desafíos resueltos por la búsqueda semántica

Basándonos en el catálogo de productos, exploremos cómo la búsqueda semántica puede transformar la experiencia de búsqueda en supermercados abordando cuestiones de vocabulario y contexto con las que la búsqueda léxica tradicional a menudo tiene dificultades.

1. Interpretación de intenciones culinarias

Problema 01: Un cliente puede buscar "marisco para asar", pero un sistema de búsqueda léxica puede no comprender completamente la intención detrás de la consulta. Podría no identificar todos los productos de marisco aptos para asar, devolviendo solo aquellos con el término exacto "marisco" o "parrilla" en el título del producto.

Primero, realizaremos una búsqueda léxica y analizaremos los resultados. Luego, haremos lo mismo con una búsqueda semántica, comparando los resultados del mismo término de búsqueda.

Consulta de búsqueda léxica

Resultados:

Tipo de búsqueda

Nombre

Puntaje

Léxico

Pescado del Noroeste del Cangrejo de las Nieves Bairdi de Alaska

10.453125

Léxico

Salsa Gourmet original del señor Yoshida.

7.2289705

Léxico

Pack Premium de Mariscos - 20 piezas

7.1924105

Léxico

Pargo rojo americano - entero, de frente, limpiado

6.998647

Léxico

Pinzas y brazos de langosta, capturados en la naturaleza sostenible

6.438654

La búsqueda léxica demostró algunos productos de marisco aptos para asar, como el pargo rojo americano y el cangrejo de nieve bairdi de Alaska de pesca del noroeste. Sin embargo, la búsqueda léxica devolvía productos menos relevantes en la parte superior de la lista, como la salsa Mr. Yoshida, que no es un producto de marisco sino una salsa de carne, lo que sugiere que el algoritmo léxico tuvo dificultades para comprender completamente el contexto de "para asar".

Solución de búsqueda semántica

Empleamos una consulta que combina el término "marisco" con contextos de preparación como "asar" para devolver una lista completa de opciones, como filetes de pescado, gambas y vieiras, que son ideales para asar a la parrilla, aunque las palabras "parrilla" o "marisco" no aparezcan directamente en el nombre del producto. Esto cerciora que los resultados de búsqueda se alineen más estrechamente con la intención del cliente.

Consulta búsqueda semántica:

Tipo de búsqueda

Nombre

Puntaje

Semántica

Pescado branzino completamente de cabeza

16.175909

Semántica

Bacalao negro de Alaska (pez sable)

15.855331

Semántica

Pargo rojo americano - entero, de frente

15.454779

Semántica

Pescado del Noroeste del Cangrejo de las Nieves Bairdi de Alaska

15.855331

Semántica

Pargo rojo americano - entero, de frente

15.3892355

La búsqueda semántica no solo devolvía productos directamente relacionados con el término "marisco", sino que también entendía el contexto de "asar", sacando pescado entero y filetes adecuados para asar. La clave aquí es la precisión de los resultados, que incluían opciones de pescado entero como branzino y bacalao negro de Alaska, ambos comúnmente usados para asar a la parrilla.

Problema 02 : Muchos clientes buscan soluciones rápidas y fáciles para cenar tras un largo día de trabajo, usando términos como "comidas fáciles entre semana". La búsqueda léxica tradicional puede no captar completamente el concepto de comidas rápidas, ya que a menudo se centra solo en productos que incluyen la palabra "easy" en su nombre.

Como hicimos en el problema anterior, comenzaremos realizando una búsqueda léxica. Luego de eso, aplicaremos una solución usando búsqueda semántica.

Consulta de búsqueda léxica

Resultados:

Tipo de búsqueda

Nombre

Puntaje

Léxico

Etiquetas de dirección Avery Easy Peel, 4200

8.017723

Léxico

Omeals Comidas de Emergencia/Portátiles con Autocalentamiento 32

6.592727

Léxico

Pesquero costero atún amarillo en cubos

5.836883

Léxico

Espuma de 12 oz de súper peso

5.8116536

Léxico

Servilleta de Vanity Fair para el día a día, 2 capas, 110

5.752989

La búsqueda léxica devolvió resultados mucho menos relevantes, incluyendo elementos completamente ajenos a las comidas, como las etiquetas de dirección Avery Easy Peel y las servilletas cotidianas de Vanity Fair. Estos productos no satisfacen la necesidad del usuario de comidas rápidas. Aunque la búsqueda léxica sí devolvió un producto útil (Omeals Self Heating Emergency Meals), otros resultados, como servilletas y etiquetas, solo coincidían con las palabras "fácil" o "noche de semana" en sus descripciones, sin abordar realmente la intención del usuario de una solución de comida rápida.

Solución de búsqueda semántica

Implementamos una consulta que entiende la intención detrás de comidas rápidas y sencillas. Asocia productos que pueden preparar rápidamente, como carnes precocinadas, pasta congelada o kits de comida, aunque no incluyan explícitamente la palabra "fácil" en el nombre. Este enfoque garantiza que los clientes encuentren las opciones más adecuadas para cenas rápidas entre semana, atendiendo la necesidad de comodidad.

Consulta a la búsqueda semántica

Resultados:

Tipo de búsqueda

Nombre

Puntaje

Semántica

Omeals Comidas de Emergencia/Portátiles con Autocalentamiento 32

14.610006

Semántica

Nissin, Cup Noodles, Gambas, 2,5 oz

13.751424

Semántica

Mezcla de gofres y panqueques sin gluten de Namaste

13.73376

Semántica

Papa de Idaho, papa hashbrowns Golden Grill

12.549422

Semántica

Nissin, Fideos en Taza, Pollo, 24-Count

12.034527

La búsqueda semántica devolvió productos claramente relacionados con comidas rápidas y convenientes, como fideos instantáneos (Cup Noodles), papa precocinadas y mezclas para panqueques, que son opciones típicas para cenas fáciles entre semana. Esto demuestra que la búsqueda semántica puede captar el concepto detrás de la frase "comidas fáciles entre semana", captando la intención del usuario de encontrar comidas rápidas y convenientes. Curiosamente, productos de otras categorías, como "refrescos", también pueden incluir cuando sea relevante en el contexto (por ejemplo, bebidas para acompañar las comidas).

2. Términos regionales y variaciones de vocabulario

Problema: Un cliente puede buscar "refresco", mientras que otro cliente podría usar "refresco" para el mismo producto. La búsqueda léxica tradicional no reconoce que ambos términos se refieren al mismo elemento.

Consulta de búsqueda léxica

Resultados:

Tipo de búsqueda

Nombre

Puntaje

Léxico

Prime Hydration+ Sticks mezcla de bebidas electrolíticas

14.492869

Léxico

Capri Sun, 100% jugo, paquete variado

12.340851

Léxico

Bebida energética Joyburst, Frose Rose, 12

11.839179

Léxico

Kellogg's Pop-Tarts, canela glaseada con azúcar moreno

9.97788

Léxico

Mini barras Kind, pack variado, 0,7

9.336912

La búsqueda léxica se centra en coincidencias exactas de palabras. Aunque devolvió productos como Prime Hydration y Capri Sun, la coincidencia directa con el término "pop" también llevó a resultados irrelevantes, como los Kellogg's Pop-Tarts, que son un tentempié y no una bebida. Esto pone de manifiesto cómo la búsqueda léxica puede ser menos efectiva cuando un término tiene múltiples significados o puede ser ambiguo.

Solución de búsqueda semántica

En consultas semánticas, podemos superar el problema de las variaciones de vocabulario que la búsqueda léxica no aborda. Al ampliar los términos de búsqueda, podemos obtener resultados basados en el significado contextual, proporcionando respuestas más relevantes y completas.

Consulta:

Resultados:

Tipo de búsqueda

Nombre

Puntaje

Semántica

Variedad de refrescos Prebióticos de 12 oz de Olipop

14.776867

Semántica

Bai Antioxidant Cocofusion, Pack de variedades, 18

14.663253

Semántica

Bebida energética Monster, Zero Ultra, 24

14.486348

Semántica

Joyburst Variedad de Energía, 12 fl oz

14.007214

Semántica

Bebida energética Joyburst, Frose Rose, 12

13.641038

La búsqueda semántica devuelve productos que coinciden directamente con el concepto de "pop" como sinónimo de "refresco" (como Olipop Prebiotics Soda), aunque el término exacto "pop" no esté presente en el nombre del producto. La búsqueda entendió la intención del usuario — una bebida refrescante y baja en azúcar — y pudo devolver productos relevantes, incluyendo opciones como refrescos prebióticos (Olipop) y bebidas energéticas sin azúcar (Monster Energy Drink).

Conclusión

La implementación de la búsqueda semántica en el contexto de supermercados demostró ser muy eficaz para entender consultas complejas como "marisco para asar" y "comidas fáciles entre semana". Este enfoque nos permitió interpretar la intención del usuario con mayor precisión, devolviendo productos altamente relevantes.

Al usar Elasticsearch y simplificar el proceso con ELSER, pudimos aplicar la búsqueda semántica de forma rápida y eficiente, mejorando significativamente los resultados y proporcionando una experiencia de compra más ágil y dirigida. Esto no solo optimizó el proceso de búsqueda, sino que también aumentó la relevancia de los resultados ofrecidos a los clientes.

Referencias

Modelo ELSER:

https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference-api.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-elser.html

Texto semántico:

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-text.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

Conjunto de datos:

https://www.kaggle.com/datasets/bhavikjikadara/grocery-store-dataset?select=grocerydataset.csv

Búsqueda semántica:

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search-semantic-text.html