Cómo MATCH y TO_TEXT habilitan la búsqueda de texto completo en cualquier expresión ES|QL

Empecemos con una búsqueda que era imposible en Elasticsearch 9.4, que usa el comando EVAL:

En este ejemplo, no tiene una configuración de mapeo ni de analizador. Tampoco está asociado con ningún índice invertido. Solo existe durante la vida útil de esta búsqueda, pero ahora puedes realizar una búsqueda de todos modos. Dos adiciones hacen que esto funcione.

Primero, MATCH ahora acepta cualquier expresión como su primer argumento, no solo un campo mapeado. Eso incluye las columnas producidas por EVAL y los resultados de funciones utilizados en línea. También incluye campos no mapeados cargados directamente desde el documento original. Además, todos los tipos de datos normalmente aceptados por MATCH son compatibles en este nuevo caso de uso.

La segunda parte de esto es la nueva función TO_TEXT, que es la primera función de conversión ES|QL que produce la salida de tipo texto. Hasta ahora, las columnas de texto solo podían provenir de campos indexados y mapeados, y todos los textos producidos por las expresiones ES|QL eran valores de palabras clave en lugar de texto. La distinción es importante porque MATCH trata ambos de forma diferente: se analizan los valores de texto, mientras que los valores de palabras clave se comparan exactamente, reflejando cómo una búsqueda MATCH en un campo de palabra clave indexado se reescribe en una búsqueda de término. TO_TEXT(x) es la forma de indicarle a ES|QL: trata esta cadena como texto completo.

Esto se envía como una vista previa técnica en Elasticsearch 9.5 y, como tal, tiene algunas limitaciones:

• Actualmente solo está filtrando. Una coincidencia en una expresión aún no contribuye a la puntuación de relevancia; solo las coincidencias en los campos indexados afectan la puntuación.

• Las opciones de búsqueda, como la imprecisión y otras, aún no son compatibles al hacer coincidir una expresión.

• El texto en tiempo de ejecución se analiza con el analizador estándar. Esto aún no es configurable.

Se está trabajando para solucionar estas limitaciones.

¿Por qué usar la búsqueda de texto completo en lugar de LIKE o RLIKE en ES|QL?

ES|QL ya tenía dos formas de búsqueda de textos sin índice: LIKE (patrones comodines) y RLIKE (expresiones regulares). Ambos funcionan en cualquier expresión de texto, así que es justo preguntar qué agrega MATCH. La respuesta es el análisis, una forma más avanzada de búsqueda que emplea técnicas como el stemming y los sinónimos. También usa la eliminación de palabras vacías.

LIKE es una simple coincidencia de subcadenas, sin ninguna comprensión de las palabras que componen un texto. Digamos, por ejemplo, que estás buscando mensajes de log sobre un oso:

Esto no detecta “Oso avistado cerca del gallinero” por la mayúscula, mientras que sí coincide con “Un resultado fabuloso para la competencia”, que no tiene nada que ver con un oso. Falla en ambas direcciones: hay falsos negativos por la mayúscula y falsos positivos por subcadenas escondidas dentro de otras palabras.

Las expresiones regulares pueden solucionar el problema de las mayúsculas y minúsculas, pero el problema de los límites de las palabras se complica rápidamente. Algo como:

Y ni siquiera así queda bien. No detecta un oso al final de una oración seguido de ¡ o ¿, y no dice nada sobre tabulaciones, comillas o paréntesis. Cada arreglo hace que el patrón sea más largo, y la próxima persona que lea la búsqueda tiene que hacer ingeniería inversa para entender qué es lo que realmente hace.

MATCH hace que el problema desaparezca, porque ejecuta tanto la búsqueda como el valor a través de un analizador, que tokeniza el texto en términos en minúsculas y luego compara término con término:

Esta búsqueda coincidirá con valores como “El rápido oso pardo” y “OSO avistado cerca del gallinero”, pero no con “Un resultado hermoso para la competencia” ni “Protocolo OSOBUCO habilitado”, sin importar la puntuación que rodee a las palabras. Por supuesto, todo esto también funciona con búsquedas de varios términos, como MATCH(TO_TEXT(message), “oso pardo”), tal como uno esperaría.

Se está trabajando para habilitar el uso de los 36 analizadores de lenguaje, con soporte para lenguajes naturales en datos que nunca fueron indexados ni mapeados.

Casos de uso de búsqueda de texto completo para datos no indexados y no mapeados

Los ejemplos anteriores buscaron valores calculados a partir de campos mapeados. Los casos de uso más interesantes para ES|QL MATCH en expresiones involucran datos que nunca se pudieron buscar en absoluto. Vamos a repasar algunos.

Cómo buscar campos sin mapeo en ES|QL sin agregar un mapeo

A veces dejas deliberadamente un campo fuera de tus mapeos, como un rastreo de pila verboso o una carga útil de solicitud sin procesar. Incluso podrías omitir un bloque de depurar. Indexar uno de estos campos costaría espacio en disco y memoria heap en cada documento, y no valdría la pena para un campo que quizás consultes una vez al trimestre.

Esa decisión siempre ha sido definitiva, porque los campos no mapeados eran invisibles para las búsquedas por completo. En Elasticsearch 9.5, puedes usar SET unmapped_fields="load" para hacer que ES|QL cargue campos no mapeados directamente desde el documento de origen como palabras clave. Sigue envolviéndolo en TO_TEXT, y ahora puedes ejecutar una búsqueda de texto completo en él:

Aquí, stack_trace nunca se mapeó. Cada valor se obtiene de los documentos originales y se analiza sobre la marcha. Están emparejados fila por fila. Eso es un trabajo real, y nunca será tan rápido como una búsqueda de índice invertido. Pero ahora, ese campo que no indexaste ya no es inbuscable. Puedes mantener el mapeo pequeño para el caso cotidiano y seguir respondiendo a la pregunta de una vez por trimestre cuando importa.

Búsqueda de texto completo en un campo de palabras clave sin reindexar

Los campos de palabras clave pueden hacer mucho. Dan coincidencias exactas, agregaciones rápidas y clasificación, razón por la cual tantos campos terminan mapeados de esa manera. Pero los mapeos se deciden cuando llegan los datos, y es fácil terminar en una situación en la que quieres hacer algo diferente con tus datos de lo que originalmente pretendías. Quizás product_name se mapeó como palabra clave porque los paneles de control agregan datos en función de ella, y luego de recibir datos de productos de un año, alguien quiere poder buscar dentro de los valores de product_name.

La respuesta antigua era cambiar el mapeo a texto (o agregar campos múltiples) y reindexar todo. Esto puede llevar mucho tiempo y ser costoso, y en muchos casos, los usuarios simplemente no querrán molestarse con ello. La nueva respuesta es una llamada a una función:

TO_TEXT convierte los valores de las palabras clave en texto sobre la marcha, así que MATCH los analiza en vez de compararlos exactamente. Esto te permite consultar un campo de palabra clave sin crear un mapeo o reindexar el documento de origen. Si la búsqueda se convierte en una búsqueda cotidiana, indexar el campo como texto sigue siendo el movimiento correcto a largo plazo, pero TO_TEXT te da una respuesta hoy, sin ningún trabajo adicional.

Buscar el mismo campo en los índices con diferentes mapeos

ES|QL puede abarcar muchos índices, y el mismo campo no tiene por qué verse siempre igual en todos. Cuando el mismo campo tiene diferentes tipos en distintos índices, ES|QL lo trata como un tipo de unión, y una función de conversión resuelve el conflicto. Consideremos un ejemplo en el que el campo message tiene tipo texto en la plantilla de índice de este año, pero era tipo palabra clave en la del año pasado:

Cada valor se analiza en el momento de la búsqueda, ya sea que provenga del índice de texto o del de la palabra clave. Los valores de palabra clave de los índices más antiguos se tokenizan y convierten a minúsculas como todo lo demás, así que “connection reset” encuentra “Connection RESET by peer”, sin importar en qué índice se encuentre.

Otro caso interesante es cuando un campo está mapeado en un solo índice pero también presente (y no mapeado) en el otro:

Hay un matiz que vale la pena destacar aquí. Si error_details está mapeado en logs-2026 pero no en logs-2025, Elasticsearch no puede enviar esta búsqueda a Lucene, porque los índices donde el campo no está mapeado no devolverían coincidencias silenciosamente. En cambio, el planificador se da cuenta de que el campo está potencialmente no mapeado y evalúa todo MATCH fila por fila, de donde provengan las filas. No es necesario que sepas en cuál de tus índices está mapeado el campo; la búsqueda simplemente responde a la pregunta.

Cómo ES|QL analiza el texto en tiempo de búsqueda sin un índice invertido

Cuando ES|QL planifica un MATCH contra una expresión, analiza el texto de búsqueda una vez, de antemano, en un conjunto de términos. La forma en que se evalúa cada fila depende del tipo de expresión:

Tipo de expresión

Procesamiento

Comportamiento de coincidencia

texto (mediante TO_TEXT)

El analizador tokeniza el valor en términos en minúsculas

Comparación token-contra-token; una fila coincide si cualquier token es igual a cualquier término de búsqueda (O semántica)

palabra clave, ip, fecha, numérico

Sin análisis; constante de búsqueda convertida una vez al tipo nativo

Comparación exacta por fila

Ambas rutas eluden Lucene por completo y evalúan los valores fila por fila. La ruta no textual refleja exactamente lo que hace una búsqueda de coincidencia cuando se delega a Lucene contra esos tipos de campo, por lo que la semántica sigue siendo consistente independientemente de si la búsqueda llega a un índice.

Una búsqueda de índice invertido hace su trabajo en el momento de la ingesta, y nunca procesa documentos que no coinciden en el momento de la búsqueda. Un MATCH en tiempo de ejecución realiza ese análisis en el momento de la búsqueda, por cada fila que llega a él. Uno es rápido porque el trabajo ya ocurrió; el otro es flexible porque los datos no necesitan haber sido indexados en absoluto.

¿Qué novedades hay para la búsqueda de texto completo en ES|QL?

Todo lo que se menciona en esta publicación es la primera entrega de un esfuerzo mayor para lograr que la búsqueda en ES|QL funcione con cualquier tipo de contenido, no solo con lo que se indexó previamente. Las limitaciones señaladas anteriormente se abordan de forma activa, y la roadmap va más allá:

• Puntuación. Las coincidencias en tiempo de ejecución contribuirán a _score, por lo que puedes ordenar por relevancia incluso cuando los datos nunca se indexaron.

• MATCH_PHRASE en las expresiones. Ya disponible en Elastic Cloud Serverless, y llegará a Elastic Stack en la versión 9.6.

• Analizadores configurables. Compatibilidad del analizador con MATCH y MATCH_PHRASE en expresiones, lo que permite el uso de analizadores de lenguaje, derivación y sinónimos en el momento de la búsqueda.

• Opciones de coincidencia. Opciones como la coincidencia inexacta y el operador para coincidencias en tiempo de ejecución.

• Búsqueda vectorial. Generar incrustaciones por fila y ejecutar kNN (vecinos más cercanos) en expresiones dense_vector en tiempo de ejecución, llevando también la búsqueda semántica a datos no indexados.

Prueba la búsqueda de texto completo ES|QL en expresiones hoy

Puedes probar la búsqueda en tiempo de ejecución hoy mismo. Ya está disponible en Elastic Cloud Serverless, donde las nuevas capacidades de ES|QL llegan primero y se lanza como vista previa técnica en Elasticsearch 9.5. Comienza con la referencia de funciones de búsqueda y consulta la página de limitaciones de ES|QL para conocer los límites actuales. Es una vista previa técnica porque queremos tus comentarios: si realizas una búsqueda de algo que nunca fue indexado y te sorprende, ya sea positiva o negativamente, nos encantaría saberlo.

Novedades en la creación del dashboard de IA de Kibana

Capacidad

Vista previa técnica (9.4)

GA (9.5)

Manejo de errores

No se permiten reintentos en consultas ES|QL fallidas

Reintento automático hasta tres veces con inspección y ajuste de consultas

Costo de generación de ES|QL

Todas las consultas enrutadas a través del modelo principal

Enrutamiento por niveles, hasta 5 veces más económico

Intervalo de tiempo

Ventana predeterminada fija

Selección automática basada en la distribución temporal de los datos

Controles de filtro

Sin soporte

Se agrega automáticamente para los campos más relevantes

Gráficos de Vega-Lite

Sin soporte

Creación en lenguaje natural, incluyendo gráficos de dispersión, gráficos de caja, formato condicional, sugerencias de herramientas personalizadas

Edición de gráficos

Sin soporte

Edita paneles Vega-Lite existentes a través del lenguaje natural

Recuperación automática de errores para la generación del dashboard de IA

En la versión preliminar técnica, el agente no volvió a intentar las consultas ES|QL fallidas. En la versión 9.5, detecta errores de consulta y vuelve a intentarlo hasta tres veces, inspeccionando cada error y ajustando la consulta antes de darte por vencido. En la práctica, esto elimina la mayoría de los problemas de paneles vacíos y produce dashboards que se renderizan correctamente en el primer intento.

¿Por qué es más barato crear dashboards con IA en Elastic 9.5?

No todos los pasos en la generación del dashboard requieren el mismo nivel de razonamiento. En la versión 9.5, la generación de ES|QL emplea un modelo más ligero de manera predeterminada y solo recurre al modelo principal cuando es necesario. Si tu conector emplea Claude Opus 4.8 de Anthropic, eso significa que la generación de ES|QL será 5 veces más económica en todos los paneles.

Selección automática de intervalos de tiempo basada en tus datos

Los dashboards solo son útiles cuando muestran la ventana de datos correcta. El agente ahora aplica una lógica mejorada para elegir un intervalo de tiempo que tenga sentido para los datos que está consultando, a menos que el usuario solicite un intervalo de tiempo específico. Considera la distribución temporal de los datos y ajusta en consecuencia, ya sea la última hora para un incidente en tiempo real o los últimos 90 días para un análisis de tendencias, en lugar de recurrir de manera predeterminada a una ventana fija.

Control automático de filtros en dashboards generados por IA

La creación de dashboards ahora admite controles; es decir, filtros interactivos que permiten a los usuarios refinar un dashboard por valores de campo sin editar las consultas subyacentes. Al generar un dashboard, el agente agrega automáticamente controles en la parte superior para los campos más relevantes para filtrar.

Gráficos Vega-Lite de lenguaje natural: tipos de gráficos y formato más allá de los valores predeterminados

Vega y Vega-Lite admiten una amplia variedad de tipos de gráficos y personalizaciones en Kibana. Con 9.5, puedes construirlos a partir de un lenguaje sencillo en lugar de escribir el código tú mismo. 

Gráficos de dispersión, gráficos de caja y más tipos de gráficos Vega-Lite

Los diagramas de dispersión, diagramas de caja, múltiplos pequeños facetados, gráficos de burbujas y diagramas de composición (como combinar histogramas con mapas de calor), entre muchos otros, se admiten en Vega-Lite. Una indicación como Muéstrame un gráfico de dispersión del tiempo de respuesta frente al tamaño de la solicitud, coloreado por nombre de servicio, produce un panel Vega-Lite con los mapeos de datos correctos. Usan las paletas de colores predeterminadas de Kibana para combinarse con el resto del dashboard.

Formato condicional, información sobre herramientas personalizadas y etiquetas en gráficos estándar

Incluso para tipos de gráficos que ya son nativos de los dashboards, como barra, línea o área, a veces necesitas más control del que ofrecen las capacidades predeterminadas. Vega-Lite, a través del chat, cubre esa necesidad. Algunos ejemplos incluyen:

• Formato de color condicional: colorea los puntos de datos por encima de un umbral de manera diferente; por ejemplo, marca en rojo los puntos de datos en una línea o barras cuando alguna métrica supera tu objetivo de nivel de servicio (SLO). Pregúntale al agente algo como Marca en rojo cualquier punto por encima de 500 ms para mi gráfico de líneas.

  

• Marcas y etiquetas personalizadas: agrega emojis, símbolos o etiquetas de texto en línea a los puntos de datos para obtener indicadores de estado de un vistazo.

  

• Información sobre herramientas personalizada: enriquece los estados del cursor con métricas adicionales, contexto o valores calculados que no forman parte de los ejes del gráfico. Pregunta algo como Agrega una descripción emergente que muestre el total de registros y el porcentaje por barra.

  

Esto también funciona para editar gráficos de Vega existentes. Si tienes un panel Vega-Lite que necesita un ajuste como cambiar una escala de color, ajustar un eje o cambiar el tipo de marca, describe el cambio en el chat en lugar de indagar en el código JSON.

Cómo construimos la generación en lenguaje natural de Vega-Lite en Kibana

Generar un gráfico Vega-Lite a partir de una oración no es una simple indicación de solicitud JSON al modelo. Construimos un pequeño pipeline agéntico que convierte la intención del lenguaje natural en un gráfico validado y respaldado por datos.

Cuando llega una solicitud, el agente primero determina si Vega-Lite es la opción adecuada. Para las solicitudes de Vega-Lite, establece la visualización en una consulta ES|QL real contra Elasticsearch y luego usa un modelo para generar el código Vega-Lite. Antes de renderizar, el resultado pasa por una capa de normalización que corrige el esquema y vincula la consulta canónica. También aplica transformaciones de seguridad de renderizado.

Algunas decisiones de diseño hacen que este flujo de trabajo sea confiable:

• Llamadas a herramientas tipificadas: la creación de gráficos es una invocación de herramienta estructurada en lugar de Vega-Lite de forma libre pegada en la conversación.

• Generación con restricciones: el modelo genera código Vega-Lite dentro de un esquema definido, haciendo que la salida sea más previsible y fácil de validar.

• Ejemplos seleccionados: los patrones estructurales, como el facetado, las marcas superpuestas y los mapas de calor, proporcionan orientación sin copiar los datos subyacentes.

• Ejecutar y verificar bucles: las consultas se ejecutan antes de la creación de gráficos y los errores de validación desencadenan reintentos correctivos para la generación de ES|QL.

Prueba la creación de dashboard con IA y gráficos Vega-Lite en Kibana

Para probar la creación de dashboards en lenguaje natural y gráficos Vega-Lite, actualiza a Elastic 9.5 (o inicia una prueba gratis), y abre el chat en Kibana. Luego pídele que cree un dashboard a partir de tus datos. Para Vega-Lite, intenta pedir un tipo de gráfico que hayas querido pero que nunca hayas construido, como un diagrama de dispersión o un gráfico de burbujas. Si el resultado no es del todo correcto, dile al agente qué cambiar. El agente itera contigo.

Esto requiere una licencia Empresarial. Comencemos.

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 alguna característica o funcionalidad que no esté disponible en este momento no se lance a tiempo o no se lance en absoluto.

Tu primera búsqueda

Comienza por definir un objeto CLR (POCO) simple que se mapea a tu índice de Elasticsearch. Los nombres de las propiedades se resuelven a nombres de columnas ES|QL a través de atributos System.Text.Json estándar, como [JsonPropertyName], o a través de un JsonNamingPolicy configurado. Las mismas reglas de serialización de origen que se aplican en el resto del cliente también se aplican aquí.

Con el tipo ya definido, una consulta se ve así:

El proveedor traduce esto al siguiente ES|QL:

Algunos detalles a tener en cuenta:

• Resolución de nombres de propiedades: p.Price se vuelve price_usd debido al atributo [JsonPropertyName], y p.Brand se convierte en brand siguiendo la política predeterminada de nombres camelCase.

• Captura de parámetros: Las variables C# minPrice y brand se capturan como parámetros nombrados (?minPrice, ?brand). Se envían por separado del texto de búsqueda en la carga útil JSON, lo que previene la inyección y habilita el almacenamiento en caché del plan de búsqueda del lado del servidor.

• Streaming: QueryAsync<T> devuelve IAsyncEnumerable<T>. Las filas se materializan una a la vez a medida que llegan desde Elasticsearch.

También puedes inspeccionar la búsqueda generada y sus parámetros sin ejecutarla:

¿Cómo funciona esto? Un repaso rápido de LINQ

El mecanismo que hace posibles los proveedores LINQ es la distinción entre IEnumerable<T> y IQueryable<T>.

Cuando llamas a .Where(p => p.Price > 100) en un IEnumerable<T>, la lambda se compila en un Func<Product, bool>, un delegado común que el runtime ejecuta en proceso. Esto es LINQ a objetos.

Cuando llamas al mismo método en un IQueryable<T>, el compilador de C# encapsula la expresión lambda en un Expression<Func<Product, bool>> en su lugar. Esta es una estructura de datos que representa la estructura del código en lugar de su forma ejecutable. El árbol de expresión puede inspeccionarse, analizarse y traducirse a otro idioma en tiempo de ejecución.

La interfaz IQueryProvider es el punto de extensión. Cualquier proveedor puede implementar CreateQuery<T> y Execute<T> para traducir estos árboles de expresiones a un idioma destino. Entity Framework usa esto para emitir SQL. El proveedor de LINQ a ES|QL lo usa para emitir ES|QL.

El árbol de expresión para la búsqueda anterior se ve así:

Árbol de expresiones para la búsqueda de ejemplo.

El árbol está anidado al revés: Take envuelve OrderByDescending, que envuelve Where, que envuelve From, que envuelve la constante raíz EsqlQueryable<Product>. El predicado Where es en sí mismo un subárbol de BinaryExpression nodos para los operadores &&, >= y ==, con MemberExpression hojas para accesos a propiedades y capturas de cierre para las variables minPrice y brand. Esta es la estructura de datos que el proveedor recorre para producir el ES|QL final.

En detalle: el pipeline de traducción

La ruta de una expresión LINQ a los resultados de la búsqueda sigue un pipeline de seis etapas:

Visión general del pipeline de traducción.

1. Captura del árbol de expresiones

Cuando se encadenan .Where(), .OrderBy(), .Take() y otros operadores en un IQueryable<T>, la infraestructura LINQ estándar crea un árbol de expresiones. EsqlQueryable<T> implementa IQueryable<T> y delega a EsqlQueryProvider.

2. Traducción

Cuando se ejecuta la búsqueda (al enumerar, llamar a ToList() o usar await foreach), EsqlExpressionVisitor recorre el árbol de expresiones de adentro hacia afuera. Envía cada llamada al método LINQ a un visitante especializado:

Visitante

Traduce

En

whereClauseVisitor

.Where(predicado)

Condición WHERE

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

GroupByVisitor

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

Campo SORT [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, métodos de texto

Más de 80 funciones ES|QL

Durante la traducción, las variables de C# a las que se hace referencia en las expresiones se capturan como parámetros con nombre.

3. Modelo de búsqueda

Los visitantes no producen textos directamente. En cambio, producen objetos QueryCommand, una representación intermedia inmutable. Un FromCommand, un WhereCommand, un SortCommand y un LimitCommand, cada uno representa un comando de procesamiento de ES|QL. Estos se recopilan en un modelo EsqlQuery.

Modelo de búsqueda y patrón de comandos.

Este modelo intermedio está desacoplado tanto del árbol de expresiones como del formato de salida. Se puede inspeccionar, interceptar (vía IEsqlQueryInterceptor) o modificar antes de dar formato.

4. Formato

EsqlFormatter visita cada QueryCommand en orden y produce el texto final de ES|QL. Cada comando se convierte en una línea, separada por el operador de barra vertical (|) que ES|QL usa para encadenar comandos de procesamiento. Los identificadores que contienen caracteres especiales se escapan automáticamente con comillas invertidas.

5. Ejecución

El texto ES|QL formateado y los parámetros capturados se envían al endpoint /_query de Elasticsearch como carga útil JSON. La interfaz IEsqlQueryExecutor abstrae la capa de transporte, que es donde entra en juego la arquitectura de paquetes en capas.

6. Materialización

EsqlResponseReader transmite la respuesta JSON sin almacenar en memoria todo el conjunto de resultados. Un árbol ColumnLayout, precomputado una vez por búsqueda, mapea nombres de columnas planas de ES|QL (como address.street, address.city) a propiedades anidadas de POCO. Cada fila se ensambla en una instancia T y se genera una a la vez a través de IEnumerable<T> o IAsyncEnumerable<T>.

La arquitectura en capas

La funcionalidad de LINQ a ES|QL se divide en tres paquetes:

Arquitectura de paquetes. Elastic.Esql es el motor puro de traducción. No tiene dependencias HTTP y contiene los visitantes de expresiones, el modelo de búsqueda, el formateador y el lector de respuestas. Puedes usarlo de forma independiente para crear e inspeccionar búsquedas de ES|QL sin una conexión de Elasticsearch, lo que es útil para pruebas, logging de búsquedas o para crear tu propia capa de ejecución.

Elastic.Clients.Esql es un cliente ES|QL ligero e independiente. Añade ejecución HTTP sobre Elastic.Esql a través de Elastic.Transport. Si tu aplicación solo necesita ES|QL y ninguna de las otras API de Elasticsearch, esta es la opción de dependencia mínima.

Elastic.Clients.Elasticsearch es el cliente completo de Elasticsearch .NET. También se basa en Elastic.Esql y expone al proveedor LINQ a través del espacio de nombres client.Esql. Este es el punto de entrada recomendado para la mayoría de las aplicaciones.

Ambos paquetes de capa de ejecución proporcionan su propia implementación de IEsqlQueryExecutor, la interfaz estratégica que une la traducción y el transporte.

Los tres paquetes son compatibles con Native AOT cuando se usan con un JsonSerializerContext generado por el código fuente. Para el cliente completo, consulta la documentación de Native AOT.

Mas allá de los conceptos básicos

El ejemplo anterior cubrió el filtrado, la clasificación y la paginación. El proveedor admite un conjunto más amplio de operaciones.

Agregaciones

GroupBy, combinado con funciones agregadas en Select, se traduce a ES|QL STATS ... BY:

Proyecciones

Select, con tipos anónimos genera comandos EVAL, KEEP, y RENAME:

Biblioteca de funciones enriquecida

Hay más de 80 funciones ES|QL disponibles a través de la clase EsqlFunctions, que abarcan fecha/hora, texto, matemáticas, IP, coincidencia de patrones y puntuación. También se traducen los métodos estándar Math.* y string.*:

LOOKUP JOIN

Las consultas cruzadas de índices se traducen a ES|QL LOOKUP JOIN:

Acceso directo a ES|QL sin procesar

Para las características de ES|QL que aún no están cubiertas por el proveedor de LINQ, puedes anexar fragmentos sin procesar:

Búsquedas asíncronas del lado del servidor

Para búsquedas de ejecución prolongada, envíalas para procesamiento en segundo plano en el servidor:

Las búsquedas asíncronas del lado del servidor son especialmente útiles para búsquedas analíticas de larga duración/procesamiento de grandes sets de datos que pueden superar los umbrales típicos de tiempo de espera, o en entornos sensibles al tiempo de espera con balanceadores de carga, gateways API o proxies que imponen tiempos de espera HTTP estrictos. Las búsquedas asíncronas evitan las caídas de conexión al separar el envío de la solicitud de la recuperación de los resultados.

Primeros pasos

LINQ a ES|QL está disponible a partir de:

• Elastic.Clients.Elasticsearch v9.3.4 (rama 9.x)

• Elastic.Clients.Elasticsearch v8.19.18 (rama 8.x)

Instalar desde NuGet:

dotnet add package Elastic.Clients.Elasticsearch

Los puntos de entrada están en client.Esql:

Método

Devuelve

Caso de uso

Query<T>(...)

IEnumerable<T>

Ejecución sincrónica

QueryAsync<T>(...)

IAsyncEnumerable<T>

Transmisión asíncrona

CreateQuery<T>()

IEsqlQueryable<T>

Composición e inspección avanzadas

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

Búsquedas de larga ejecución del lado del servidor

Para consultar la referencia completa de características, incluidas las opciones de búsqueda, el acceso a múltiples campos, los objetos anidados y el manejo de campos de valores múltiples, consulta la documentación de LINQ a ES|QL.

Conclusión

LINQ a ES|QL aporta toda la expresividad de LINQ de C# al lenguaje de búsqueda ES|QL de Elasticsearch, lo que te permite realizar búsquedas con tipado fuerte y combinables sin crear manualmente cadenas de texto. Con captura automática de parámetros, materialización de streaming y una arquitectura de paquetes en capas que escala desde el paquete de traducción autónomo hasta el cliente completo de Elasticsearch, se adapta naturalmente a aplicaciones .NET de cualquier tamaño. Instala el cliente más reciente, dirige tus expresiones LINQ a un índice y deja que el proveedor se encargue del resto.

¿Por qué importa esto?

La mayoría de los flujos de trabajo analíticos típicos acaban reduciéndose a agrupar datos. Ya sea para calcular el promedio de bytes por host, contar eventos por usuario o agregar métricas en diferentes dimensiones, la operación de núcleo es la misma: asignar claves a grupos y actualizar los agregados en ejecución.

A pequeña escala, casi cualquier tabla hash razonable funciona bien. A gran escala (cientos de millones de documentos y millones de grupos distintos), los detalles empiezan a importar. Los factores de carga, la estrategia de sondeo, el diseño de la memoria y el comportamiento de la memoria caché pueden marcar la diferencia entre un rendimiento lineal y una barrera de fallos de caché.

Elasticsearch ha soportado estas cargas de trabajo durante años, pero siempre estamos buscando oportunidades para modernizar los algoritmos de núcleo. Por lo tanto, evaluamos un enfoque más reciente inspirado en las tablas suizas y lo aplicamos a cómo ES|QL calcula las estadísticas.

¿Qué son realmente las tablas suizas?

Las tablas suizas son una familia de tablas hash modernas popularizadas por la SwissTable de Google y posteriormente adoptadas en Abseil y otras bibliotecas.

Las tablas hash tradicionales pasan mucho tiempo persiguiendo punteros o cargando claves solo para descubrir que no coinciden. La característica definitoria de las tablas suizas es la capacidad de rechazar la mayoría de las sondas usando una pequeña estructura de matriz residente en caché, almacenada separadamente de las claves y valores, llamadas bytes de control, para reducir significativamente el tráfico de memoria.

Cada byte de control representa un solo slot y, en nuestro caso, codifica dos cosas: si el slot está vacío y una huella corta derivada del hash. Estos bytes de control están dispuestos de forma continua en la memoria, típicamente en grupos de 16, lo que los hace ideales para el procesamiento de una sola instrucción y múltiples datos (SIMD).

En lugar de sondear una ranura a la vez, las tablas suizas escanean todo un bloque de bytes de control utilizando instrucciones vectoriales. En una sola operación, la CPU compara la huella digital de la clave entrante con 16 ranuras y filtra las entradas vacías. Solo los pocos candidatos que sobreviven a esta ruta rápida requieren cargar y comparar las claves reales.

Este diseño intercambia una pequeña cantidad de metadatos adicionales por una mejor localización de caché y muchas menos cargas aleatorias. A medida que la tabla crece y las cadenas de sonda se alargan, esas propiedades se vuelven cada vez más valiosas.

SIMD en el centro

La verdadera estrella del espectáculo es SIMD.

Los bytes de control no solo son compactos, sino que también están diseñados explícitamente para ser procesados con instrucciones vectoriales. Una sola comparación SIMD puede verificar 16 huellas dactilares a la vez, lo que convierte lo que normalmente sería un bucle en un puñado de operaciones amplias. Por ejemplo:

En la práctica, esto significa:

• Menos ramas.

• Cadenas de sondeo más cortas.

• Menos cargas de la memoria de claves y valores.

• Mucho mejor utilización de las unidades de ejecución de la CPU.

La mayoría de las búsquedas nunca pasan del escaneo de bytes de control. Cuando lo hacen, el trabajo restante es enfocado y previsible. Este es precisamente el tipo de carga de trabajo en el que destacan las CPU modernas.

SIMD bajo el capó

Para los lectores a quienes les gusta echar un vistazo por dentro, aquí está lo que sucede al insertar una nueva clave en la tabla. Utilizamos la API Panama Vector con vectores de 128 bits, por lo que opera en 16 bytes de control en paralelo.

El siguiente fragmento muestra el código generado en un Intel Rocket Lake con AVX-512. Aunque las instrucciones reflejan ese entorno, el diseño no depende de AVX-512. Las mismas operaciones vectoriales de alto nivel se emiten en otras plataformas usando instrucciones equivalentes (por ejemplo, AVX2, SSE o NEON).

Cada instrucción tiene una función clara en el proceso de inserción:

• vmovdqu: Carga 16 bytes de control consecutivos en el registro xmm0 de 128 bits.

• vpbroadcastb:Replica la huella digital de 7 bits de la nueva clave en todos los carriles del registro xmm1.

• vpcmpeqb: Compara cada byte de control con la huella digital transmitida, lo que genera una máscara de posibles coincidencias.

• kmovq + test: Mueve la máscara a un registro de propósito general y comprueba rápidamente si existe una coincidencia.

Finalmente, decidimos sondear grupos de 16 bytes de control a la vez, ya que las pruebas de rendimiento mostraron que expandirse a 32 o 64 bytes con registros más amplios no proporcionaba ningún beneficio de rendimiento medible.

Integración en ES|QL

Adoptar el hash al estilo suizo en Elasticsearch no fue solo un reemplazo inmediato. ES|QL tiene exigencias estrictas en cuanto a contabilidad de memoria, seguridad e integración con el resto del motor de cálculo.

Integramos la nueva tabla hash estrechamente con la gestión de memoria de Elasticsearch, que incluye el reciclador de páginas y la contabilidad del interruptor de circuito, lo que garantiza que las asignaciones permanezcan visibles y limitadas. Las agregaciones de Elasticsearch se almacenan densamente y se indexan por un ID de grupo, lo que mantiene el diseño de memoria compacto y rápido para la iteración, además de habilitar ciertas optimizaciones de rendimiento al permitir el acceso aleatorio.

Para las claves de bytes de longitud variable, almacenamos en caché el hash completo junto con el ID del grupo. Esto evita la recomputación de costosos códigos hash durante el sondeo y mejora la localidad de la caché al mantener los metadatos relacionados juntos. Durante el reprocesamiento, podemos confiar en el hash en caché y en los bytes de control sin inspeccionar los valores en sí, lo que mantiene bajos los costos de redimensionamiento.

Una simplificación importante en nuestra implementación es que las entradas nunca se eliminan. Esto elimina la necesidad de marcadores (marcadores para identificar ranuras previamente ocupadas) y permite que las ranuras vacías permanezcan verdaderamente vacías, lo que mejora aún más el comportamiento de la sonda y mantiene eficientes los escaneos de bytes de control.

El resultado es un diseño que se ajusta naturalmente al modelo de ejecución de Elasticsearch a la vez que preserva las características de rendimiento que hacen atractivas a las tablas suizas.

¿Cómo funciona?

En cardinalidades pequeñas, las tablas suizas rinden aproximadamente al mismo nivel que la implementación existente. Esto es lo que se espera: cuando las tablas son pequeñas, los efectos de la caché tienen menos importancia y hay poco que optimizar.

A medida que aumenta la cardinalidad, la imagen cambia rápidamente.

El mapa de calor anterior traza los factores de mejora del tiempo para diferentes tamaños de clave (8, 32, 64 y 128 bytes) en cardinalidades desde 1,000 hasta 10,000,000 de grupos. A medida que aumenta la cardinalidad, el factor de mejora aumenta constantemente, y llega a hasta 2–3x para distribuciones uniformes.

Esta tendencia es exactamente lo que predice el diseño. Una cardinalidad más alta conduce a cadenas de sondeo más largas en las tablas hash tradicionales, mientras que el sondeo de estilo suizo continúa resolviendo la mayoría de las búsquedas dentro de los bloques de bytes de control amigables con SIMD.

El comportamiento de la caché cuenta la historia

Para comprender mejor las aceleraciones, ejecutamos el mismo JMH benchmarks en Linux perf y capturamos estadísticas de caché y TLB.

En comparación con la implementación original, la versión suiza realiza aproximadamente un 60% menos de referencias de caché en general. Las cargas de la caché de último nivel disminuyen más de 4 veces, y los fallos de carga de la LLC caen en más de 6 veces. Dado que las omisiones de LLC a menudo se traducen directamente en accesos a la memoria principal, esta reducción por sí sola explica una gran parte de la mejora de extremo a extremo.

Más cerca de la CPU, vemos menos pérdidas de caché de datos L1 y casi 6 veces menos pérdidas TLB de datos, lo que apunta a una localidad espacial más estrecha y patrones de acceso a la memoria más predecibles.

Esta es la recompensa práctica de los bytes de control compatibles con SIMD. En lugar de cargar repetidamente claves y valores desde ubicaciones de memoria dispersas, la mayoría de las pruebas se resuelven escaneando una estructura compacta residente en la caché. Menos memoria afectada significa menos fallos, y menos fallos significan consultas más rápidas.

Resumen

Al adoptar un diseño de tabla hash al estilo suizo y al inclinarnos por el sondeo amigable con SIMD, logramos una velocidad de 2 a 3 veces mayor para cargas de trabajo de estadísticas ES|QL de alta cardinalidad, junto con un rendimiento más estable y predecible.

Este trabajo destaca cómo las estructuras de datos modernas con conocimiento de CPU pueden desbloquear ganancias sustanciales, incluso para problemas bien conocidos, como las tablas hash. Hay más para explorar aquí, como especializaciones adicionales de tipo primitivo y el uso en otras rutas de alta cardinalidad, como las uniones, que son solo parte del esfuerzo más amplio y continuo para modernizar continuamente los internos de Elasticsearch.

Si te interesan los detalles o quieres seguir el trabajo, echa un vistazo a esta solicitud de extracción y problema meta en Github.

¡Feliz hash!

Recientemente contribuimos al proyecto open source Google MCP Toolbox for Databases agregando soporte para Elasticsearch como base de datos.

Con esta nueva característica, ahora puedes usar Google MCP Toolbox para conectarte a Elasticsearch y “conversar” directamente con tus datos.

Elasticsearch

Es necesario tener una instancia de Elasticsearch en funcionamiento. Puedes activar una prueba gratuita en Elastic Cloud o instalarla localmente utilizando el script start-local:

Esto instalará Elasticsearch y Kibana en tu computadora y generará una clave API que se utilizará para configurar Google MCP Toolbox.

La clave de API se mostrará como salida del comando anterior y se almacenará en un archivo .env. en la carpeta elastic-start-local.

Instala el set de datos de ejemplo

Tras la instalación, puedes iniciar sesión en Kibana con el nombre de usuario elastic y la contraseña generada por el script start-local (almacenada en un archivo .env).

Puedes instalar el conjunto de datos de pedidos de comercio electrónico disponible desde Kibana. Incluye un único índice llamado kibana_sample_data_ecommerce que contiene información sobre 4675 pedidos de un sitio web de comercio electrónico. Para cada pedido, tenemos la siguiente información:

• Información del cliente (nombre, identificación, fecha de nacimiento, correo electrónico, etc.)

• Fecha del pedido

• ID de pedido

• Productos (lista de todos los productos con precio, cantidad, identificación, categoría, descuento, etc.)

• SKU

• Precio total (sin impuestos, con impuestos)

• Cantidad total

• Información geográfica (ciudad, país, continente, ubicación, región)

Para instalar los datos de muestra, abre la página Integraciones en Kibana (busca “Integración” en la barra superior de búsqueda) e instala los “Datos de muestra”. Para obtener más detalles, consulta la documentación aquí: https://www.elastic.co/docs/explore-analyze/#gs-get-data-into-kibana.

El objetivo de este artículo es mostrar lo fácil que es configurar Google MCP Toolbox para conectarse a Elasticsearch e interactuar con el índice de kibana_sample_data_ecommerce usando lenguaje natural.

Google MCP Toolbox

Google MCP Toolbox es un servidor MCP open source diseñado para facilitar la interacción segura y eficiente de aplicaciones y agentes de IA con bases de datos. El proyecto, anteriormente conocido como el “GenAI Toolbox for Databases”, cambió su denominación después de adoptar la compatibilidad total con el Protocolo de contexto de modelo (MCP). Su propósito es eliminar el trabajo pesado que tradicionalmente se requiere al conectar agentes con bases de datos, gestionando la agrupación de conexiones, autenticación, observabilidad y otras preocupaciones operativas en segundo plano.

Esencialmente, Toolbox permite a los desarrolladores definir herramientas reutilizables de alto nivel que encapsulan las interacciones con la base de datos. Estas herramientas pueden ser invocadas por cualquier cliente compatible con MCP (como un agente de IA) sin requerir que el cliente implemente consultas SQL de bajo nivel o administre conexiones de base de datos. Este enfoque reduce drásticamente la cantidad de código repetitivo necesario para crear agentes compatibles con bases de datos, lo que permite integrar operaciones de datos avanzadas en solo unas pocas líneas de lógica de aplicación. Una vez definida una herramienta, se puede compartir entre varios agentes, marcos de trabajo o lenguajes (Figura 1).

Una de las ventajas principales de usar la Toolbox es el modelo de seguridad integrado. Los flujos de autenticación como OAuth2 y OIDC son compatibles de forma nativa, lo que permite a los desarrolladores evitar manejar o almacenar credenciales confidenciales de bases de datos en agentes. La plataforma también ofrece características de observabilidad (como métricas y rastreo) a través de OpenTelemetry, que es esencial para la depuración, la supervisión y los despliegues de producción. En conjunto, MCP Toolbox sirve como una interfaz unificada, segura y extensible para interactuar con tus datos desde cualquier sistema compatible con MCP.

Cómo instalar MCP Toolbox

Puedes instalar el servidor MCP Toolbox en Linux usando el siguiente comando:

Si quieres instalarlo en macOS o Windows, puedes seguir las instrucciones detalladas aquí.

Configura la Toolbox para Elasticsearch

Para configurar el MCP Toolbox para Elasticsearch, necesitamos crear un archivo tools.yaml, de la siguiente manera:

Debes reemplazar el valor <insert-here-api-key> por una clave API válida de Elasticsearch. Si estás ejecutando Elasticsearch localmente usando start-local, puedes encontrar la clave de API en el archivo.env generado por start-local, bajo la variable ES_LOCAL_API_KEY . Si usas Elastic Cloud, puedes generar una clave API siguiendo el procedimiento descrito aquí.

Las herramientas anteriores contienen la siguiente consulta ES|QL para Elasticsearch:

Si no estás familiarizado con ES|QL, es un lenguaje de búsqueda desarrollado por Elastic, similar a SQL, que puedes usar para buscar en uno o más índices. Puedes leer más sobre ES|QL en la documentación oficial aquí.

La búsqueda anterior busca todos los pedidos almacenados en el índice kibana_sample_data_ecommerce que contienen el nombre del cliente especificado, usando el parámetro ?name (el signo de interrogación indica un parámetro).

El nombre del cliente se define en la configuración YAML anterior empleando el texto de tipo y la descripción "El nombre del cliente".

Esta herramienta se puede usar para responder preguntas sobre los pedidos de un cliente, por ejemplo: ¿Cuántos pedidos realizó el cliente Foo en octubre de 2025?

Las descripciones de las herramientas y sus parámetros son esenciales para extraer la información relevante de la solicitud en lenguaje natural del usuario. Esta extracción se realiza utilizando la capacidad de llamada de función de un modelo de lenguaje grande (LLM). En la práctica, un LLM puede determinar qué función (herramienta) debe ejecutar para obtener la información necesaria, junto con los parámetros apropiados para esa función.

Para más información sobre las llamadas a funciones, sugerimos leer el artículo de OpenAI sobre llamadas a funciones con Elasticsearch de Ashish Tiwari.

Ejecuta el servidor de Toolbox

Puedes ejecutar la MCP Toolbox usando el archivo tools.yaml anterior con el siguiente comando:

El parámetro –ui ejecuta una aplicación sitio web en http://127.0.0.1:5000/ui (Figura 2).

Puedes seleccionar la Herramientas > pedidos-clientes e insertar un nombre de cliente en el parámetro nombre (por ejemplo, Gwen Sanders) y haz clic en el botón Ejecutar herramienta. Deberías ver una respuesta JSON como se indica en la Figura 3.

La configuración se ha completado y MCP Toolbox puede ejecutar la herramienta de pedidos de clientes para comunicarse con Elasticsearch, ejecutando la consulta ES|QL.

Usar la herramienta MCP Toolbox con Gemini CLI

Podemos usar cualquier cliente del MCP para comunicarnos con MCP Toolbox for Database. Por ejemplo, podemos usar Gemini CLI, una herramienta de línea de comandos, para usar Gemini. Puedes instalar Gemini CLI siguiendo las instrucciones indicadas aquí.

Gemini CLI ofrece una extensión preconfigurada para MCP Toolbox, disponible en gemini-cli-extensions/mcp-toolbox. Puedes instalar esta extensión ejecutando el comando siguiente:

Tras la instalación, debes ir al directorio donde almacenaste el archivo de configuración tools.yaml para MCP Toolbox y ejecutar la CLI Gemini de la siguiente manera (este paso es necesario para que la CLI Gemini se configure automáticamente con MCP Toolbox):

Deberías ver un anuncio de salida como el que se muestra en la Figura 4.

Puedes comprobar si MCP Toolbox está conectada usando el siguiente comando:

Deberías ver el mcp_toolbox con las herramientas de customer-orders listadas (Figura 5).

Si el MCP Toolbox está conectado a la CLI de Gemini, ahora podemos intentar hacer algunas preguntas, como: “Dame los pedidos del cliente Gwen Sanders”. La CLI de Gemini solicitará entonces permiso para ejecutar la herramienta de pedidos de clientes desde el servidor mcp_toolbox (ver Figura 6).

Tras la confirmación, Gemini CLI ejecutará la solicitud a MCP Toolbox, obteniendo una respuesta JSON como resultado y utilizándola para dar formato a la respuesta (Figura 7).

La respuesta de Gemini CLI será un reporte que indica que Gwen Sanders hizo solo un pedido de 2 productos, por un precio total de 132 euros.

SDK de MCP Toolbox

Google MCP Toolbox también ofrece un SDK para acceder a todas las funcionalidades desde un programa escrito en Go, Python y Javascript.

Por ejemplo, el SDK de Python está disponible en Github en la siguiente página: https://github.com/googleapis/mcp-toolbox-sdk-python.

Es necesario crear un agente simple para conectarnos a MCP Toolbox. Debemos instalar los siguientes paquetes:

Además, crear un nuevo proyecto de agente usando los siguientes comandos:

Esto creará un nuevo directorio llamado my_agent con un archivo agent.py.

Actualiza my_agent/agent.py con el siguiente contenido para conectar con Toolbox:

Crea un archivo .env con tu clave de API de Google:

Finalmente, podemos ejecutar el agente y observar los resultados. Para ejecutar el agente, puedes ejecutar el siguiente comando:

O bien, puedes servirlo a través de una interfaz web:

En ambos casos, puedes interactuar con MCP Toolbox usando una interfaz de preguntas frecuentes. Por ejemplo, puedes hacer la pregunta anterior: Dame las órdenes de la cliente Gwen Sanders.

Para más información sobre los diferentes SDK, puedes consultar esta página de documentación.

Conclusión

En este artículo, hemos mostrado la integración de Elasticsearch con Google MCP Toolbox for Databases. Mediante un sencillo archivo de configuración YAML, podemos definir un conjunto de herramientas que traducen preguntas en lenguaje natural a consultas de Elasticsearch utilizando el lenguaje ES|QL.

Mostramos cómo interactuar con el set de datos kibana_sample_data_ecommerce, que contiene pedidos de un sitio web de comercio electrónico. Con este archivo de configuración, podemos simplemente ejecutar el servidor MCP Toolbox y conectarnos a él desde cualquier cliente MCP.

Por último, mostramos cómo utilizar la CLI de Gemini como cliente para conectarse a MCP Toolbox for Databases y consultar los datos de comercio electrónico almacenados en Elasticsearch. Ejecutamos una consulta en lenguaje natural para recuperar información sobre pedidos para un cliente específico identificado por su nombre.

A medida que el ecosistema MCP sigue creciendo, este patrón (definiciones ligeras de herramientas respaldadas por infraestructuras seguras y listas para producción) crea nuevas oportunidades para construir agentes cada vez más capaces y conscientes de los datos con un esfuerzo mínimo. Ya sea que experimentes localmente con los sets de datos de muestra de Elastic o integres capacidades de búsqueda en una aplicación más amplia, MCP Toolbox ofrece una base fiable y extensible para interactuar con tus datos de Elasticsearch usando lenguaje natural.

Para obtener más información sobre el desarrollo de aplicaciones de IA agentic, puedes leer el artículo Creación de flujos de trabajo de IA agentic con Elasticsearch de Anish Mathur y Dana Juratoni.

Para obtener más información sobre Google MCP Toolbox, puedes visitar https://googleapis.github.io/genai-toolbox/getting-started/introduction/.

A continuación, se muestran las características de Elasticsearch 9.2 que transformarán tus flujos de trabajo de análisis de datos con ES|QL.

Revolucionando la correlación de datos: Lookup Join más inteligente, rápido y flexible

El comando LOOKUP JOIN en ES|QL experimentó una transformación significativa en Elasticsearch 9.2, y se volvió mucho más eficiente y versátil. Lookup JOIN combina datos de la tabla de resultados de búsquedas ES|QL con registros coincidentes de un índice de modo de consulta especificado. Agrega campos del índice de búsqueda como nuevas columnas a la tabla de resultados en función de los valores coincidentes en el campo de combinación. Anteriormente, la unión de datos se limitaba a un solo campo y a una igualdad simple. ¡Ya no! Estas mejoras te permiten abordar escenarios complejos de correlación de datos con facilidad.

Las mejoras clave de Lookup Join incluyen:

• Uniones de múltiples campos: únete fácilmente a varios campos. Por ejemplo, para unir application_logs con service_registry en service_name, environment y version:

• Utilización de predicados de unión complejos con expresiones (vista previa técnica):

Ya no estás limitado a la igualdad simple. LOOKUP JOIN ahora permite especificar múltiples criterios de correlación e incorporar una variedad de operadores binarios, como ==, !=, <, >, <= y >=. Esto significa que puedes crear condiciones de unión muy matizadas, lo que te permite plantear preguntas mucho más complejas sobre tus datos.

Ejemplo 1: Búsqueda de métricas de aplicaciones con umbrales de SLA por servicio

Ejemplo 2: Esta búsqueda calcula el monto adeudado, basado en políticas de precios regionales que cambian con el tiempo. Une tres sets de datos basados en condiciones complejas de rango de fechas e igualdad para calcular un due_amount final. La segunda unión de búsqueda utiliza el campo measurement_date del índice de meter_readings y el campo region_id del índice de customers para unirse al índice de pricing_policies y encontrar la política de precios correcta según la region y la measurement_dateparticular.

• Grandes ganancias de rendimiento para uniones filtradas:

Hemos mejorado el rendimiento de las "uniones en expansión" que se filtran al utilizar condiciones de tabla de búsqueda. Las uniones expansivas producen múltiples coincidencias por fila de entrada, lo que puede generar grandes conjuntos de resultados intermedios. Esto empeora cuando muchas de esas filas se descartan mediante un filtro posterior. En la versión 9.2, optimizamos estas uniones al filtrar las filas innecesarias cuando se aplica un filtro a los datos de búsqueda, lo que evita procesar filas que se descartarían. ¡En algunos casos, estas uniones pueden ser hasta 1000 veces más rápidas!

Esta optimización es crucial cuando se trata de "uniones en expansión", en las que una búsqueda podría generar inicialmente muchas coincidencias potenciales. Al aplicar filtros de forma inteligente, solo se procesan los datos relevantes, lo que reduce drásticamente el tiempo de ejecución de las consultas y permite realizar análisis en tiempo real en sets de datos masivos. Esto significa que obtienes tu información mucho más rápido, incluso con operaciones de unión muy grandes o complejas.

Compatibilidad de la búsqueda de agrupación con Cross-Cluster Search (CCS):

Cuando Lookup Join se lanzó al mercado en las versiones 8.19 y 9.1, carecía de compatibilidad con Cross-Cluster Search (CCS). Para organizaciones que operan en múltiples agrupaciones, LOOKUP JOIN ahora se integra perfectamente con CCS en la versión 9.2. Simplemente coloca tu índice de búsqueda en todos los clústeres remotos donde desees realizar una unión, y ES|QL aprovechará automáticamente estos índices de búsqueda para unirse a sus datos remotos. Esto simplifica el análisis distribuido de datos y garantiza un enriquecimiento consistente en todo el despliegue de Elasticsearch.

Estas mejoras permiten correlacionar diversos conjuntos de datos con una precisión, velocidad y facilidad sin precedentes, lo que permite obtener información más profunda y útil sin necesidad de soluciones alternativas complejas ni pasos de preprocesamiento.

Enriquece tus datos con facilidad: Kibana Discover UX para índices de búsqueda

El enriquecimiento de datos debe ser sencillo, no un obstáculo. Introdujimos una experiencia de usuario fantástica en Discover de Kibana para crear y gestionar índices de búsqueda.

Flujo de trabajo intuitivo: el autocompletado integral de Discover te guiará a través del proceso y te sugerirá índices de búsqueda y campos de unión en el editor ES|QL, lo que hace que sea increíblemente fácil conectar tus datos de monitoreo del tiempo de actividad con índices existentes. Escribe el nombre de un índice de búsqueda que no exista y obtén acceso directo al editor de búsqueda con un clic para crear el índice. Escribe el nombre de un índice de búsqueda existente y te sugeriremos una opción para editarlo:

Gestión en línea (CRUD): mantén actualizados tus sets de datos de referencia con las funciones de edición en línea (crear, leer, actualizar, eliminar) directamente en Discover.

Carga de archivos sin esfuerzo: ahora puedes subir archivos directamente, como CSVs, dentro de Discover y usarlos instantáneamente en LOOKUP JOIN. ¡Ya no es necesario cambiar de contexto al saltar de un área a otra de Kibana!

Ya sea que estés usando mapping de IDs de usuario a nombres, agregando metadatos empresariales o uniendo archivos de referencia estáticos, esta característica democratiza el enriquecimiento de datos, lo que pone el poder de las uniones directamente en manos de cada usuario de forma rápida, sencilla y en un solo lugar.

Preserva tu contexto: presentación de INLINE STATS (versión preliminar de tecnología)

La agregación de datos es crucial, pero a veces necesitas ver los agregados junto a tus datos originales. Nos complace presentar INLINE STATS como una característica de vista previa técnica.

A diferencia del comando STATS, que reemplaza tus campos de entrada por una salida agregada, INLINE STATS conserva todos tus campos de entrada originales y simplemente agrega los nuevos campos agregados. Esto te permite realizar más operaciones en tus campos de entrada originales después de la agregación, lo que genera un flujo de trabajo de análisis más continuo y flexible.

Por ejemplo, para calcular la distancia promedio de vuelo mientras se mantienen las filas de vuelo individuales:

En esta consulta, se agrega avgDist a cada fila con el Destcorrespondiente (ination) por el que agrupamos y, como aún tenemos las columnas de información de vuelo, podemos filtrar los resultados a los vuelos con una distancia mayor que la media.

Compatibilidad con series temporales en ES|QL (vista previa técnica)

Elasticsearch usa flujos de datos temporales para almacenar métricas. Estamos agregando soporte para agregaciones de series temporales en ES|QL, a través del comando fuente TS. Esto está disponible en Elastic Cloud Serverless y la versión 9.2 básica como vista previa técnica.

El análisis de series temporales se basa en gran medida en consultas de agregación que resumen los valores métricos a lo largo de las cubetas de tiempo, divididos por una o más dimensiones de filtrado. La mayoría de las consultas de agregación se basan en un procesamiento de dos pasos, con (a) una función de agregación interna que resume los valores por serie temporal y (b) una función de agregación externa, que combina los resultados de (a) en todas las series temporales.

El comando de origen TS, combinado con STATS, proporciona una forma concisa, pero efectiva de expresar tales consultas sobre series temporales. Más concretamente, considera el siguiente ejemplo para calcular la tasa total de solicitudes por host y hora:

En este caso, la función de agregación de seriales temporales RATE se evalúa primero por series temporales y hora. Los agregados parciales producidos se combinan luego al usar SUM para calcular los valores agregados finales por host y por hora.

Puedes consultar la lista de funciones de agregación de series temporales disponibles aquí. Ahora se admite la tasa de contador, posiblemente la función de agregación más importante para procesar contadores.

El comando fuente TS está diseñado para combinarse con STATS, con ejecución ajustada para soportar eficientemente agregaciones de series temporales. Por ejemplo, los datos se ordenan antes de pasar a las STATS. Actualmente, no se permiten comandos de procesamiento que puedan enriquecer o alterar los datos temporales o su orden, como FORK o INLINE STATS, entre TS y STATS. Esta limitación podría eliminarse en el futuro.

La salida tabular STATS se puede procesar aún más con cualquier comando aplicable. Por ejemplo, la siguiente búsqueda calcula la relación del promedio de cpu_usage por host hospedado y hora con el valor máximo por host:

Los datos temporales se almacenan en nuestro motor de almacenamiento columnar subyacente que funciona con los valores de documentos de Lucene. El comando TS agrega ejecución de consultas vectorizadas a través del motor de cómputo ES|QL. El rendimiento de las búsquedas a menudo se mejora en más de un orden de magnitud, en comparación con las consultas DSL equivalentes, y está a la par con los sistemas establecidos específicos de métricas. En el futuro ofreceremos un análisis detallado de arquitectura y rendimiento, así que mantente alerta.

Ampliación de tu conjunto de herramientas: funciones nuevas de ES|QL

Para mejorar aún más la utilidad y versatilidad de ES|QL, agregamos un conjunto de funciones nuevas:

Manipulación de cadenas: CONTAINS, MV_CONTAINS, URL_ENCODE, URL_ENCODE_COMPONENT, URL_DECODE para un procesamiento más robusto de texto y URL.

Serie temporal y geoespacial: TBUCKET para cubetas de tiempo flexibles, TO_DENSE_VECTOR para operaciones vectoriales y un conjunto completo de funciones geoespaciales como ST_GEOHASH, ST_GEOTILE, ST_GEOHEX, TO_GEOHASH, TO_GEOTILE, TO_GEOHEX para un análisis avanzado basado en la ubicación.

Formato de fechas: DAY_NAME, MONTH_NAME para representaciones de fechas más legibles.

Estas funciones te proporcionan un conjunto más completo de herramientas para manipular y analizar tus datos directamente dentro de ES|QL.

Bajo el capó: Más rendimiento y eficiencia

Más allá de las características destacadas, Elasticsearch 9.2 incluye varias optimizaciones de rendimiento en ES|QL. Aceleramos RLIKE (LIST) con pushdown en casos en los que la función reemplaza múltiples consultas RLIKE similares. Con RLIKE (LIST), podemos fusionar esas búsquedas en un único autómata y aplicar un autómata en vez de varios. También tenemos una carga más rápida de los campos de palabras clave con ordenamientos de índice y optimizaciones generales de consultas; estas mejoras aseguran que tus consultas ES|QL se ejecuten más eficientemente que nunca.

¡Comienza hoy mismo!

Elasticsearch 9.2 representa un avance significativo para ES|QL, ya que brinda un poder y flexibilidad sin precedentes a sus flujos de trabajo de análisis de datos. Te invitamos a explorar estas funciones nuevas y a experimentar la diferencia que generan.

Para obtener una lista completa de todos los cambios y mejoras de Elasticsearch 9.2, consulte las notas de lanzamiento oficiales. ¡Feliz búsqueda!

En este blog, exploraremos la experiencia de desarrollador del ES|QL Editor en Elasticsearch 9.1 comparándolo con PPL en el Event Analyzer (PPL para abreviar) en OpenSearch 3.2.

Las diferencias se hacen evidentes rápidamente: el ES|QL Editor ofrece autocompletado inteligente, ayuda contextual, consultas recomendadas y soporte para consultas entre clústeres que empoderan no solo a usuarios principiantes, sino también a expertos en nivel profesional. El diseño pensado para ES|La autoría QL se observa también en la inspección integrada de consultas y la integración holística a través de flujos de trabajo Kibana, por ejemplo, con Consultas Recientes.

PPL, en cambio, carece de soporte comparable para autocompletado, guía contextual y consultas distribuidas, lo que crea una curva de aprendizaje más pronunciada y más prueba y error.

Creación de ES|QL es más fácil de aprender y usar

Empezar con un nuevo lenguaje de consulta a menudo puede resultar abrumador. El ES|QL Editor, integrado directamente en Kibana Discover, está diseñado para facilitar ese proceso apoyando no solo la creación y depuración de consultas, sino también acelerando la rapidez con la que te familiarizas y te sientes cómodo con el lenguaje. Como el editor ayuda a reducir la fricción en las tareas cotidianas, puedes cambiar tu enfoque de la sintaxis y el ensayo y error a la solución. Puedes leer más sobre estos principios y cómo los integramos en el editor aquí.

Esta experiencia como editor no se limita a Discover; es un módulo de código reutilizable que estamos trabajando en integrar en otras partes de Kibana, como paneles de control, alertas de Kibana y mapas de Kibana.

Autocompletado inteligente: acelerando la creación de tu consulta

El autocompletado en ES|QL Editor es completo, ofreciendo sugerencias para funciones, argumentos, literales e incluso funciones anidadas compatibles, una capacidad notablemente ausente en PPL. De hecho, fue reconstruida desde cero, como se explica aquí.

La validación se ejecuta a medida que el usuario escribe, como se describe aquí, y sugerirá campos y también notificará al usuario sobre errores. Esto reduce la carga mental de los usuarios y ayuda a prevenir errores al principio del proceso de creación de la consulta.

Ejemplo: Se sugieren campos y funciones compatibles en este anidamiento:

Algo que PPL no soporta:

Incluso con un autocompletado inteligente guiándote a través de funciones compatibles, argumentos y funciones anidadas, puede que aún quieras entender más a fondo las opciones disponibles. Aquí es precisamente donde ES|La ayuda contextual de QL Editor se vuelve invaluable, ofreciendo asistencia inmediata dentro del editor para aclarar y mejorar el desarrollo de tus consultas.

Ayuda contextual al alcance de tu mano

Información adicional sobre un comando generado por autocompletado está a un clic Ctrl-Espacio de distancia. Aparece inmediatamente un panel con detalles sobre la función, argumento o campo en cuestión. Esta interacción ligera mantiene a los desarrolladores en el flujo, proporcionando orientación justo a tiempo sin obligarles a abandonar el editor ni buscar en documentación externa. Esto reduce el tiempo perdido en búsquedas de sintaxis y ayuda a prevenir errores comunes antes de que ocurran.

Así es como se ve en acción:

PPL carece de este nivel de guía integrada, lo que obliga a los usuarios a depender de documentos externos o de prueba y error. Esa ausencia no es solo una característica que falta; Pone de manifiesto una disparidad más amplia en la filosofía del diseño. ES|QL prioriza una experiencia reflexiva y consciente del contexto que se adapta a los datos y al flujo de trabajo del usuario. Esta diferencia se hace más pronunciada a medida que las consultas se vuelven más complejas, haciendo que ES|QL Editor es un entorno más eficiente y fiable tanto para el aprendizaje como para el uso en producción.

Consultas recomendadas que sean conscientes del contexto de los datos

El ES|QL Editor proporciona consultas recomendadas que se adaptan automáticamente a los datos con los que trabajas, como los registros. En lugar de presentar un editor en blanco, pone a la luz los puntos de partida más relevantes para casos de uso comunes. Seleccionar una consulta recomendada genera una consulta canónica que es inmediatamente utilizable y puede refinar según sea necesario. Este enfoque acelera el desarrollo de consultas, especialmente para nuevos usuarios que aún no conocen la sintaxis completa.

Aquí tienes un ejemplo en el que un usuario selecciona la consulta "Detectar punto de cambio":

Compáralo con la experiencia de PPL:

En cambio, PPL aquí solo ofrece autocompletado básico, dejándote armar las consultas sin contexto ni estructura. Esta falta de orientación puede provocar frustración y prueba y error. Con ES|Consultas recomendadas con conocimiento de datos de QL Editor, puedes evitar empezar desde cero o memorizar la sintaxis para tareas rutinarias. El editor reduce la carga cognitiva, ayuda a prevenir errores y te permite centrarte en la resolución de problemas y en objetivos más amplios, como realizar búsquedas entre clústeres en lugar de lidiar con la construcción de consultas.

Consulta intuitiva entre clústeres

ES|El autocompletado del editor QL sigue siendo superior, incluso cuando se trabaja con múltiples clústeres remotos con CCS. He aquí por qué:

ES|QL Editor ofrece un autocompletado fluido incluso entre clústeres

Autocompletado en el ES|QL Editor soporta no solo nombres de clústeres sino también índices locales y remotos. Como se explica aquí, esto funciona gracias a una arquitectura de nodos coordinadores, que ayuda a validar y generar el plan de consulta para enviar a los nodos locales, ejecutar la consulta y agregar los resultados antes de enviarlos de vuelta al usuario. Sin introducir el nombre completo del clúster remoto, escribir ":" inicia el proceso de autocompletado para el índice remoto. Y no estás limitado al prefijo.

Esto facilita descubrir y consultar entre conjuntos de datos distribuidos sin memorizar convenciones de nombres ni cambiar de contexto.

Aquí tienes un ejemplo en el que el usuario simplemente escribe "clu:g" para localizar un índice remoto:

En marcado contraste, la PPL solo proporciona completitud básica para índices locales, con sugerencias restringidas a coincidencias con prefijos. Los clústeres remotos deben ser tipados manualmente, lo que aumenta la probabilidad de errores y ralentiza la creación de consultas.

PPL solo proporciona completitud para índices locales y las sugerencias se restringen al prefijo:

ES|QL va más allá permitiendo exclusiones directamente usando un signo negativo, dándote un control detallado sobre qué clústeres participan en tu exploración. Esta capacidad es especialmente valiosa al trabajar con entornos híbridos, donde puede ser necesario incluir u omitir conjuntos de datos específicos durante investigaciones entre clústeres.

Estas mejoras reflejan el enfoque más amplio de Elasticsearch en reducir la fricción en la búsqueda entre clústeres. Al facilitar la construcción y gestión de consultas distribuidas, ES|QL Editor permite a analistas y desarrolladores centrar en los insights en lugar de la sintaxis, mientras que PPL deja mayor parte de esa carga al usuario. Y igual que el ES|QL Editor simplifica la creación de consultas entre clústeres y también proporciona herramientas para inspeccionar cómo se ejecutan esas consultas, garantizando transparencia y monitorización del rendimiento en múltiples clústeres.

Uso de la herramienta Inspect para analizar los detalles de búsqueda entre clústeres

La Herramienta de Inspección, accesible desde el ES|QL Editor está diseñado para proporcionar metadatos con información explícita sobre la ejecución de consultas en todos los clústeres. Esta funcionalidad está habilitada en Kibana Discover y es accesible directamente en el inspector de consultas, permitiéndote analizar el progreso y los detalles de la búsqueda, algo especialmente crucial para la búsqueda entre clústeres (CCS). Esta capacidad te ayuda a monitorizar el progreso de las búsquedas y a entender cómo funcionan las consultas entre conjuntos de datos distribuidos.

Esta visibilidad detallada de la ejecución de consultas, especialmente para búsquedas distribuidas complejas, te permite garantizar un rendimiento y resolución de problemas óptimos.

Más allá de entender la mecánica de las consultas individuales, ES|QL Editor mejora aún más el recorrido del usuario al integrar profundamente funcionalidades esenciales en toda la plataforma Kibana, fomentando un flujo de trabajo fluido e ininterrumpido.

Experiencia unificada de consultas con ES|QL y Kibana

Una de las fuentes más comunes de fricción en el análisis guiado por consultas es el cambio de contexto. A menudo necesitas recordar consultas que ya escribiste. Cada interrupción rompe el foco y ralentiza las investigaciones. ES|QL Editor aborda esto integrando el historial de consultas en Kibana.

Consultas recientes

La función de Consultas Recientes en ES|QL Editor te ayuda a mantener el flujo haciendo que el trabajo pasado sea instantáneamente accesible. Dentro del ES|En el Editor QL en Discover, puedes ver, volver a ejecutar y poner estrellas en tus últimas 20 consultas, cerciorando que las consultas frecuentes o complejas estén a solo un clic de distancia. Estas consultas almacenadas también se transmiten a Kibana, integrar con paneles, visualizaciones, alertas y mapas, así que no necesitas salir de la pantalla actual ni volver a escribir comandos desde cero. Esto reduce el trabajo repetitivo, acelera las investigaciones y minimiza el riesgo de errores.

Por ejemplo, un usuario puede emplear las Consultas Recientes en ES|Editor de QL en Discover (y ponles la estrella):

Las consultas recientes están integradas en el Panel de Control:

PPL no ofrece una capacidad comparable, por lo que los usuarios dependen de copiar y pegar manualmente o notas externas para reutilizar consultas. La diferencia es más que la comodidad; refleja la estrategia de Elastic de construir ES|QL como un lenguaje verdaderamente integrado dentro del ecosistema Kibana. Con funciones como Consultas Recientes, ES|QL Editor no solo agiliza los flujos de trabajo diarios, sino que también sienta las bases para funcionalidades más avanzadas que ahora están en vista previa técnica, cerciorando que la experiencia siga evolucionando.

Conclusión

ES|QL es más que una sintaxis; refleja la estrategia de Elastic para mejorar la forma en que los usuarios buscan, exploran y analizan los datos. Con autocompletado inteligente, consultas recomendadas que consigan el contexto, guía en el editor y herramientas como Inspect, ES|QL Editor acelera el aprendizaje, reduce errores y simplifica flujos de trabajo complejos como el análisis entre clústeres. Integrado en Kibana, conecta consultas de forma fluida con paneles, alertas y visualizaciones para un flujo de trabajo ininterrumpido.

En resumen, ES|QL no es simplemente otro lenguaje canalizado; es un motor de consultas cuidadosamente diseñado combinado con una interfaz intuitiva que redefine fundamentalmente cómo interactúas con tus datos, ofreciendo una experiencia integrada, inteligente y en constante evolución que contrasta fuertemente con la naturaleza a menudo secuencial y menos guiada de OpenSearch PPL.

¿Qué viene después?

Este blog solo rasca la superficie de ES|QL. Las futuras publicaciones profundizarán en comparaciones con OpenSearch PPL y explorarán funciones geoespaciales, de visualización y de próximos editores como los Controles (ya disponibles en Dashboards), pestañas de exploración de múltiples datos, búsqueda en segundo plano, historial de consultas más completo y FUSE.

Prueba ES|QL hoy

Puedes echar un vistazo a ES|QL en proyectos Serverless de Elasticsearch totalmente gestionados con una prueba gratis. También está disponible en versiones que abarcan desde la 8.11, pero se experimenta mejor en la 8.19 y la 9.1.

Empieza en minutos en tu entorno local con un solo comando:

ESQL:

Rubí:

Instalación

La gema puede instalar desde RubyGems con:

O puede agregar al archivo de gemas de un proyecto:

Uso

Puedes construir una consulta completa de una vez o crear un objeto de consulta con un comando fuente como from o row y luego encadenar ES|QL métodos para construir sobre ella.

La gema traduce el código a ES|QL en el método to_s , así que devuelve el ES|Consulta QL cuando se imprime o se convierte en una cadena:

Puedes instanciar un objeto de consulta y mutar su estado inicial usando los equivalentes ! de cada función:

La herramienta ofrece formas cómodas de encadenar pasos extra a un ES|Función QL, como enrich y sort. Una vez que llamas enrich a un objeto Elastic::ESQL , puedes encadenar on y with a él:

También puedes encadenar desc, asc, nulls_first y nulls_last a tu consulta tras usar sort:

También soporta cadenas personalizadas, por si quieres escribir el ES|Consulta QL tú mismo, o usa una función que aún no se agregó a la biblioteca. custom se unirán a las cadenas al final de la consulta. Los agregará a medida que se envían a la función, sin agregar ningún carácter de la tubería. Se combinarán con el resto de la consulta mediante un carácter espacio.

También puedes encadenar custom funciones:

Usando el ES|QL Query Builder con el cliente Ruby

Puedes usar el constructor de consultas directamente con elasticsearch-ruby y la API esql.query enviando el objeto de consulta:

También puedes usarlo con el ES|QL Helper del cliente Ruby de Elasticsearch, para saber más:

Como herramienta independiente

La gema está diseñada como una herramienta independiente para construir ES|QL consulta de forma idiomática. No tiene dependencias en tiempo de ejecución; puedes usarlo con el cliente oficial de Elasticsearch Ruby, o por separado.

La consulta generada puede usar con la API esql.query de cualquier forma que una aplicación interactúe con la API de Elasticsearch (Ruby o no). Una vez que una consulta se construye con elastic-esql, la cadena generada puede enviar a la API como el parámetro query en el cuerpo de la solicitud.

Anteriormente escribí sobre el uso de Elasticsearch con las herramientas Ruby populares. Esta gema puede usar con cualquiera de las herramientas Ruby populares para consultar Elasticsearch con ES|QL.

Conclusión

Esta biblioteca está en desarrollo activo y la API final aún no se completó. Actualmente está lanzado como un avance técnico. Si tienes algún comentario sobre la API actual o su uso general, no dudes en abrir un nuevo número. Por favor, consulta el README para saber más sobre el Ruby ES|Constructor de consultas QL.

Importación de datos geoespaciales usando Kibana

Los datos que usamos para los ejemplos del blog anterior se basaban en datos que usamos internamente para pruebas de integración. Para tu comodidad, lo incluimos aquí en forma de algunos archivos CSV que se pueden importar fácilmente usando Kibana. Los datos son una mezcla de aeropuertos, ciudades y límites urbanos. Puedes descargar los datos desde:

• airports.csv

  • Este contiene una fusión de tres conjuntos de datos:

    • Aeropuertos (nombres, ubicaciones y datos relacionados) de Natural Earth

    • Ubicaciones de las ciudades según SimpleMaps

    • Elevaciones de aeropuertos según la base de datos global de aeropuertos

• airport_city_boundaries.csv

  • Esto contiene una fusión de nombres de aeropuertos y ciudades mencionados anteriormente con una fuente nueva:

    • Límites de la ciudad según OpenStreetMap

Como puedes imaginar, dedicamos un tiempo a combinar estas fuentes de datos en los dos archivos anteriores, con el objetivo de poder probar las características geoespaciales de ES|QL. Puede que esto no sea exactamente lo mismo que tus necesidades específicas de datos, pero espero que esto te dé una idea de lo que es posible. En individuo, queremos demostrar algunas cosas interesantes:

• Importación de datos con campos geoespaciales junto con otros datos indexables

• Importar datos geo_point y geo_shape y usarlos juntos en consultas

• Importación de datos en dos índices que pueden unir mediante una relación espacial

• Crear una canalización de ingestión para facilitar futuras importaciones (más allá de Kibana)

• Algunos ejemplos de procesadores de ingest, como csv, convert y split

Aunque en este blog hablaremos sobre cómo trabajar con datos CSV, es importante entender que existen varias formas de agregar datos geográficos usando Kibana. Dentro de la aplicación de mapas puedes subir datos delimitados como archivos de forma CSV, GeoJSON y ESRI, y también puedes dibujar formas directamente en el mapa. Para este blog nos centraremos en importar archivos CSV desde la página principal de Kibana.

Importación de aeropuertos

El primer expediente , airports.csv, tiene algunas rarezas interesantes con las que tenemos que lidiar. En primer lugar, las columnas tienen espacios en blanco adicionales que las separan, algo que no es típico de los archivos CSV. En segundo lugar, el campo type es un campo de varios valores, que necesitamos separar en cuerpos separados. Por último, algunos campos no son cadenas y necesitan convertir al tipo correcto. Todo esto se puede hacer empleando la instalación de importación CSV de Kibana.

Empieza en la página principal de Kibana. Hay una sección llamada "Empezar agregando integraciones", que tiene un enlace llamado "Subir un archivo":

Haz clic en este enlace y serás llevado a la página "Subir archivo". Aquí puedes arrastrar y soltar el archivo airports.csv , y Kibana analizará el archivo y te mostrará una vista previa de los datos. Debería detectar automáticamente el delimitador como una coma, y la primera fila como la fila de cabecera. Sin embargo, probablemente no recortó el espacio en blanco extra entre las columnas, ni determinó los tipos de campos, suponiendo que todos los campos sean text o keyword. Tenemos que arreglar esto.

Haz clic Override settings y marca la casilla para Should trim fieldsy Apply para cerrar la configuración. Ahora necesitamos fijar los tipos de los campos. Esto está disponible en la página siguiente, así que adelante y haz clic Import.

Primero elige un nombre de índice y luego selecciona Advanced para acceder a la página de mapeo de campos e ingesta del procesador.

Aquí necesitamos hacer cambios tanto en los mapeos de campos del índice como en la canalización de ingesta para importar los datos. En primer lugar, aunque Kibana probablemente detectó automáticamente el campo scalerank como long, percibió erróneamente los campos location y city_location como keyword. Edítalos para que geo_point, y acabes con mapeos que se ven algo así como:

Aquí tienes cierta flexibilidad, pero ten en cuenta que el tipo que elijas afectará a cómo se indexa el campo y qué tipo de consultas son posibles. Por ejemplo, si dejas location tal keyword no puedes realizar ninguna consulta de búsqueda geoespacial sobre él. De manera similar, si dejas elevation tal text no puedes realizar consultas numéricas por rango.

Ahora es el momento de arreglar la pipeline de ingest. Si Kibana detectó automáticamente scalerank como long anterior, también agregó un procesador para convertir el campo en un long. Necesitamos agregar un procesador similar para el campo elevation , esta vez convirtiéndolo a double. Edita la canalización para cerciorarte de que tienes esta conversión en marcha. Antes de almacenar esto, queremos una conversión más, para dividir el campo de type en varios campos. Agregar un procesador split a la canalización, con la siguiente configuración:

La pipeline final de ingesta debería ser la siguiente:

Ten en cuenta que no agregamos un procesador de conversión para los campos location y city_location . Esto se debe a que el tipo geo_point en el mapeo de campos ya entiende el formato WKT de los datos en estos campos. El tipo geo_point puede comprender una variedad de formatos, incluyendo WKT, GeoJSON y más. Si tuviéramos, por ejemplo, dos columnas en el archivo CSV para latitude y longitude, tuvimos que agregar un procesador script o un set para combinarlas en un solo campo geo_point (por ejemplo, "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Ahora estamos listos para importar el archivo. Haz clic Import y los datos se importarán al índice con los mapeos y la pipeline de ingesta que acabamos de definir. Si hay errores al absorber los datos, Kibana los reportará aquí, así que puedes editar los datos fuente o la pipeline de ingesta y volver a intentarlo.

Fíjate que se creó una nueva canalización de ingestión. Esto puede comprobar yendo a la sección Stack Management de Kibana y seleccionando Ingest pipelines. Aquí puedes ver la canalización que acabamos de crear y editarla si es necesario. De hecho, la sección Ingest pipelines puede usar para crear y probar canalizaciones de ingest, una función muy útil si planeas hacer ingestas aún más complejas.

Si quieres explorar estos datos inmediatamente, baja a las secciones posteriores, pero si también quieres importar los límites de la ciudad, sigue leyendo.

Importación de los límites de la ciudad

El archivo de límites de la ciudad disponible en airport_city_boundaries.csv es un poco más sencillo de importar que el ejemplo anterior. Contiene un campo city_boundary que es una representación WKT del límite de la ciudad como POLYGONy un campo city_location que es una representación geo_point de la ubicación de la ciudad. Podemos importar estos datos de forma similar a los datos del aeropuerto, pero con algunas diferencias:

• Tuvimos que seleccionar la opción de anulación Has header row ya que no se detectó automáticamente

• No fue necesario recortar campos, ya que los datos ya estaban limpios de espacio en blanco extra

• No tuvimos que editar la tubería de ingesta porque todos los tipos eran de cadena o de tipos espaciales

• Sin embargo, tuvimos que editar los mapeos de campos para establecer el campo city_boundary a geo_shape y el campo city_location a geo_point

Nuestros mapeos finales de campo eran los siguientes:

Como con la importación airports.csv anterior, simplemente haz clic Import para importar los datos al índice. Los datos se importarán junto con los mapeos que editamos y la pipeline de ingesta que Kibana definió.

Explorando datos geoespaciales con herramientas de desarrollo

En Kibana es habitual explorar los datos indexados con "Descubrir". Sin embargo, si tu intención es crear tu propia app usando ES|Consultas QL, podría ser más interesante intentar acceder a la API en bruto de Elasticsearch. Kibana tiene una consola práctica para experimentar escribiendo consultas. Esto se llama la consola Dev Tools y se puede encontrar en la barra lateral de Kibana. Esta consola se comunica directamente con el clúster Elasticsearch y puede usar para ejecutar consultas, crear índices y más.

Prueba lo siguiente:

Esto debería proporcionar los siguientes resultados:

distancia

Abbrev

nombre

Ubicación

país

ciudad

elevación

273418.05776847183

JAMÓN

Hamburgo

POINT (10.005647830925 53.6320011640866)

Alemania

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

POINT (13.2903090925074 52.5544287044101)

Alemania

Hohen Neuendorf

38.0

483713.15032266214

OSL

Oslo Gardermoen

POINT (11.0991032762581 60.1935783171386)

Noruega

Oslo

208.0

522538.03148094116

BMA

Bromma

POINT (17.9456175406145 59.3555902065112)

Suecia

Estocolmo

15.0

522538.03148094116

ARN

Arlanda

POINT (17.9307299016916 59.6511203397372)

Suecia

Estocolmo

38.0

624274.8274399083

DUS

Düsseldorf Int'l

POINT (6.76494446612174 51.2781820420774)

Alemania

Düsseldorf

45.0

633388.6966435644

PRG

Ruzyn

POINT (14.2674849854076 50.1076511703671)

Chequia

Praga

381.0

635911.1873311149

AMS

Schiphol

PUNTO (4.76437693232812 52.3089323889822)

Países Bajos

Hoofddorp

-3.0

670864.137958866

FRA

Nt'l de Frankfurt

POINT (8.57182286907608 50.0506770895207)

Alemania

Fráncfort

111.0

683239.2529970079

WAW

Okecie Int'l

POINT (20.9727263383587 52.171026749259)

Polonia

Piaseczno

111.0

Visualización de datos geoespaciales con Kibana Maps

Kibana Maps es una herramienta poderosa para visualizar datos geoespaciales. Puede emplear para crear mapas con múltiples capas, cada capa representando un conjunto de datos diferente. Los datos pueden filtrar, agregar y estilizar de diversas maneras. En esta sección, te mostraremos cómo crear un mapa en Kibana Maps usando los datos que importamos en la sección anterior.

En el menú Kibana, navega hasta Analytics->Maps para abrir una nueva vista del mapa. Haz clic en Add Layer y selecciona Documents, eligiendo el airports de vista de datos y luego editando el estilo de capa para colorear los marcadores usando el campo elevation , para que podamos ver fácilmente la altura de cada aeropuerto.

Haz clic en 'Conservar cambios' para almacenar el mapa:

Ahora agrega una segunda capa, esta vez seleccionando la vista de datos airport_city_boundaries . Esta vez, usaremos el campo city_boundary para estilizar la capa y pondremos el color de relleno en azul claro. Esto mostrará los límites de la ciudad en el mapa. Cerciórate de reordenar las capas para que los marcadores del aeropuerto estén encima.

Unirías espaciales

ES|QL no soporta comandos JOIN, pero puedes lograr un caso especial de unión usando el comando ENRICH. Este comando funciona de forma similar a una 'unión por la izquierda' en SQL, permitiéndote enriquecer resultados de un índice con datos de otro índice basar en una relación espacial entre los dos conjuntos de datos.

Por ejemplo, enriquezcamos los resultados de una tabla de aeropuertos con información adicional sobre la ciudad a la que sirven encontrando el límite de la ciudad que contiene la ubicación del aeropuerto, y luego realicemos algunas estadísticas sobre los resultados:

Si ejecutas esta consulta sin preparar primero el índice de enriquecimiento, recibirás un mensaje de error como:

Esto se debe a que, como mencionamos antes, ES|QL no soporta comandos de JOIN verdadero. Una razón importante para ello es que Elasticsearch es un sistema distribuido, y las uniones son operaciones costosas que pueden ser difíciles de escalar. Sin embargo, el comando ENRICH puede ser bastante eficiente, ya que emplea índices de enriquecimiento especialmente preparados que se duplican a lo largo del clúster, permitiendo realizar uniones locales en cada nodo.

Para entender mejor esto, centrémonos en el comando ENRICH de la consulta anterior:

Este comando instruye a Elasticsearch para enriquecer los resultados recuperados del índice de airports y realizar una unión intersects entre el campo city_location del índice original y el campo city_boundary del índice de airport_city_boundaries , que usamos en algunos ejemplos anteriores. Pero parte de esta información no es claramente visible en esta consulta. Lo que sí vemos es el nombre de una política de enriquecimiento city_boundaries, y la información que falta está encapsulada dentro de esa definición de política.

Aquí podemos ver que realizará una consulta geo_match (intersects es el valor predeterminado), el campo a emparejar es city_boundary, y los enrich_fields son los campos que queremos agregar al documento original. Uno de esos campos, el region , se usó como clave de agrupación para el comando STATS , algo que no podríamos hacer sin esta capacidad de 'unión izquierda'. Para más información sobre las pólizas de enriquecimiento, consulte la documentación de enriquecimiento.

Los índices y políticas de enriquecimiento en Elasticsearch fueron diseñados originalmente para enriquecer datos en el momento del índice, empleando datos de otro índice de enriquecimiento preparado. En ES|QL, sin embargo, el comando ENRICH funciona en el momento de la consulta y no requiere el uso de pipelines de ingest. Esto lo hace efectivamente bastante similar a un LEFT JOINSQL, excepto que no puedes unir dos índices cualquiera, solo un índice normal a la izquierda con un índice enrich especialmente preparado a la derecha.

En cualquier caso, ya sea para canalizaciones de ingesta o para su uso en ES|QL, es necesario realizar algunos pasos preparatorios para establecer el índice de enriquecimiento y la póliza. Ya importamos el índice de airport_city_boundaries arriba, pero este no se puede usar directamente como índice de enriquecimiento en el comando ENRICH . Primero necesitamos realizar dos pasos:

• Crea la política de enriquecimiento descrita anteriormente para definir el índice fuente, el campo en el índice fuente para coincidir y los campos que devolver una vez emparejados.

• Ejecuta esta política para crear el índice enriquecido. Esto construirá un índice interno especial, leyendo el índice original en una estructura de datos más eficiente que se copia a través del clúster.

La política de enriquecimiento puede crear usando el siguiente comando:

Y la política puede ejecutar usando el siguiente comando:

Ten en cuenta que si alguna vez cambias el contenido del índice de airport_city_boundaries , tendrás que volver a ejecutar esta política para ver los cambios reflejados en el índice de enriquecimiento. Ahora vamos a ejecutar el ES| originalConsulta QL de nuevo:

Esto devuelve las 5 regiones con más aeropuertos, junto con el centroide de todos los aeropuertos que tienen regiones coincidentes, y el rango en longitud de la representación WKT de los límites de la ciudad dentro de esas regiones:

centroide

Recuento

región

POINT (-12.139086859300733 31.024386116624648)

126

nulo

POINT (-83.10398317873478 42.300230911932886)

3

Detroit

POINT (39.74537850357592 47.21613017376512)

3

городской округ Батайск

POINT (-156.80986787192523 20.476673701778054)

3

Hawai

POINT (-73.94515332765877 40.70366442203522)

3

Ciudad de Nueva York

POINT (-83.10398317873478 42.300230911932886)

3

Detroit

POINT (-76.66873019188643 24.306286952923983)

2

Nueva Providencia

POINT (-3.0252167768776417 51.39245774131268)

2

Cardiff

POINT (-115.40993484668434 32.73126147687435)

2

Municipio de Mexicali

POINT (41.790108773857355 50.302146775648)

2

Центральный район

POINT (-73.88902732171118 45.57078813901171)

2

Montréal

También puede que notes que la región más común era null. ¿Qué podría implicar esto? Recuerda que comparé este comando con un 'left join' en SQL, lo que significa que si no se encuentra ningún límite de ciudad coincidente para un aeropuerto, el aeropuerto sigue devolver pero con valores null para los campos del índice de airport_city_boundaries . Resulta que hubo 125 aeropuertos que no encontraron city_boundarycoincidentes, y un aeropuerto con un coincidente donde el campo de region estaba null. Esto llevó a un recuento de 126 aeropuertos sin region en los resultados. Si tu caso de uso requiere que todos los aeropuertos puedan coincidir con un límite de ciudad, eso requeriría buscar datos adicionales para cubrir los huecos. Sería necesario determinar dos cosas:

• qué registros en el índice de airport_city_boundaries no tienen campos city_boundary

• qué registros en el índice de airports no coinciden usando el comando ENRICH (es decir, no intersectar)

Usando ES|QL para datos geoespaciales en Kibana Maps

Kibana agregó soporte para Spatial ES|QL en la aplicación de Mapas. Esto significa que ahora puedes usar ES|QL para buscar datos geoespaciales en Elasticsearch y visualizar los resultados en un mapa.

Hay una nueva opción de capa en el menú de agregar capas, llamada "ES|QL". Como todas las características geoespaciales descritas hasta ahora, esto está en "vista previa técnica". Seleccionar esta opción te permite agregar una capa al mapa basada en los resultados de un ES|Consulta QL. Por ejemplo, podrías agregar una capa al mapa que muestre todos los aeropuertos del mundo.

O podrías agregar una capa que muestre los polígonos del índice de airport_city_boundaries , o mejor aún, ¿qué tal esa compleja consulta de ENRICH arriba que genera estadísticas sobre cuántos aeropuertos hay en cada región?

¿Qué sigue ahora?

El anterior blog de búsqueda geoespacial se centraba en el uso de funciones como ST_INTERSECTS para realizar búsquedas, disponibles en Elasticsearch desde la versión 8.14. Y este blog te muestra cómo importar los datos que usamos para esas búsquedas. Sin embargo, Elasticsearch 8.15 venía con una función especialmente interesante: ST_DISTANCE que puede usar para realizar búsquedas espaciales eficientes, ¡y este será el tema del próximo blog!

Elasticsearch 8.12 y 8.13 llevaron soporte básico para tipos geoespaciales a ES|QL. Esto se mejoró significativamente con la incorporación de capacidades de búsqueda geoespacial en la versión 8.14. Más importante aún, este soporte fue diseñado para ajustar estrechamente al estándar Simple Feature Access del Open Geospatial Consortium (OGC) empleado por otras bases de datos espaciales como PostGIS, facilitando mucho su uso para expertos en SIG familiarizados con estos estándares.

En este blog, te mostraremos cómo usar ES|QL para realizar búsquedas geoespaciales y cómo se compara con los equivalentes SQL y Query DSL. También te mostraremos cómo usar ES|QL para realizar uniones espaciales y cómo visualizar los resultados en Kibana Maps. Ten en cuenta que todas las funciones descritas aquí están en "vista previa técnica", y nos encantaría conocer vuestros comentarios sobre cómo podemos mejorarlas.

Búsqueda de datos geoespaciales

Empecemos con una consulta de ejemplo:

Esto realiza una búsqueda de cualquier polígono de límite de ciudad que intersecte con un polígono rectangular alrededor del Aeropuerto Internacional Sanya Phoenix (SYX).

En un conjunto de datos de ejemplo de aeropuertos, ciudades y límites urbanos, esta búsqueda encuentra el polígono que se cruza y devuelve los campos deseados del documento correspondiente:

Abbrev

aeropuerto

región

ciudad

city_location

SYX

Sanya Phoenix Internacional

天涯区

Sanya

POINT(109.5036 18.2533)

¡Eso fue fácil! Ahora compáralo con el tradicional DSL de Elasticsearch Query para la misma consulta:

Ambas consultas son bastante claras en su intención, pero el ES|La consulta QL se parece mucho a SQL. La misma consulta en PostGIS es la siguiente:

Mira atrás en el ES|Ejemplo de QL. Muy parecido, ¿verdad?

Comprobamos que los usuarios actuales de la API de Elasticsearch encuentran ES|QL mucho más fácil de usar. Ahora esperamos que los usuarios existentes de SQL, especialmente los de SQL Espacial, descubran que ES|QL se siente muy familiar con lo que están acostumbrados a ver.

¿Por qué no SQL?

¿Y qué pasa con Elasticsearch SQL? Lleva un tiempo existiendo y tiene algunas características geoespaciales. Sin embargo, Elasticsearch SQL se escribía como un envoltorio sobre la API original de Consultas, lo que significaba que solo se soportaban consultas que podían transpilarse a la API original. ES|QL no tiene esta limitación. Ser una pila completamente nueva permite muchas optimizaciones que no eran posibles en SQL. Nuestros benchmarks muestran ES|QL suele ser muy rápido que la API de Consultas, ¡especialmente con agregaciones!

Diferencias con SQL

Claramente, por el ejemplo anterior, ES|QL es algo similar a SQL, pero hay algunas diferencias importantes. Por ejemplo, ES|QL es un lenguaje de consulta por pipes, que comienza con un comando fuente como FROM y luego encadena todos los comandos posteriores junto con el pipe | carácter. Esto facilita mucho entender cómo cada comando recibe una tabla de datos y realiza alguna acción sobre esa tabla, como filtrar con WHERE, agregar columnas con EVAL, o realizar agregaciones con STATS. En lugar de comenzar con SELECT para definir las columnas de salida finales, puede haber uno o más comandos KEEP , siendo el último el que especifica los resultados finales. Esta estructura simplifica el razonamiento sobre la consulta.

Centrándonos en el comando WHERE del ejemplo anterior, podemos ver que se parece bastante al ejemplo de PostGIS:

ES|QL

PostGIS

Aparte de la diferencia en los caracteres de comillas de cadena, la mayor diferencia está en cómo tipificamos la cadena a un tipo espacial. En PostGIS, usamos el sufijo ::geometry , mientras que en ES|QL, usamos el sufijo ::geo_shape . Esto se debe a que ES|QL se ejecuta dentro de Elasticsearch, y el operador de typecasting :: puede usar para convertir una cadena a cualquiera de los ES| soportadosQL tipia, en este caso, un geo_shape. Además, los tipos geo_shape y geo_point en Elasticsearch implican el sistema de coordenadas espaciales conocido como WGS84, más comúnmente conocido con el número SRID 4326. En PostGIS, esto debe ser explícito, de ahí el uso del prefijo SRID=4326; a la cadena WKT. Si se elimina ese prefijo, el SRID se pondrá en 0, que es más parecido a los tipos de Elasticsearch cartesian_point y cartesian_shape, que no están vinculados a ningún sistema de coordenadas específico.

Ambos ES|QL y PostGIS también proporcionan sintaxis de funciones de conversión de tipos:

ES|QL

PostGIS

Funciones OGC

Elasticsearch 8.14 introduce las siguientes cuatro funciones de búsqueda espacial OGC:

ES|QL

PostGIS

Descripción

ST_INTERSECTS

ST_Intersects

Devuelve verdadero si dos geometrías se cruzan, y falso en caso contrario.

ST_DISJOINT

ST_Disjoint

Devuelve verdadero si dos geometrías no se intersectan, y falso en caso contrario. El inverso de ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Devuelve verdadero si una geometría contiene otra, y falso en caso contrario.

ST_WITHIN

ST_Within

Devuelve verdadero si una geometría está dentro de otra, y falso en caso contrario. El inverso de ST_CONTAINS.

Estas funciones se comportan de forma similar a sus contrapartes PostGIS y se emplean de la misma manera. Por ejemplo, ST_INTERSECTS devuelve verdadero si dos geometrías se intersectan y falso en caso contrario. Si sigues los enlaces de documentación de la tabla anterior, puede que notes que todos los ES|Los ejemplos de QL están dentro de una cláusula de WHERE luego de una cláusula de FROM , mientras que todos los ejemplos de PostGIS usan geometrías literales. De hecho, ambas plataformas soportan el uso de las funciones en cualquier parte de la consulta donde tengan sentido.

El primer ejemplo en la documentación de PostGIS para ST_INTERSECTS es:

El ES|El equivalente en QL de esto sería:

Fíjate en que no especificamos el SRID en el ejemplo de PostGIS. Esto se debe a que en PostGIS, al usar el tipo geometry , todos los cálculos se realizan en un sistema de coordenadas planas, por lo que si ambas geometrías tienen el mismo SRID, no importa cuál sea el SRID. En Elasticsearch, esto también es cierto para la mayoría de las funciones, sin embargo, hay excepciones donde geo_shape y geo_point emplean cálculos esféricos, como veremos en el próximo blog sobre búsqueda por distancia espacial.

ES|Versatilidad en QL

Vimos ejemplos arriba de usar funciones espaciales en cláusulas WHERE y en comandos ROW . ¿Dónde más tendrían sentido? Un lugar muy útil es en el comando EVAL . Este comando te permite evaluar una expresión y devolver el resultado. Por ejemplo, determinemos si los centroides de todos los aeropuertos agrupados por el nombre de sus países están dentro de un límite que delimita el país:

Se esperan los resultados: el centroide de los aeropuertos del Reino Unido está dentro del límite del Reino Unido, y no dentro del límite de Islandia, y viceversa:

centroide

Recuento

in_uk

in_iceland

within_uk

within_iceland

POINT (-21.946634463965893 64.13187285885215)

1

falso

true

falso

true

POINT (-2.597342072712148 54.33551226578214)

17

true

falso

true

falso

POINT (0.04453958108176276 23.74658354606057)

873

falso

falso

falso

falso

De hecho, estas funciones pueden usar en cualquier parte de la consulta donde su firma tenga sentido. Todos toman dos argumentos, que son o bien un objeto espacial literal o un campo de un tipo espacial, y todos devuelven un valor booleano. Una consideración importante es que el sistema de referencia de coordenadas (CRS) de las geometrías debe coincidir, o se devolverá un error. Esto significa que no puedes mezclar geo_shape y cartesian_shape tipos en la misma llamada de función. Sin embargo, puedes mezclar geo_point y geo_shape tipos, ya que el tipo geo_point es un caso especial del tipo geo_shape , y ambos comparten el mismo sistema de referencia de coordenadas. La documentación de cada una de las funciones definidas anteriormente lista las combinaciones de tipos soportadas.

Además, cualquiera de los dos argumentos puede ser un literal espacial o un campo, en cualquiera de los dos ordenes. Incluso puedes especificar dos campos, dos literales, un campo y un literal, o un literal y un campo. El único requisito es que los tipos sean compatibles. Por ejemplo, esta consulta compara dos campos en el mismo índice:

La consulta básicamente pregunta si la ubicación de la ciudad está dentro del límite de la ciudad, lo cual generalmente debería ser cierto, pero siempre hay excepciones:

cardinalidad

Recuento

in_city

poco

29

falso

mucho

740

true

Una pregunta mucho más interesante sería si la ubicación del aeropuerto está dentro de los límites de la ciudad a la que sirve el aeropuerto. Sin embargo, la ubicación del aeropuerto se encuentra en un índice diferente al que contiene los límites de la ciudad. Esto requiere un método para consultar y correlacionar eficazmente los datos de estos dos índices separados.

Unirías espaciales

ES|QL no soporta comandos JOIN, pero puedes lograr un caso especial de unión usando el comando ENRICH, que se comporta de forma similar a una 'unión izquierda' en SQL. Este comando funciona de forma similar a una 'unión por la izquierda' en SQL, permitiéndote enriquecer resultados de un índice con datos de otro índice basar en una relación espacial entre los dos conjuntos de datos.

Por ejemplo, enriquezcamos los resultados de una tabla de aeropuertos con información adicional sobre la ciudad a la que sirven encontrando el límite de la ciudad que contiene la ubicación del aeropuerto, y luego realicemos algunas estadísticas sobre los resultados:

Esto devuelve las 5 regiones con más aeropuertos, junto con el centroide de todos los aeropuertos que tienen regiones coincidentes, y el rango en longitud de la representación WKT de los límites de la ciudad dentro de esas regiones:

centroide

Recuento

min_wkt

max_wkt

región

PUNTO (-32.56093470960719 32.598117914802714)

90

207

207

nulo

POINT (-73.94515332765877 40.70366442203522)

9

438

438

Ciudad de Nueva York

POINT (-83.10398317873478 42.300230911932886)

9

473

473

Detroit

POINT (-156.3020245861262 20.176383580081165)

5

307

803

Hawai

POINT (-73.88902732171118 45.57078813901171)

4

837

837

Montréal

Entonces, ¿qué pasó realmente aquí? ¿Dónde ocurrió la supuesta JOIN ? El núcleo de la consulta reside en el comando ENRICH :

Este comando instruye a Elasticsearch para enriquecer los resultados recuperados del índice de airports y realizar una unión intersects entre el campo city_location del índice original y el campo city_boundary del índice de airport_city_boundaries , que usamos en algunos ejemplos anteriores. Pero parte de esta información no es claramente visible en esta consulta. Lo que sí vemos es el nombre de una política de enriquecimiento city_boundaries, y la información que falta está encapsulada dentro de esa definición de política.

Aquí podemos ver que realizará una consulta geo_match (intersects es el valor predeterminado), el campo a emparejar es city_boundary, y los enrich_fields son los campos que queremos agregar al documento original. Uno de esos campos, el region , se usó como clave de agrupación para el comando STATS , algo que no podríamos hacer sin esta capacidad de 'unión izquierda'. Para más información sobre las pólizas de enriquecimiento, consulte la documentación de enriquecimiento. Al leer esos documentos, notarás que describen el uso de los índices enrich para enriquecer datos en tiempo de indexación, configurando pipelines de ingest. Esto no es necesario para ES|QL, ya que el comando ENRICH funciona en el momento de la consulta. Basta con preparar el índice de enriquecimiento con los datos y la política de enriquecimiento necesarios, y luego usar el comando ENRICH en tu ES|Consultas QL.

También puede que notes que la región más común era null. ¿Qué podría implicar esto? Recuerda que comparé este comando con un 'left join' en SQL, lo que significa que si no se encuentra ningún límite de ciudad coincidente para un aeropuerto, el aeropuerto sigue devolver pero con valores null para los campos del índice de airport_city_boundaries . Resulta que había 89 aeropuertos que no encontraron city_boundarycoincidentes, y un aeropuerto con un region campo de null. Esto llevó a un recuento de 90 aeropuertos sin region en los resultados. Otro detalle interesante es la necesidad del comando MV_EXPAND . Esto es necesario porque el comando ENRICH puede devolver múltiples resultados por cada fila de entrada, y MV_EXPAND ayuda a separar estos resultados en varias filas, una para cada resultado. Esto también aclara por qué "Hawái" muestra resultados min_wkt y max_wkt diferentes: había varias regiones con el mismo nombre pero diferentes límites.

Kibana Maps

Kibana agregó soporte para Spatial ES|QL en la aplicación de Mapas. Esto significa que ahora puedes usar ES|QL para buscar datos geoespaciales en Elasticsearch y visualizar los resultados en un mapa.

Hay una nueva opción de capa en el menú de agregar capas, llamada "ES|QL". Como todas las características geoespaciales descritas hasta ahora, esto está en "vista previa técnica". Seleccionar esta opción te permite agregar una capa al mapa basada en los resultados de un ES|Consulta QL. Por ejemplo, podrías agregar una capa al mapa que muestre todos los aeropuertos del mundo.

O podrías agregar una capa que muestre los polígonos del índice de airport_city_boundaries , o mejor aún, ¿qué tal esa compleja consulta de ENRICH arriba que genera estadísticas sobre cuántos aeropuertos hay en cada región?

¿Qué sigue ahora?

Quizá notaste que en dos de los ejemplos anteriores incluimos otra función espacial ST_CENTROID_AGG. Esta es una función agregadora empleada en el comando STATS , y la primera de muchas funciones de análisis espacial que planeamos agregar a ES|QL. ¡Escribiremos sobre ello en el blog cuando tengamos más que mostrar!

Antes de eso, queremos contarte más sobre una función especialmente emocionante en la que trabajamos: la capacidad de realizar búsquedas espaciales, una de las funciones de búsqueda espacial más empleadas en Elasticsearch. ¿Te imaginas cómo sería la sintaxis de las búsquedas a distancia? ¿Quizá similar a una función OGC? ¡Permanece atento al próximo blog de este serial para descubrirlo!

Alerta de spoilers: Elasticsearch 8.15 acaba de ser lanzado, y la búsqueda por distancia espacial con ES|¡QL está incluido!

ES|QL

ES|QL es un nuevo lenguaje de consulta Elasticsearch introducido en Elasticsearch 8.11.0. Ahora mismo, está disponible en vista previa técnica. Proporciona una forma poderosa de filtrar, transformar y analizar los datos almacenados en Elasticsearch.

Emplea "tuberías" (|) para manipular y transformar datos paso a paso. Este enfoque permite a los usuarios componer un serial de operaciones, donde la salida de una operación se convierte en la entrada para la siguiente, permitiendo transformaciones y análisis complejos de datos.

Por ejemplo, la siguiente consulta devuelve los primeros 3 documentos (filas) del índice sample_data :

Caso de uso: ES|Funciones de QL en el cliente oficial de PHP

Para ilustrar el ES|Características de QL desarrolladas en el cliente oficial de PHP, almacenamos en Elasticsearch un archivo CSV de 81.828 libros (54,4 MB) incluyendo la siguiente información:

Extrajimos esta lista del conjunto de datos de Amazon Books Reviews, disponible al público.

Creamos un índice books con los siguientes mapeos de Elasticsearch:

El valor rating es la media de las reseñas de clasificación tomadas del archivo Books_rating.csv de 2,9 GB.

Aquí puedes encontrar el script PHP que usamos para importar en masa todos los libros en Elasticsearch. La operación a granel consumía 7 segundos y 28 MB de RAM usando PHP 8.2.17. Con el mapeo propuesto, el tamaño del índice en Elasticsearch es de unos 62 MB.

Mapa ES|Resultados QL a un objeto PHP o clase personalizada

Podemos ejecutar ES|Consulta QL en PHP usando el punto final esql()->query() . El resultado de esta consulta es una estructura de datos de tabla. Esto se expresa en JSON usando los campos columns y values . En el campo columns tenemos la definición de name y type .

Aquí tienes un ejemplo de ES|Consulta QL para recuperar los 10 mejores libros escritos por Stephen King ordenados por las reseñas de ranking de usuarios:

El resultado JSON de Elasticsearch es el siguiente:

En este ejemplo tenemos 6 propiedades (autor, descripción, editor, valoración, título, año) relacionadas con un libro y 10 resultados, todos libros de Stephen King.

Una lista de todos los tipos soportados en ES|Aquí se informa de QL.

El objeto de respuesta $result puede acceder como un array, una cadena o un objeto ( ver aquí para más información).

Usando la interfaz objeto, podemos acceder a los valores mediante propiedades e índices. Por ejemplo, $result->values[0][4] devuelve el título (4) del primer libro (0) en la lista, $result->values[1][3] devuelve el puntaje de rango (3) del segundo libro (1), etc. Recuerda, el índice de un array en PHP empieza desde cero.

Esta interfaz puede ser suficientemente buena para algunos casos de uso, pero la mayoría de las veces nos gustaría tener una variedad de objetos como resultado.

Para mapear el resultado en un array de objetos podemos usar la nueva función mapTo() de elasticsearch-php.

Esta función está disponible directamente en el objeto de respuesta Elasticsearch. Eso significa que puedes acceder a él de la siguiente manera:

Si tienes una clase Book personalizada, puedes mapear el resultado usándola de la siguiente manera:

Si tu clase tiene otras propiedades además de las incluidas en el ES|Resultado QL, esto también funcionará. La función mapTo() usará solo las propiedades devueltas como columnas del ES|Resultado de QL.

Puedes descargar todos los ejemplos que se mencionan en este artículo aquí.