Comment MATCH et TO_TEXT permettent la recherche full-text sur n'importe quelle expression ES|QL

Commençons par une requête qui était impossible dans Elasticsearch 9.4, qui utilise la commande EVAL :

Dans cet exemple, le résumé ne dispose d'aucune configuration de mapping ou d'analyseur. Il n'est pas non plus associé à un index inversé. Il n'existe que le temps de cette requête, mais il est tout de même possible d'effectuer des recherches dessus. Deux ajouts permettent d'y parvenir.

Premièrement, la fonction MATCH accepte désormais n'importe quelle expression comme premier argument, et non plus seulement un champ mappé. Cela inclut les colonnes générées par EVAL ainsi que les résultats de fonctions utilisés directement dans l'expression. Cela englobe également les champs non mappés chargés directement depuis le document d'origine. De plus, tous les types de données habituellement acceptés par MATCH sont compatibles avec ce nouveau cas d'utilisation.

Deuxièmement, la nouvelle fonction TO_TEXT, qui est la première fonction de conversion ES|QL qui produit une sortie de type texte. Jusqu'à présent, les colonnes de texte ne pouvaient provenir que de champs mappés indexés, et toutes les chaînes générées par les expressions ES|QL étaient des valeurs de mots-clés plutôt que de texte. Cette distinction est importante car MATCH traite les deux différemment : les valeurs de texte sont analysées, tandis que les valeurs de mots-clés sont comparées exactement, reproduisant ainsi le mécanisme par lequel une requête MATCH sur un champ de mot-clé indexé est réécrite en requête de terme. TO_TEXT(x) permet d'indiquer à ES|QL de traiter cette chaîne comme du texte intégral.

Cette fonctionnalité est disponible en préversion technique dans Elasticsearch 9.5, et, à ce titre, présente certaines limitations :

• Pour l'instant, elle se limite au filtrage. Une opération MATCH portant sur une expression ne contribue pas encore au score de pertinence ; seuls les matchs sur des champs indexés influencent ce score.

• Les options de requête telles que la tolérance aux erreurs ne sont pas encore prises en charge lors de l'utilisation de MATCH sur une expression.

• Le texte généré à l'exécution est analysé à l'aide de l'analyseur standard. Ce comportement n'est pas encore configurable.

Ces limitations seront résolues prochainement.

Pourquoi utiliser la recherche full-text plutôt que LIKE ou RLIKE dans ES|QL ?

ES|QL disposait déjà de deux méthodes pour rechercher des chaînes de caractères sans index : LIKE (caractères génériques) et RLIKE (expressions régulières). Les deux fonctionnant sur n'importe quelle expression de chaîne, on peut donc se demander ce que MATCH apporte. La réponse est l'analyse, une forme plus avancée de recherche qui utilise des techniques telles que la lemmatisation et les synonymes. Elle intègre également la gestion des mots vides.

LIKE effectue une simple correspondance de sous-chaîne, sans aucune compréhension des mots qui composent la chaîne. Supposons, par exemple, que vous recherchiez des messages de log à propos d'un renard :

La correspondance "Fox spotted near the henhouse" n'est pas détectée en raison de la majuscule, alors que la correspondance "Outfoxed by the competition", qui n'a aucun rapport avec un renard, est détectée. Le système échoue dans les deux cas : faux négatifs liés à la casse et faux positifs dus à des sous-chaînes incluses dans d'autres mots.

Les expressions régulières peuvent résoudre le problème de la casse, mais la gestion des limites de mots devient vite complexe. Quelque chose comme :

Et même là, ce n'est pas encore tout à fait ça. L'expression ne détecte pas le mot "fox" en fin de phrase s'il est suivi d'un point d'exclamation ou d'interrogation, et elle ne tient pas compte des tabulations, des guillemets ou des parenthèses. Chaque correction allonge le pattern, obligeant la personne suivante qui lira la requête à procéder à une ingénierie inverse pour comprendre ce qu'elle fait réellement.

MATCH résout le problème, car il fait passer aussi bien la requête que la valeur par un analyseur qui découpe le texte à l'aide de tokens et le convertit en minuscules, puis compare les termes entre eux :

Cette requête correspondra à des valeurs comme "The quick brown fox" et "FOX spotted near the henhouse", mais pas à "Outfoxed by the competition" ou "FOXTROT protocol enabled", quelle que soit la ponctuation entourant les mots. Bien entendu, tout cela fonctionne également pour les requêtes comportant plusieurs termes, comme MATCH(TO_TEXT(message), "brown fox"), exactement comme on peut s'y attendre.

Des travaux sont en cours pour permettre l'utilisation des 36 analyseurs linguistiques dédiés, avec la prise en charge des langues naturelles sur des données jamais indexées ni mappées.

Cas d'utilisation de la recherche full-text pour des données non indexées et non mappées

Les exemples ci-dessus portaient sur des valeurs calculées à partir de champs mappés. Les cas d'utilisation les plus intéressants de la fonction MATCH d'ES|QL appliquée à des expressions concernent des données qui, auparavant, n'étaient pas du tout interrogeables. Examinons quelques-uns de ces cas.

Comment rechercher des champs non mappés dans ES|QL sans ajouter de mapping

Il arrive parfois que l'on doive exclure un champ de nos mappings, comme une trace de pile détaillée ou une charge utile de requête brute. On peut même omettre un blob à déboguer. L'indexation de l'un de ces éléments consommerait de l'espace disque et de la mémoire pour chaque document, ce qui ne se justifierait pas pour un champ que l'on n'interroge peut-être qu'une fois par trimestre.

Cette décision a toujours été irrévocable, car les champs non mappés étaient totalement invisibles pour les requêtes. Dans Elasticsearch 9.5, vous pouvez utiliser SET unmapped_fields="load" pour permettre à ES|QL de charger directement les champs non mappés depuis le document source en tant que mots-clés. En enveloppant ensuite le résultat dans TO_TEXT, vous pouvez exécuter une recherche full-text sur ces champs :

Ici, stack_trace n'a jamais été mappé. Chaque valeur est récupérée depuis les documents d'origine et analysée à la volée ; la correspondance est établie ligne par ligne. C'est un travail conséquent, qui ne sera jamais aussi rapide qu'une recherche via un index inversé. Toutefois, ce champ que vous n'aviez pas indexé n'est plus impossible à interroger. Vous pouvez ainsi conserver un mapping léger pour les besoins courants tout en étant capable de répondre, le moment venu, à une question qui ne se pose qu'une fois par trimestre.

Recherche full-text sur un champ de mots-clés sans réindexation

Les champs de mots-clés offrent de nombreuses possibilités. Ils permettent une correspondance exacte, des agrégations rapides et le tri des données ; c'est pourquoi tant de champs sont finalement mappés de cette manière. Toutefois, le mapping est défini au moment de l'arrivée des données, et il est fréquent de se retrouver dans une situation où l'on souhaite exploiter ces données différemment de ce qui avait été prévu initialement. Par exemple, le champ product_name a peut-être été mappé en tant que mot-clé parce que les tableaux de bord s'appuyaient sur lui pour des agrégations. Or, après avoir accumulé une année de données produits, un utilisateur peut soudainement vouloir effectuer des recherches au sein même des valeurs de ce champ.

L'ancienne solution consiste à convertir le mapping en texte (ou à ajouter un champ multiple) et à tout réindexer. Cette opération est longue et coûteuse et, bien souvent, les utilisateurs ne veulent pas s'en donner la peine. La nouvelle solution se résume à un seul appel de fonction :

TO_TEXT convertit à la volée les valeurs de mot-clés en texte, permettant ainsi à MATCH de les analyser plutôt que de les comparer de manière exacte. Cela vous permet d'interroger un champ de mot-clé sans avoir à créer de mapping ni à réindexer le document source. Si cette recherche est amenée à devenir une requête courante, l'indexation du champ en tant que texte reste la solution idéale à long terme. Toutefois, TO_TEXT vous permet d'obtenir une réponse immédiate, sans travail supplémentaire.

Recherche sur le même champ dans des index aux mappings différents

ES|QL peut couvrir plusieurs index, et un même champ ne doit pas nécessairement présenter la même structure dans chacun d'eux. Lorsqu'un même champ possède des types différents selon les index, ES|QL le traite comme un type d'union, et une fonction de conversion résout le conflit. Prenons l'exemple d'un champ de message qui est de type texte dans le modèle d'index de cette année, alors qu'il était de type mot-clé dans celui de l'année précédente :

Chaque valeur est analysée au moment de la requête, qu'elle provienne de l'index texte ou de l'index mots-clés. Les valeurs de type mot-clé issues des anciens index sont découpées en tokens et converties en minuscules, tout comme les autres ; ainsi, la recherche "connection reset" permet de trouver "Connection RESET by peer", quel que soit l'index dans lequel la donnée est stockée.

Un autre cas intéressant est celui où un champ est mappé dans un seul index mais également présent (et non mappé) dans l'autre :

Il existe une nuance ici qu'il convient de souligner. Si error_details est mappé dans logs-2026 mais pas dans logs-2025, Elasticsearch ne peut pas déléguer cette requête à Lucene, car les index où le champ n'est pas mappé ne renverraient silencieusement aucun résultat. Au lieu de cela, le planificateur détecte que le champ n'est potentiellement pas mappé et évalue l'intégralité de la clause MATCH ligne par ligne, quelle que soit la provenance des lignes. Vous n'avez pas besoin de savoir à quels index appartient le mapping de ce champ ; la requête répond simplement à la question.

Comment ES|QL analyse le texte au moment de la requête sans index inversé

Lorsque ES|QL planifie une opération MATCH sur une expression, il analyse la chaîne de requête une seule fois, au préalable, pour la transformer en un ensemble de termes. La manière dont chaque ligne est ensuite évaluée dépend du type de l'expression :

Type d'expression

Traitement

Comportement correspondant

texte (via TO_TEXT)

L'analyseur segmente la valeur à l'aide de tokens et la convertit en minuscules

Comparaison token par token ; une ligne correspond si un token correspond à un terme de requête quelconque (sémantique OU)

mot-clé, adresse IP, date, numérique

Aucune analyse ; constante de la requête convertie une seule fois vers le type natif

Comparaison exacte par ligne

Ces deux méthodes contournent entièrement Lucene et évaluent les valeurs ligne par ligne. Le chemin non textuel reproduit exactement le comportement d'une requête de correspondance lorsqu'elle est déléguée à Lucene pour ces types de champs ; la sémantique reste donc cohérente, que la requête utilise un index ou non.

Une recherche via un index inversé s'effectue au moment de l'ingestion et n'interagit jamais avec les documents non correspondants lors de l'exécution de la requête. À l'inverse, une opération MATCH effectuée à l'exécution réalise cette analyse au moment de la requête, pour chaque ligne traitée. La première méthode est rapide car le travail a déjà été accompli en amont, tandis que la seconde offre de la flexibilité, car les données n'ont pas besoin d'avoir été indexées au préalable.

Prochaines évolutions de la recherche full-text dans ES|QL

Tout ce qui est présenté dans cet article constitue la première étape d'une initiative plus vaste visant à permettre à la recherche ES|QL de fonctionner sur n'importe quelles données, et pas seulement sur celles indexées au préalable. Nous travaillons activement à lever les limitations mentionnées précédemment, et la roadmap va encore plus loin :

• Calcul du score. Les correspondances évaluées à l'exécution contribueront au score (_score) ; vous pourrez ainsi effectuer un tri par pertinence, même si les données n'ont jamais été indexées.

• MATCH_PHRASE sur les expressions. Déjà disponible dans Elastic Cloud Serverless et prochainement dans la Suite Elastic version 9.6.

• Analyseurs configurables. Prise en charge des analyseurs pour MATCH et MATCH_PHRASE sur les expressions, permettant l'utilisation d'analyseurs linguistiques, de la lemmatisation et de synonymes au moment de la requête.

• Options de correspondance. Des options telles que la tolérance et l'opérateur pour les correspondances à l'exécution.

• Recherche vectorielle. Génération d'embeddings par ligne et exécution de l'algorithme des k plus proches voisins (kNN) sur des expressions dense_vector évaluées à l'exécution, permettant d'étendre la recherche sémantique aux données non indexées.

Essayez dès aujourd'hui la recherche full-text ES|QL sur les expressions

Vous pouvez essayer la recherche au moment de l'exécution dès maintenant. Elle est disponible dans Elastic Cloud Serverless, où les nouvelles fonctionnalités ES|QL sont déployées en priorité, et proposée en préversion technique dans Elasticsearch 9.5. Commencez par consulter la documentation de référence sur les fonctions de recherche ainsi que les limites actuelles sur la page dédiée aux limitations ES|QL. Cette préversion technique est destinée à recueillir votre avis : si vous effectuez une recherche sur un élément qui n'a jamais été indexé et que le résultat vous surprend – en bien ou en mal –, n'hésitez pas à nous en faire part.

Quoi de neuf dans la création de tableaux de bord IA avec Kibana

Fonctionnalité

Préversion technique (9.4)

DG (9.5)

Gestion des erreurs

Pas de nouvelle tentative en cas d'échec des requêtes ES|QL

Jusqu'à trois tentatives automatiques avec inspection et ajustement des requêtes

Coût de génération ES|QL

Toutes les requêtes sont acheminées via le modèle principal

Modèle de routage à plusieurs niveaux, jusqu'à 5 fois moins cher

Plage temporelle

Fenêtre fixe par défaut

Sélection automatique en fonction de la distribution temporelle des données

Contrôles de filtre

Non pris en charge

Ajoutés automatiquement pour les champs les plus pertinents

Graphiques Vega-Lite

Non pris en charge

Création en langage naturel, incluant les nuages de points, les diagrammes en boîte, la mise en forme conditionnelle et les infobulles personnalisées

Modification de graphique

Non pris en charge

Modification des panneaux Vega-Lite existants en langage naturel

Récupération automatique des erreurs pour la génération de tableaux de bord par IA

Dans la préversion technique, l'agent ne relançait pas les requêtes ES|QL ayant échoué. Avec la version 9.5, il détecte les erreurs de requête et tente de les réexécuter jusqu'à trois fois ; il analyse chaque erreur et ajuste la requête avant d'abandonner. En pratique, cela élimine la majeure partie des problèmes de panneaux vides et permet d'obtenir des tableaux de bord qui s'affichent correctement dès la première tentative.

Pourquoi la création de tableaux de bord par IA est-elle moins coûteuse dans Elastic 9.5 ?

Les étapes de génération d'un tableau de bord ne nécessitent pas toutes le même niveau de raisonnement. Dans la version 9.5, la génération ES|QL passe par un modèle plus léger par défaut et revient au modèle principal uniquement en cas de besoin. Si votre connecteur utilise Claude Opus 4.8 d'Anthropic, la génération ES|QL pour tous les panneaux revient alors cinq fois moins cher.

Sélection automatique de la plage temporelle basée sur vos données

Les tableaux de bord ne sont utiles que s'ils affichent la fenêtre de données appropriée. L'agent applique désormais une logique optimisée pour sélectionner une période pertinente au regard des données interrogées, à moins que l'utilisateur ne spécifie une plage horaire particulière. Il prend en compte la répartition temporelle des données et adapte son choix en conséquence, qu'il s'agisse de la dernière heure pour un incident en cours ou des 90 derniers jours pour une analyse de tendance, plutôt que de s'en tenir systématiquement à une fenêtre temporelle fixe.

Contrôles de filtrage automatiques sur les tableaux de bord générés par IA

La création de tableaux de bord prend désormais en charge les contrôles, c'est-à-dire des filtres interactifs qui permettent aux utilisateurs d'affiner un tableau de bord en fonction des valeurs des champs sans modifier les requêtes sous-jacentes. Lors de la génération d'un tableau de bord, l'agent ajoute automatiquement des contrôles en haut pour les champs les plus pertinents à filtrer.

Graphiques Vega-Lite à partir du langage naturel : types de graphiques et mise en forme au-delà des valeurs par défaut

Vega et Vega-Lite prennent en charge une grande variété de types de graphiques et de personnalisations dans Kibana. Avec la version 9.5, vous pouvez les créer en langage clair au lieu d'écrire le code vous-même. 

Nuages de points, diagrammes en boîte et autres types de graphiques Vega-Lite

Les nuages de points, les diagrammes en boîte, les graphiques à facettes, les graphiques à bulles et les graphiques de composition (tels que la combinaison d'histogrammes et de cartes thermiques), entre autres, sont pris en charge par Vega-Lite. Un prompt comme Affiche-moi un nuage de points du temps de réponse en fonction de la taille de la requête, avec une coloration par nom de service génère un panneau Vega-Lite intégrant les mappings de données appropriés. Ces graphiques utilisent les palettes de couleurs par défaut de Kibana afin de s'harmoniser avec le reste du tableau de bord.

Mise en forme conditionnelle, infobulles personnalisées et étiquettes sur graphiques standard

Même pour les types de graphiques déjà intégrés dans les tableaux de bord comme les graphiques à barres, linéaires ou en aires, il est parfois nécessaire de disposer d'un contrôle plus poussé que celui offert par les fonctionnalités par défaut. Vega-Lite permet de combler cette lacune via le chat. En voici quelques exemples :

• Mise en forme conditionnelle des couleurs : appliquez une couleur différente aux points de données dépassant un certain seuil ; par exemple, colorez en rouge les points d'un graphique linéaire ou en barres lorsqu'une métrique dépasse votre objectif de niveau de service (SLO). Demandez à l'agent quelque chose comme Colore en rouge tous les points dépassant 500 ms sur mon graphique linéaire.

  

• Marqueurs et étiquettes personnalisés : ajoutez des émojis, des symboles ou des étiquettes textuelles intégrées aux points de données pour obtenir des indicateurs d'état visibles d'un seul coup d'œil.

  

• Infobulles personnalisées : enrichissez les états au survol avec des métriques supplémentaires, du contexte ou des valeurs calculées qui ne figurent pas sur les axes du graphique. Demandez par exemple Ajoute une infobulle indiquant le nombre total d'enregistrements et le pourcentage par barre.

  

Cette méthode fonctionne également pour modifier des graphiques Vega existants. Si vous avez un panneau Vega-Lite nécessitant une retouche comme modifier une échelle de couleurs, ajuster un axe ou changer le type de marqueur, décrivez la modification dans le chat plutôt que de fouiller dans le code JSON.

Comment nous avons créé la génération Vega-Lite en langage naturel dans Kibana

Générer un graphique Vega-Lite à partir d'une phrase ne se résume pas à un simple prompt unique demandant au modèle de fournir du JSON. Nous avons mis au point un petit pipeline de type agent capable de transformer une intention exprimée en langage naturel en un graphique validé et étayé par des données.

À la réception d'une requête, l'agent détermine d'abord si Vega-Lite est la solution appropriée. Pour les requêtes Vega-Lite, il ancre la visualisation sur une véritable requête ES|QL adressée à Elasticsearch, puis utilise un modèle pour générer le code Vega-Lite. Avant le rendu, le résultat passe par une couche de normalisation qui corrige le schéma et lie la requête canonique ; des transformations visant à garantir la sécurité du rendu sont également appliquées.

Quelques choix de conception rendent ce workflow fiable :

• Appel d'outil typé : la création de graphiques repose sur l'appel structuré d'un outil plutôt que sur l'insertion de code Vega-Lite en format libre dans la conversation.

• Génération contrainte : le modèle génère du code Vega-Lite selon un schéma défini, ce qui rend la sortie plus prévisible et plus facile à valider.

• Exemples sélectionnés : les schémas structurels, tels que la navigation à facettes, les marqueurs superposés et les cartes thermiques, fournissent des indications sans copier les données sous-jacentes.

• Boucles d'exécution et de vérification : les requêtes sont exécutées avant la création du graphique, et les échecs de validation déclenchent des tentatives correctives pour la génération ES|QL.

Essayez la création de tableaux de bord par IA et les graphiques Vega-Lite dans Kibana

Pour tester la création de tableaux de bord en langage naturel et les graphiques Vega-Lite, passez à Elastic 9.5 (ou commencez un essai gratuit) et ouvrez le chat dans Kibana. Demandez ensuite à l'outil de générer un tableau de bord à partir de vos données. Pour Vega-Lite, demandez un type de graphique que vous avez toujours voulu mais que vous n'avez jamais créé, comme un nuage de points ou un graphique à bulles. Si le résultat ne vous convient pas tout à fait, indiquez à l'agent ce qu'il faut modifier ; il itère avec vous.

Cela nécessite une licence Entreprise. Commencer.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.

Votre première requête

Commencez par définir un objet CLR (POCO) classique qui correspond à votre index Elasticsearch. Les noms de propriétés sont résolus en noms de colonnes ES|QL via des attributs standard System.Text.Json, comme [JsonPropertyName], ou via un JsonNamingPolicy configuré. Les mêmes règles de sérialisation des sources que celles qui s'appliquent au reste du client s'appliquent également ici.

Une fois le type défini, une requête ressemble à ceci :

Le fournisseur la traduit en ES|QL comme ceci :

Quelques détails à noter :

• Résolution des noms de propriété : p.Price devient price_usd en raison de l'attribut [JsonPropertyName], et p.Brand devient brand conformément à la politique de dénomination camelCase par défaut.

• Capture des paramètres : les variables C# minPrice et brand sont capturées comme paramètres nommés (?minPrice, ?brand). Elles sont envoyées séparément de la chaîne de requête dans la charge utile JSON, ce qui empêche l'injection et permet la mise en cache du plan de requête côté serveur.

• Flux en continu : QueryAsync<T> renvoie IAsyncEnumerable<T>. Les lignes se matérialisent une à une à mesure de leur arrivée depuis Elasticsearch.

Vous pouvez également inspecter la requête générée et ses paramètres sans l'exécuter :

Comment ça marche ? Petit rappel sur LINQ

Le mécanisme qui rend possibles les fournisseurs LINQ est la distinction entre IEnumerable<T> et IQueryable<T>.

Lorsque vous appelez .Where(p => p.Price > 100) sur un IEnumerable<T>, la lambda est compilée en un Func<Product, bool>, un délégué standard que le runtime exécute en interne. C'est le principe du LINQ-to-Objects.

Lorsque vous appelez la même méthode sur un IQueryable<T>, le compilateur C# enveloppe la lambda dans un Expression<Func<Product, bool>> à la place. Il s'agit d'une structure de données qui représente la structure du code plutôt que sa forme exécutable. L'arbre d'expression peut être inspecté, analysé et traduit dans un autre langage au moment de l'exécution.

L’interface IQueryProvider est le point d’extension. Tout fournisseur peut implémenter CreateQuery<T> et Execute<T> pour traduire ces arbres d’expressions dans une langue cible. Entity Framework utilise ceci pour émettre du SQL. Le fournisseur LINQ to ES|QL l'utilise pour émettre ES|QL.

L'arbre d'expression de la requête ci-dessus ressemble à ceci :

Arbre d'expression de l'exemple de requête.

L'arbre est imbriqué de l'intérieur vers l'extérieur : Take englobe OrderByDescending, qui englobe Where, qui englobe From, qui englobe la racine constante EsqlQueryable<Product>. Le prédicat Where est lui-même un sous-arbre des nœuds BinaryExpression pour les opérateurs &&, >=, et les opérateurs ==, avec des feuilles MemberExpression pour les accès aux propriétés et des captures de fermeture pour les variables minPrice et brand. C'est cette structure de données que le fournisseur parcourt pour produire le code ES|QL final.

Sous le capot : le pipeline de traduction

Le chemin d'une expression LINQ vers les résultats de la requête suit un pipeline en six étapes :

Aperçu du pipeline de traduction.

1. Capture de l'arbre d'expressions

Lorsque vous chaînez .Where(), .OrderBy(), .Take() et d’autres opérateurs sur un IQueryable<T>, l’infrastructure standard de LINQ construit un arbre d’expressions. EsqlQueryable<T> met en œuvre IQueryable<T> et délègue à EsqlQueryProvider.

2. Traduction

Lors de l'exécution de la requête (par énumération, appel de ToList() ou utilisation de await foreach)), le EsqlExpressionVisitor parcourt l'arbre d'expressions de l'intérieur vers l'extérieur. Il envoie chaque appel de méthode LINQ à un visiteur spécialisé :

Visiteur

Est traduit

En

WhereClauseVisitor

.Where(predicate)

Condition WHERE

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

GroupByVisitor

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

Champ SORT [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, méthodes string

Plus de 80 fonctions ES|QL

Lors de la traduction, les variables C# référencées dans les expressions sont capturées comme des paramètres nommés.

3. Modèle de requête

Les visiteurs ne produisent pas directement des chaînes de caractères. À la place, ils produisent des objets QueryCommand , une représentation intermédiaire immuable. Un objet FromCommand, un objet WhereCommand, un objet SortCommand et un objet LimitCommand, chacun représentant une commande de traitement ES|QL. Ces objets sont ensuite regroupés dans un modèle EsqlQuery.

Modèle de requête et schéma de commande.

Ce modèle intermédiaire est découplé de l'arbre d'expression et du format de sortie. Il peut être inspecté, intercepté (via IEsqlQueryInterceptor) ou modifié avant d'être formaté.

4. Formatage

EsqlFormatter parcourt chaque QueryCommand dans l'ordre et produit la chaîne ES|QL finale. Chaque commande devient une ligne, séparée par l'opérateur pipe (|) utilisé par ES|QL pour chaîner les commandes de traitement. Les identificateurs contenant des caractères spéciaux sont automatiquement échappés par des guillemets inversés.

5. Exécution

La chaîne ES|QL formatée et les paramètres capturés sont envoyés au point de terminaison /_query d'Elasticsearch sous forme de charge utile JSON. L'interface IEsqlQueryExecutor masque la couche transport, où l'architecture de packages en couches prend tout son sens.

6. Matérialisation

EsqlResponseReader transmet la réponse JSON sans mettre en mémoire tampon l'ensemble des résultats. Un arbre ColumnLayout, précalculé une fois par requête, mappe les noms de colonnes ES|QL plats (comme address.street, address.city) aux propriétés POCO imbriquées. Chaque ligne est assemblée dans une instance T et renvoyée une par une via IEnumerable<T> ou IAsyncEnumerable<T>.

L'architecture en couches

La fonctionnalité LINQ to ES|QL est répartie sur trois packages :

Architecture des packages. Elastic.Esql est le moteur de traduction pur. Il ne dépend d'aucun HTTP et intègre les visiteurs d'expressions, le modèle de requêtes, le formateur et le lecteur de réponses. Vous pouvez l'utiliser de manière autonome pour créer et analyser des requêtes ES|QL sans connexion à Elasticsearch, ce qui est utile pour les tests, la journalisation des requêtes ou la création de votre propre couche d'exécution.

Elastic.Clients.Esql est un client ES|QL léger et autonome. Il ajoute l'exécution HTTP en plus de Elastic.Esql via Elastic.Transport. Si votre application n'a besoin que d'ES|QL et d'aucune autre API Elasticsearch, il s'agit de l'option de dépendance minimale.

Elastic.Clients.Elasticsearch est le client complet Elasticsearch .NET. Il s'appuie également sur Elastic.Esql et expose le fournisseur LINQ via l'espace de noms client.Esql. C'est le point d'entrée recommandé pour la plupart des applications.

Les deux packages de la couche d'exécution fournissent leur propre implémentation de IEsqlQueryExecutor, l'interface de stratégie qui fait le lien entre la traduction et le transport.

Les trois packages sont compatibles avec Native AOT lorsqu'ils sont utilisés avec un JsonSerializerContext généré par la source. Pour le client complet, consultez la documentation Native AOT.

Au-delà des bases

L'exemple ci-dessus traitait du filtrage, du tri et de la pagination. Le fournisseur prend en charge un ensemble d'opérations plus étendu.

Agrégations

GroupBy, associé aux fonctions d'agrégation dans Select, se traduit en ES|QL STATS ... BYpar :

Projections

Select, avec des types anonymes, génère les commandes EVAL, KEEP et RENAME :

Bibliothèque riche en fonctions

Plus de 80 fonctions ES|QL sont disponibles via la classe EsqlFunctions, couvrant la gestion des dates et heures, des chaînes de caractères, des opérations mathématiques, des adresses IP, la correspondance de modèles et le calcul de scores. Les méthodes standard Math.* et string.* se traduisent également par :

LOOKUP JOIN

Les recherches par index croisé se traduisent en ES|QL LOOKUP JOINpar :

Séquence d'échappement pour ES|QL brut

Pour les fonctionnalités ES|QL non encore prises en charge par le fournisseur LINQ, vous pouvez ajouter des fragments bruts :

Requêtes asynchrones côté serveur

Pour les requêtes de longue durée, soumettez-les pour un traitement en arrière-plan sur le serveur :

Les requêtes asynchrones côté serveur sont particulièrement utiles pour les requêtes analytiques de longue durée/le traitement de grands ensembles de données, qui peuvent dépasser les seuils de délai d'expiration habituels, ou dans les environnements sensibles aux délais d'expiration avec équilibreurs de charge, passerelles API ou proxys qui imposent des délais d'expiration HTTP stricts. Les requêtes asynchrones évitent les interruptions de connexion en découplant la soumission et la récupération des résultats.

Premiers pas

LINQ to ES|QL est disponible à partir de :

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

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

Installation depuis NuGet :

dotnet add package Elastic.Clients.Elasticsearch

Les points d’entrée sont sur client.Esql:

Méthode

Retours

Cas d'utilisation

Query<T>(...)

IEnumerable<T>

Exécution synchrone

QueryAsync<T>(...)

IAsyncEnumerable<T>

Streaming asynchrone

CreateQuery<T>()

IEsqlQueryable<T>

Composition et inspection avancées

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

Requêtes de longue durée côté serveur

Pour une description complète des fonctionnalités, notamment les options de requête, l'accès à plusieurs champs, les objets imbriqués et la gestion des champs à valeurs multiples, consultez la documentation LINQ to ES|QL.

Conclusion

LINQ to ES|QL apporte toute la puissance d'expression de LINQ to C# au langage de requêtes ES|QL d'Elasticsearch, vous permettant d'écrire des requêtes fortement typées et composables sans avoir à les concevoir manuellement. Grâce à la capture automatique des paramètres, la matérialisation en flux continu et une architecture de packages modulaire scalable, allant d'une simple traduction à un client Elasticsearch complet, il s'intègre naturellement aux applications .NET de toute taille. applications .NET de toute taille. Installez le client le plus récent, configurez vos expressions LINQ pour qu'elles pointent vers un index, et laissez le fournisseur gérer le reste.

Pourquoi c'est important

La plupart des workflows analytiques classiques se résument finalement à regrouper des données. Qu'il s'agisse de calculer la consommation moyenne de données par hôte, de compter les événements par utilisateur ou d'agréger des indicateurs selon différentes dimensions, l'opération de base reste la même : associer des clés à des groupes et mettre à jour les agrégats en cours.

À petite échelle, presque n'importe quelle table de hachage convenable fonctionne bien. À grande échelle (des centaines de millions de documents et des millions de groupes distincts), les détails commencent à avoir leur importance. Les facteurs de charge, la stratégie de sondage, l'organisation de la mémoire et le comportement du cache peuvent faire la différence entre des performances linéaires et une avalanche d'erreurs de cache.

Elasticsearch prend en charge ces charges de travail depuis des années, mais nous cherchons constamment à moderniser ses algorithmes de base. C'est pourquoi nous avons évalué une nouvelle approche inspirée des tables suisses et l'avons appliquée au calcul des statistiques par ES|QL.

Que sont exactement les tables suisses ?

Les tables suisses sont une famille de tables de hachage modernes popularisées par SwissTable de Google, puis adoptées par Abseil et d'autres bibliothèques.

Les tables de hachage traditionnelles passent beaucoup de temps à rechercher des pointeurs ou à charger des clés pour finalement constater qu'elles ne correspondent pas. La caractéristique principale des tables suisses est leur capacité à rejeter la plupart des requêtes grâce à une structure de tableau en cache de petite taille, stockée séparément des clés et des valeurs et appelée octets de contrôle, ce qui réduit considérablement le trafic mémoire.

Chaque octet de contrôle représente un emplacement unique et, dans notre cas, encode deux éléments : si l'emplacement est vide et une courte empreinte numérique dérivée du hachage. Ces octets de contrôle sont disposés de manière contiguë en mémoire, généralement par groupes de 16, idéal pour le traitement SIMD (Single Instruction, Multiple Data).

Au lieu de sonder un emplacement à la fois, les tables suisses parcourent un bloc entier d'octets de contrôle à l'aide d'instructions vectorielles. En une seule opération, le processeur compare l'empreinte de la clé entrante à 16 emplacements et élimine les entrées vides. Seuls les candidats retenus après ce parcours rapide nécessitent le chargement et la comparaison des clés réelles.

Cette conception privilégie une meilleure localité du cache et réduit considérablement les chargements aléatoires, au détriment d'une petite quantité de métadonnées supplémentaires. À mesure que la table s'agrandit et que les chaînes de détection s'allongent, ces avantages deviennent de plus en plus précieux.

SIMD au centre

La vraie star de la série est l'architecture SIMD.

Les octets de contrôle sont non seulement compacts, mais aussi conçus spécifiquement pour être traités par des instructions vectorielles. Une seule comparaison SIMD peut vérifier simultanément 16 empreintes, transformant ainsi une boucle classique en quelques opérations étendues. Exemple :

En pratique, cela signifie :

• Moins de branches.

• Des chaînes de détection plus courtes.

• Moins de chargements depuis la mémoire des clés et des valeurs.

• Une bien meilleure utilisation des unités d'exécution du processeur.

La plupart des recherches ne dépassent jamais l'étape de l'analyse de l'octet de contrôle. Lorsqu'elles y parviennent, le travail restant est ciblé et prévisible. C'est précisément le type de charge de travail pour lequel les processeurs modernes excellent.

SIMD sous le capot

Pour les lecteurs qui aiment jeter un œil sous le capot, voici ce qui se passe lors de l'insertion d'une nouvelle clé dans la table. Nous utilisons l'API Panama Vector avec des vecteurs de 128 bits, opérant ainsi sur 16 octets de contrôle en parallèle.

L'extrait suivant montre le code généré sur un processeur Intel Rocket Lake avec AVX-512. Bien que les instructions reflètent cet environnement, la conception ne dépend pas d'AVX-512. Les mêmes opérations vectorielles de haut niveau sont émises sur d'autres plateformes en utilisant des instructions équivalentes (par exemple, AVX2, SSE ou NEON).

Chaque instruction a un rôle clair dans le processus d'insertion :

• vmovdqu: Charge 16 octets de contrôle consécutifs dans le registre xmm0 de 128 bits.

• vpbroadcastb: Réplique l'empreinte 7 bits de la nouvelle clé sur toutes les voies du registre xmm1.

• vpcmpeqb: Compare chaque octet de contrôle à l'empreinte diffusée, produisant un masque de correspondances potentielles.

• kmovq + test : Déplace le masque vers un registre à usage général et vérifie rapidement si une correspondance existe.

Enfin, nous avons opté pour le sondage de groupes de 16 octets de contrôle à la fois, car les tests comparatifs ont montré que l'extension à 32 ou 64 octets avec des registres plus larges n'apportait aucun avantage mesurable en termes de performances.

Intégration dans ES|QL

L'adoption du hachage suisse dans Elasticsearch n'a pas été une simple solution de remplacement. ES|QL impose des exigences strictes de gestion de la mémoire, de sécurité et d'intégration au reste du moteur de calcul.

Nous avons étroitement intégré la nouvelle table de hachage à la gestion de la mémoire d'Elasticsearch, notamment au recycleur de pages et à la comptabilisation des coupures, afin de garantir la visibilité et la limitation des allocations. Les agrégations d'Elasticsearch sont stockées de manière dense et indexées par un identifiant de groupe, ce qui optimise la structure de la mémoire et la rapidité d'itération, tout en autorisant certaines optimisations de performance grâce à l'accès aléatoire.

Pour les clés binaires de longueur variable, nous mettons en cache le hachage complet ainsi que l'identifiant du groupe. Cela évite le recalcul coûteux des codes de hachage lors du sondage et améliore la localité du cache en regroupant les métadonnées associées. Lors du rehachage, nous pouvons nous appuyer sur le hachage et les octets de contrôle mis en cache sans avoir à examiner les valeurs elles-mêmes, ce qui réduit les coûts de redimensionnement.

Une simplification importante de notre implémentation est que les entrées ne sont jamais supprimées. Cela élimine le besoin de marqueurs (pour identifier les emplacements précédemment occupés) et permet aux emplacements vides de rester véritablement vides, ce qui améliore encore le comportement de sondage et maintient l'efficacité des analyses d'octets de contrôle.

Le résultat est une conception qui s'intègre naturellement dans le modèle d'exécution d'Elasticsearch tout en préservant les caractéristiques de performance qui rendent les tables suisses attrayantes.

Quelles sont ses performances ?

Pour les petites cardinalités, les tables suisses offrent des performances globalement équivalentes à celles de l'implémentation existante. Ce résultat est normal : lorsque les tables sont petites, les effets de cache sont moins importants et il y a peu de détections à optimiser.

À mesure que la cardinalité augmente, la situation change rapidement.

La carte thermique ci-dessus montre les facteurs d'amélioration du temps de traitement pour différentes tailles de clés (8, 32, 64 et 128 octets) pour des cardinalités allant de 1 000 à 10 000 000 de groupes. À mesure que la cardinalité augmente, le facteur d'amélioration s'accroît régulièrement, jusqu'à 2 à 3 fois pour les distributions uniformes.

Cette tendance correspond exactement aux prévisions de conception. Une cardinalité plus élevée entraîne des chaînes de détection plus longues dans les tables de hachage traditionnelles, tandis que le mode de sondage de type suisse continue de résoudre la plupart des recherches dans des blocs d'octets de contrôle compatibles SIMD.

Le comportement du cache raconte l'histoire

Pour mieux comprendre les gains de vitesse, nous avons exécuté le même JMH benchmarks sous Linux perf et capturé les statistiques du cache et du TLB.

Comparée à l'implémentation originale, la version suisse effectue environ 60 % d'accès au cache en moins. Les chargements du cache de dernier niveau sont 4 fois moins nombreux, et les défauts de chargement du cache LLC 6 fois moins. Étant donné que ces défauts se traduisent souvent directement par des accès à la mémoire principale, cette réduction explique à elle seule une grande partie de l'amélioration globale des performances.

Plus on se rapproche du processeur, moins on observe d'échecs de cache de données L1 et près de 6 fois moins d'échecs de TLB de données, ce qui indique une localité spatiale plus étroite et des schémas d'accès à la mémoire plus prévisibles.

C'est l'avantage concret des octets de contrôle compatibles SIMD. Au lieu de charger sans cesse des clés et des valeurs depuis des emplacements mémoire dispersés, la plupart des requêtes sont résolues par l'analyse d'une structure compacte résidant dans le cache. Moins de mémoire utilisée signifie moins d'échecs de lecture, et moins d'échecs de lecture signifient des requêtes plus rapides.

Conclusion

En adoptant une conception de table de hachage de style suisse et en misant fortement sur le sondage compatible SIMD, nous avons obtenu des gains de vitesse de 2 à 3 fois pour les charges de travail statistiques ES|QL à cardinalité élevée, ainsi que des performances plus stables et prévisibles.

Ce travail met en lumière comment les structures de données modernes optimisées pour le processeur peuvent générer des gains substantiels, même pour des problèmes complexes comme les tables de hachage. Il reste encore beaucoup à explorer, notamment en matière de spécialisation des types primitifs et d'utilisation dans d'autres opérations à forte cardinalité, telles que les jointures. Ces pistes s'inscrivent dans le cadre d'un effort plus vaste et continu de modernisation du fonctionnement interne d'Elasticsearch.

Si vous êtes intéressé par les détails ou souhaitez suivre le travail, consultez cette pull request et la meta issue qui suit les progrès sur Github.

Bon hachage !

Nous avons récemment contribué au projet open source Google MCP Toolbox for Databases en ajoutant la prise en charge d'Elasticsearch en tant que base de données.

Grâce à cette nouvelle fonctionnalité, vous pouvez désormais utiliser Google MCP Toolbox pour vous connecter à Elasticsearch et "dialoguer" directement avec vos données.

Elasticsearch

Nous avons besoin d'une instance Elasticsearch en cours d'exécution. Vous pouvez activer un essai gratuit sur Elastic Cloud ou l'installer localement via le script start-local :

Cela installera Elasticsearch et Kibana sur votre ordinateur et générera une clé API à utiliser pour configurer Google MCP Toolbox.

La clé API sera affichée comme sortie de la commande précédente et stockée dans un fichier .env dans le dossier elastic-start-local.

Installer l'ensemble de données d'exemple

Après l'installation, connectez-vous à Kibana en utilisant le nom d'utilisateur elastic et le mot de passe généré par le script "start-local" (stocké dans un fichier .env).

Vous pouvez installer l'ensemble de données eCommerce orders disponible dans Kibana. Il comprend un seul index nommé kibana_sample_data_ecommerce contenant des informations sur 4 675 commandes provenant d'un site web. Pour chaque commande, nous disposons des informations suivantes :

• Informations client (nom, identifiant, date de naissance, e-mail, etc.)

• Date de la commande

• ID de la commande

• Produits (liste de tous les produits avec prix, quantité, ID, catégorie, réduction, etc.)

• SKU

• Prix total (hors taxes, taxes incluses)

• Quantité totale

• Informations géographiques (ville, pays, continent, localisation, région)

Pour installer les données d'exemple, ouvrez la page Intégrations dans Kibana (recherchez "Integration" dans la barre de recherche supérieure), puis installez l'ensemble de données "Sample Data". Pour plus de détails, consultez la documentation ici : https://www.elastic.co/docs/explore-analyze/#gs-get-data-into-kibana.

Cet article a pour but de montrer combien il est facile de configurer Google MCP Toolbox pour se connecter à Elasticsearch et interagir avec l'index kibana_sample_data_ecommerce en utilisant le langage naturel.

Google MCP Toolbox

Google MCP Toolbox est un serveur MCP open source conçu pour faciliter l'interaction sécurisée et efficace des applications et des agents IA avec les bases de données. Auparavant appelé "GenAI Toolbox for Databases", le projet a été renommé après l'adoption d'une compatibilité totale avec le protocole MCP (Model Context Protocol). Son objectif est de supprimer les tâches complexes traditionnellement requises lors de la connexion d'agents à des bases de données en gérant en arrière-plan les pools de connexion, l'authentification, l'observabilité et d'autres aspects opérationnels.

Essentiellement, la boîte à outils permet aux développeurs de définir des outils réutilisables de haut niveau qui encapsulent les interactions avec la base de données. Ces outils peuvent ensuite être invoqués par n'importe quel client compatible MCP, tel qu'un agent IA, sans que le client n'ait à implémenter des requêtes SQL de bas niveau ni à gérer des connexions de base de données. Cette approche réduit considérablement la quantité de code répétitif nécessaire à la création d'agents compatibles avec les bases de données, permettant ainsi d'intégrer des opérations de données avancées en seulement quelques lignes de logique applicative. Une fois qu'un outil est défini, il peut être partagé entre plusieurs agents, frameworks, ou langages (Figure 1).

L'un des principaux avantages de la boîte à outils est le modèle de sécurité intégré. Les flux d'authentification tels que OAuth2 et OIDC sont pris en charge de manière native, ce qui permet aux développeurs d'éviter de manipuler ou de stocker des informations sensibles d'identification de base de données dans les agents. La plateforme fournit également des fonctionnalités d'observabilité via OpenTelemetry, y compris les métriques et le traçage, ce qui est essentiel pour le débogage, la surveillance et les déploiements en production. De manière générale, MCP Toolbox sert d'interface unifiée, sécurisée et extensible pour interagir avec vos données depuis n'importe quel système compatible MCP.

Comment installer MCP Toolbox

Vous pouvez installer le serveur MCP Toolbox sur Linux en utilisant la commande suivante :

Si vous souhaitez l'installer sur macOS ou Windows, vous pouvez suivre les instructions détaillées ici.

Configurer Toolbox pour Elasticsearch

Pour configurer MCP Toolbox pour Elasticsearch, nous devons créer un fichier tools.yaml comme suit :

Vous devez remplacer la valeur <insert-here-api-key> par une clé API Elasticsearch valide. Si vous exécutez Elasticsearch localement avec la commande "start-local", vous trouverez la clé API dans le fichier .env généré par start-local, sous la variable ES_LOCAL_API_KEY. Si vous utilisez Elastic Cloud, vous pouvez générer une clé API en suivant la procédure décrite ici.

Les outils précédents contiennent la requête ES|QL suivante pour Elasticsearch :

Si vous ne connaissez pas ES|QL, il s'agit d'un langage de requête développé par Elastic, similaire à SQL, qui peut être utilisé pour effectuer des recherches sur un ou plusieurs indices. Pour en savoir plus sur ES|QL, consultez la documentation officielle ici.

La requête ci-dessus recherche toutes les commandes stockées dans l'index kibana_sample_data_ecommerce qui contiennent le nom du client spécifié, en utilisant le paramètre ?name (le point d'interrogation indique un paramètre).

Le nom du client est défini dans la configuration YAML précédente en utilisant le type chaîne et la description "The customer name" (nom du client).

Cet outil peut être utilisé pour répondre à des questions sur les commandes d'un client, par exemple : Combien de commandes le client Foo a-t-il passées en octobre 2025 ?

Les descriptions des outils et de leurs paramètres sont essentielles pour extraire les informations pertinentes de la requête en langage naturel de l'utilisateur. Cette extraction est réalisée à l'aide de la capacité d'appel de fonctions d'un grand modèle de langage (LLM). En pratique, un LLM peut déterminer quelle fonction (outil) doit être exécutée pour obtenir les informations nécessaires, ainsi que les paramètres appropriés pour cette fonction.

Pour plus d'informations sur les appels de fonctions, nous vous invitons à lire l'article OpenAI function calling with Elasticsearch (en anglais) par Ashish Tiwari.

Exécuter le serveur Toolbox

Vous pouvez exécuter le serveur MCP Toolbox à l'aide du fichier "tools.yaml" précédent avec la commande suivante :

Le paramètre –ui exécute une application web à l'adresse http://127.0.0.1:5000/ui (Figure 2).

Sélectionnez Tools (Outils) > customer-orders et insérez un nom de client dans le paramètre name (par ex. Gwen Sanders), puis cliquez sur le bouton Run Tool (Exécuter l'outil). Une réponse JSON devrait s'afficher comme illustré dans la figure 3.

La configuration est terminée et MCP Toolbox peut exécuter l'outil customer-orders pour communiquer avec Elasticsearch, en lançant la requête ES|QL.

Utiliser MCP Toolbox avec Gemini CLI

Nous pouvons utiliser n'importe quel client MCP pour communiquer avec MCP Toolbox for Databases. Par exemple, nous pouvons choisir Gemini CLI, un outil en ligne de commande permettant d'utiliser Gemini. Si vous souhaitez installer Gemini CLI, suivez les instructions indiquées ici.

Gemini CLI propose une extension préconfigurée pour MCP Toolbox, disponible sur gemini-cli-extensions/mcp-toolbox. Vous pouvez installer cette extension en exécutant la commande suivante :

Après l'installation, vous devez accéder au répertoire dans lequel vous avez stocké le fichier de configuration "tools.yaml" pour MCP Toolbox et exécuter Gemini CLI comme suit (cette étape est nécessaire pour que Gemini CLI soit automatiquement configuré avec MCP Toolbox) :

Un message de sortie devrait s'afficher comme illustré dans la figure 4.

Vous pouvez vérifier si la boîte à outils MCP est connectée en utilisant la commande suivante :

Vous devriez voir s'afficher mcp_toolbox avec les outils customer-orders répertoriés (Figure 5).

Si MCP Toolbox est connecté à Gemini CLI, nous pouvons maintenant poser quelques questions, telles que : "Indiquez-moi les commandes pour la cliente Gwen Sanders". Gemini CLI demande alors l'autorisation d'exécuter l'outil "customer-orders" depuis le serveur mcp_toolbox (voir Figure 6).

Après confirmation, Gemini CLI exécute la requête dans MCP Toolbox, reçoit une réponse JSON et l'utilise pour mettre en forme la réponse (Figure 7).

La réponse de Gemini CLI indique que Gwen Sanders a passé une seule commande de 2 produits, pour un prix total de 132 EUR.

SDK MCP Toolbox

Google MCP Toolbox propose également un SDK pour accéder à toutes les fonctionnalités depuis un programme écrit en Go, Python et Javascript.

Par exemple, le SDK Python est disponible sur Github à la page suivante : https://github.com/googleapis/mcp-toolbox-sdk-python.

Nous devons créer un agent simple pour nous connecter à MCP Toolbox. Nous devons installer les packages suivants :

Et créer un nouveau projet d'agent à l'aide la commande suivante :

Cela créera un nouveau répertoire nommé my_agent contenant un fichier agent.py.

Mettez à jour le fichier my_agent/agent.py avec le contenu suivant pour vous connecter à Toolbox :

Créez un fichier .env avec votre clé API Google :

Enfin, nous pouvons lancer l'exécution de l'agent et observer les résultats. Pour ce faire, exécutez la commande suivante :

Ou, vous pouvez le servir via une interface web :

Dans les deux cas, vous pouvez interagir avec MCP Toolbox à l'aide d'une interface de questions-réponses. Par exemple, vous pouvez poser la question précédente : Indiquez-moi les commandes de la cliente Gwen Sanders.

Pour plus d'informations sur les différents SDK, consultez cette page de documentation.

Conclusion

Dans cet article, nous avons démontré l'intégration d'Elasticsearch pour Google MCP Toolbox for Databases. À l'aide d'un simple fichier de configuration YAML, nous pouvons définir un ensemble d'outils qui traduisent les questions en langage naturel en requêtes Elasticsearch en utilisant le langage ES|QL.

Nous avons montré comment interagir avec l'ensemble de données "kibana_sample_data_ecommerce", qui contient des commandes provenant d'un site web. Avec ce fichier de configuration, nous pouvons simplement lancer l'exécution du serveur MCP Toolbox et nous y connecter depuis n'importe quel client MCP.

Enfin, nous avons démontré comment utiliser Gemini CLI en tant que client pour nous connecter à MCP Toolbox for Databases et interroger les données e-commerce stockées dans Elasticsearch. Nous avons exécuté une requête en langage naturel pour récupérer des informations sur les commandes d'un client spécifique identifié par son nom.

À mesure que l'écosystème MCP se développe, ce modèle – des définitions d'outils légères soutenues par une infrastructure sécurisée et prête pour la production – crée de nouvelles possibilités pour construire des agents de plus en plus performants et sensibles aux données avec un minimum d'efforts. Qu'il s'agisse d'expérimenter localement les ensembles de données Elastic ou d'intégrer des fonctionnalités de recherche dans une application plus vaste, MCP Toolbox fournit une base fiable et extensible pour interagir avec vos données Elasticsearch en langage naturel.

Pour en savoir plus sur le développement d'applications d'IA agentique, consultez l'article Construire des workflows d'IA agentique avec Elasticsearch par Anish Mathur et Dana Juratoni.

Pour plus d'informations sur Google MCP Toolbox, consultez la page vhttps://googleapis.github.io/genai-toolbox/getting-started/introduction/.

Découvrez les fonctionnalités d’Elasticsearch 9.2 qui révolutionneront votre analyse de données avec ES|QL.

Révolutionner la corrélation des données : un Lookup Join plus intelligent, plus rapide et plus flexible

La commande LOOKUP JOIN dans ES|QL a subi une transformation importante dans Elasticsearch 9.2, elle devient considérablement plus efficace et polyvalente. LOOKUP JOIN fusionne les données issues de la table de résultats de votre requête ES|QL avec les enregistrements concordants d’un index de mode de recherche que vous avez désigné. Cela permet d’ajouter des champs de l’index de recherche en tant que nouvelles colonnes à votre table de résultats, en faisant correspondre les valeurs du champ de jointure. Auparavant, la jointure des données était limitée à un seul champ et à une simple égalité. Plus maintenant ! Ces améliorations vous permettent de gérer facilement des scénarios complexes de corrélation de données.

Les principales améliorations de Lookup Join incluent :

• Jointures multi-champs : Effectuez facilement des jointures sur plusieurs champs. Par exemple, pour joindre application_logs à service_registry sur service_name, environment et version:

• Utilisation d’expressions pour des prédicats de jointure complexes (aperçu technologique) :

Vous n'êtes plus limité à la simple égalité. LOOKUP JOIN permet désormais de spécifier plusieurs critères de corrélation et d’incorporer une gamme d’opérateurs binaires, notamment ==, !=, <, >, <=et >=. Cela signifie que vous pouvez créer des conditions de jointure très nuancées, vous permettant de poser des questions beaucoup plus sophistiquées à vos données.

Exemple 1 : Recherche des métriques d’application avec un seuil de SLA par service

Exemple 2 : Cette requête calcule le montant dû, en se basant sur les politiques tarifaires régionales qui évoluent au fil du temps. Cela relie trois ensembles de données basés sur des périodes complexes et des conditions d’égalité pour calculer un due_amountfinal. La deuxième jonction de recherche utilise le champ measurement_date de l’indice meter_readings et le champ region_id de l’indice customers pour joindre l’indice pricing_policies et trouver la politique de tarification appropriée pour le region et le measurement_date particuliers.

• Des gains de performances considérables pour les jointures filtrées :

Nous avons amélioré les performances des « jointures en expansion » qui sont filtrées à l'aide de conditions de table de recherche. Les jointures en expansion produisent plusieurs correspondances par ligne d'entrée, ce qui peut créer de grands ensembles de résultats intermédiaires. Cela s’aggrave lorsqu’un filtre ultérieur écarte un grand nombre de ces lignes. Avec la version 9.2, nous optimisons ces jointures en excluant les lignes superflues lorsqu’un filtre est appliqué aux données de recherche, ce qui permet d’éviter de traiter des lignes vouées à être éliminées. Dans certains scénarios, ces jointures peuvent être jusqu'à 1000 fois plus rapides !

Cette optimisation est déterminante pour gérer les « jointures à résultats multiples », là où une consultation initiale peut produire de nombreux résultats potentiels. La transmission intelligente des filtres garantit que seules les données pertinentes sont traitées, réduisant ainsi fortement le temps d’exécution des requêtes pour une analyse en temps réel sur des ensembles de données gigantesques. Cela signifie que vous obtenez vos informations beaucoup plus rapidement, même avec des opérations de jointure très volumineuses ou complexes.

Recherchez la compatibilité de Lookup Join avec la rechercher inter-clusters (CCS) :

Lorsque Lookup Join est devenu disponible en version générale dans les versions 8.19 et 9.1, il manquait le support de la recherche inter-clusters (CCS). LOOKUP JOIN s’intègre parfaitement à CCS en 9.2, ce qui est un atout majeur pour les entreprises gérant plusieurs clusters. Placez simplement votre index de recherche sur tous les clusters distants où vous souhaitez effectuer une jointure, et ES|QL utilisera automatiquement ces index de recherche distants pour la jointure avec vos données distantes. Cela simplifie l'analyse distribuée des données et garantit un enrichissement constant sur l'ensemble de votre déploiement Elasticsearch.

Ces améliorations vous permettent de corréler divers ensembles de données avec une précision, une rapidité et une facilité sans précédent, afin de découvrir des informations plus approfondies et plus exploitables sans solutions complexes ni étapes de prétraitement.

Enrichissez vos données en toute simplicité : Kibana Discover UX pour les index de recherche

L’enrichissement des données doit rester simple, et non constituer un problème. Une fantastique nouvelle expérience utilisateur a été ajoutée à Discover (Kibana) pour créer et gérer les index de recherche.

Workflow intuitif : la fonction de saisie semi-automatique complète de Discover vous guidera tout au long du processus, en suggérant des index de recherche et des champs de jointure dans l’éditeur ES|QL, ce qui facilite grandement la connexion de vos données téléchargées avec les index existants. Tapez le nom d'un index de recherche qui n'existe pas et accédez directement à l'éditeur de recherche en un seul clic pour créer l'index. Tapez le nom d'un index de recherche existant, et nous vous suggérerons une option pour le modifier :

Gestion en ligne (CRUD) : maintenez vos ensembles de données de référence à jour grâce à des fonctionnalités d'édition en ligne (création, lecture, mise à jour, suppression) directement dans Discover.

Téléchargement de fichiers sans effort : vous pouvez désormais télécharger directement des fichiers, tels que des CSV, dans Discover et les utiliser instantanément dans vos LOOKUP JOIN. Plus besoin de changer constamment de contexte en naviguant entre les différentes zones de Kibana !

Cette fonctionnalité démocratise l’enrichissement des données, que vous mappiez des ID utilisateur à des noms, ajoutiez des métadonnées d’entreprise ou joigniez des fichiers de référence statiques. La puissance des jointures est désormais à la portée de tous, de manière rapide, simple et au même endroit.

Préservez votre contexte : présentation d'INLINE STATS (aperçu technique)

L'agrégation des données est cruciale, mais parfois vous avez besoin de voir les agrégations à côté de vos données originales. Nous sommes ravis de présenter les STATS EN LIGNE en tant que fonctionnalité de la Tech Preview.

Contrairement à la commande STATS, qui remplace vos champs d'entrée par une sortie agrégée, INLINE STATS préserve tous vos champs d'entrée d'origine et ajoute simplement les nouveaux champs agrégés. Cela vous permet d’effectuer des opérations supplémentaires sur vos champs d’entrée originaux après l’agrégation, offrant ainsi un workflow d’analyse plus continu et plus flexible.

Par exemple, pour calculer la distance moyenne des vols tout en conservant les lignes de vol individuelles :

Dans cette requête, avgDist est ajouté à chaque ligne avec le Destcorrespondant (ination) par lequel nous avons regroupé, puis, comme nous avons toujours les colonnes d’information de vol, nous pouvons filtrer les résultats vers les vols ayant une distance supérieure à la moyenne.

Prise en charge des séries temporelles dans ES|QL (aperçu technique)

Elasticsearch utilise des flux de données temporelles pour stocker des métriques. Nous ajoutons la prise en charge des agrégations de séries temporelles dans ES|QL, via la commande source TS . Cette fonctionnalité est disponible dans Elastic Cloud serverless et en version 9.2 (niveau Basic) en préversion technique.

L’analyse de séries temporelles est principalement basée sur des requêtes d’agrégation qui résument les valeurs de métriques sur des plages de temps, segmentées par une ou plusieurs dimensions de filtrage. La majorité des requêtes d’agrégation nécessitent un traitement en deux étapes, avec (a) une fonction d’agrégation interne qui résume les valeurs de chaque série temporelle, et (b) une fonction d’agrégation externe qui consolide les résultats de (a) au travers des séries temporelles.

La commande source TS, combinée à STATS, offre un moyen concis et efficace d'exprimer de telles requêtes sur des séries temporelles. Plus concrètement, considérons l’exemple suivant pour calculer le taux total de requêtes par hôte et par heure :

Dans ce cas, la fonction d'agrégation de séries chronologiques RATE est d'abord évaluée par série chronologique et par heure. Les agrégats partiels produits sont ensuite combinés à l'aide de SUM pour calculer les valeurs agrégées finales par hôte et par heure.

Vous pouvez consulter la liste des fonctions d'agrégation de séries temporelles disponibles ici. La fonction counter_rate est désormais prise en charge, sans doute la fonction d’agrégation la plus importante pour le traitement des compteurs.

La commande source TS est conçue pour être combinée avec STATS, avec une exécution adaptée pour prendre en charge efficacement les agrégations de séries temporelles. Par exemple, les données sont triées avant d’entrer dans le STATS. Les commandes de traitement susceptibles d’enrichir ou de modifier les données temporelles ou leur ordre, telles que FORK ou INLINE STATS, ne sont actuellement pas autorisées entre TS et STATS. Cette restriction pourrait être levée à l’avenir.

La sortie tabulaire de STATS peut être traitée avec n'importe quelle commande applicable. Par exemple, la requête suivante calcule le rapport entre la valeur moyenne de cpu_usage hébergé par hôte et par heure et la valeur maximale par hôte :

Les données de séries temporelles sont enregistrées sur notre moteur de stockage sous-jacent à colonnes, optimisé par les doc values de Lucene. La commande TS ajoute une exécution vectorisée de requêtes via le moteur de calcul ES|QL. Les performances des requêtes sont souvent améliorées de plus d'un ordre de grandeur, par rapport aux requêtes DSL équivalentes, et sont comparables aux systèmes établis spécifiques aux métriques. Une analyse détaillée de l’architecture et des performances sera bientôt disponible. Ne manquez pas cette publication.

Élargir votre boîte à outils : nouvelles fonctions ES|QL

Pour améliorer davantage l’utilité et la polyvalence d’ES|QL, nous avons ajouté une suite de nouvelles fonctions:

Manipulation de chaînes : CONTAINS, MV_CONTAINS, URL_ENCODE, URL_ENCODE_COMPONENT, URL_DECODE pour un traitement plus robuste du texte et des URL.

Séries temporelles et géospatial : TBUCKET pour des buckets temporels flexibles, TO_DENSE_VECTOR pour les opérations vectorielles, et un ensemble complet de fonctions géospatiales comme ST_GEOHASH, ST_GEOTILE, ST_GEOHEX, TO_GEOHASH, TO_GEOTILE, TO_GEOHEX pour une analyse avancée basée sur la localisation.

Formatage de la date : DAY_NAME, MONTH_NAME pour une représentation plus lisible des dates.

Ces fonctions vous offrent un ensemble d'outils plus riche pour manipuler et analyser vos données directement dans ES|QL.

Sous le capot : plus de performance et d'efficacité

Au-delà des fonctionnalités mises en avant, Elasticsearch 9.2 inclut de nombreuses optimisations de performances pour ES|QL. Nous avons accéléré RLIKE (LIST) avec pushdown dans les cas où la fonction remplace plusieurs requêtes RLIKE similaires. Avec RLIKE (LIST), nous pouvons fusionner ces requêtes en un seul automate et appliquer un automate au lieu de plusieurs. Nous avons également accéléré le chargement des champs de mots clés grâce à des tris d'index et des optimisations générales des requêtes. Ces améliorations garantissent que vos requêtes ES|QL s'exécutent plus efficacement que jamais.

Lancez-vous dès aujourd'hui !

La version 9.2 d’Elasticsearch représente une avancée majeure pour ES|QL, conférant une puissance et une flexibilité inédites à vos workflows d’analyse de données. Nous vous encourageons à explorer ces nouvelles fonctionnalités et à constater la différence qu’elles apportent.

Pour une liste complète de tous les changements et améliorations dans Elasticsearch 9.2, veuillez consulter les notes de publication officielles. Bonne recherche !

Dans ce blog, nous allons explorer l'expérience du développeur de l'éditeur ES|QL dans Elasticsearch 9.1 en le comparant à PPL dans l'analyseur d'événements (PPL en abrégé) dans OpenSearch 3.2.

Les différences apparaissent rapidement : l'éditeur ES|QL offre une autocomplétion intelligente, une aide contextuelle, des requêtes recommandées et une prise en charge des requêtes entre clusters qui permettent aux utilisateurs débutants, mais aussi aux utilisateurs experts, d'être plus autonomes. La conception réfléchie de la rédaction ES|QL est également visible dans l'inspection intégrée des requêtes et l'intégration holistique par le biais des flux de travail Kibana, par exemple, avec les requêtes récentes.

En revanche, PPL n'offre pas de support comparable pour l'autocomplétion, l'orientation contextuelle et les requêtes distribuées, ce qui entraîne une courbe d'apprentissage plus raide et davantage d'essais et d'erreurs.

Faciliter l'apprentissage et l'utilisation d'ES|QL

Se lancer dans l'utilisation d'un nouveau langage d'interrogation peut souvent sembler insurmontable. L'éditeur ES|QL, intégré directement à Kibana Discover, est conçu pour faciliter ce processus en prenant en charge non seulement la création et le débogage des requêtes, mais aussi en accélérant la vitesse à laquelle vous vous familiarisez et vous vous sentez à l'aise avec le langage. Comme l'éditeur aide à réduire les frictions dans les tâches quotidiennes, vous pouvez vous concentrer sur la recherche de solutions plutôt que sur la syntaxe et les essais-erreurs. Pour en savoir plus sur ces principes et sur la manière dont nous les avons intégrés dans l'éditeur , cliquez ici.

Cette expérience d'éditeur n'est pas limitée à Discover ; il s'agit d'un module de code réutilisable que nous travaillons à intégrer dans d'autres parties de Kibana, telles que les tableaux de bord, les alertes Kibana et les cartes Kibana.

Autocomplétion intelligente : accélérer la création de requêtes

L'autocomplétion de l'éditeur ES|QL est complète, offrant des suggestions de fonctions compatibles, d'arguments, de littéraux et même de fonctions imbriquées, une capacité qui fait notablement défaut dans PPL. En fait, il a été reconstruit de fond en comble, comme indiqué ici.

La validation s'exécute au fur et à mesure que l'utilisateur tape, comme indiqué ici, et suggère des champs tout en notifiant l'utilisateur en cas d'erreur. Cela réduit la charge mentale des utilisateurs et permet d'éviter les erreurs dès le début du processus de création de la requête.

Exemple : Des champs et des fonctions compatibles sont proposés dans cette imbrication :

Ce que la PPL ne soutient pas :

Même si l'autocomplétion intelligente vous guide à travers les fonctions compatibles, les arguments et les fonctions imbriquées, il se peut que vous souhaitiez mieux comprendre les options disponibles. C'est précisément là que l'aide contextuelle de l'éditeur ES|QL devient inestimable, offrant une assistance immédiate, au sein de l'éditeur, pour clarifier et améliorer le développement de votre requête.

Une aide contextuelle au bout des doigts

Il suffit d'un clic Ctrl-Espace pour obtenir des informations supplémentaires sur une commande générée par la saisie semi-automatique. Un panneau apparaît immédiatement avec des détails sur la fonction, l'argument ou le champ en question. Cette interaction légère permet aux développeurs de rester dans le flux, en leur fournissant des conseils juste à temps sans les obliger à quitter l'éditeur ou à rechercher de la documentation externe. Cela permet de réduire le temps perdu en recherches syntaxiques et d'éviter les erreurs courantes avant qu'elles ne se produisent.

Voici ce que cela donne en pratique :

PPL ne dispose pas de ce niveau d'orientation intégrée, ce qui oblige les utilisateurs à s'appuyer sur des documents externes ou à procéder par tâtonnements. Cette absence n'est pas seulement une caractéristique manquante ; elle met en évidence une disparité plus large dans la philosophie de conception. ES|QL donne la priorité à une expérience réfléchie et contextuelle qui s'adapte aux données et au flux de travail de l'utilisateur. Cette différence s'accentue au fur et à mesure que les requêtes deviennent plus complexes, ce qui fait de l'Éditeur ES|QL un environnement plus efficace et plus fiable, tant pour l'apprentissage que pour la production.

Requêtes recommandées qui tiennent compte du contexte des données

L'éditeur ES|QL propose des requêtes recommandées qui sont automatiquement adaptées aux données avec lesquelles vous travaillez, telles que les journaux. Au lieu de présenter un éditeur vierge, il fait apparaître les points de départ les plus pertinents pour les cas d'utilisation courants. La sélection d'une requête recommandée génère une requête canonique qui est immédiatement utilisable et peut être affinée si nécessaire. Cette approche accélère le développement des requêtes, en particulier pour les nouveaux utilisateurs qui ne connaissent pas encore toute la syntaxe.

Voici un exemple où un utilisateur sélectionne la requête "Détecter le point de changement" :

Comparez cela à l'expérience PPL :

En revanche, PPL n'offre qu'une autocomplétion de base, ce qui vous laisse le soin d'élaborer des requêtes sans contexte ni structure. Ce manque d'orientation peut conduire à la frustration et au tâtonnement. Grâce aux requêtes recommandées de l'éditeur ES|QL qui tiennent compte des données, vous pouvez éviter de partir de zéro ou de mémoriser la syntaxe pour les tâches de routine. L'éditeur réduit la charge cognitive, aide à prévenir les erreurs et vous permet de vous concentrer sur la résolution de problèmes et sur des objectifs plus larges, tels que l'exécution de recherches entre clusters, plutôt que de vous débattre avec la construction d'une requête.

Interrogation intuitive de l'ensemble des clusters

L'autocomplétion de l'éditeur ES|QL reste supérieure, même lorsque l'on travaille avec plusieurs clusters distants avec CCS. Voici pourquoi :

L'éditeur ES|QL offre une autocomplétion transparente, même à travers les clusters

L'autocomplétion dans l'éditeur ES|QL prend en charge non seulement les noms des clusters, mais aussi les index locaux et distants. Comme indiqué ici, cela fonctionne grâce à l'architecture d'un nœud coordinateur, qui aide à valider et à générer le plan d'interrogation à envoyer aux nœuds locaux, à exécuter l'interrogation et à agréger les résultats avant de les renvoyer à l'utilisateur. Sans saisir le nom complet du cluster distant, la saisie de " :" lance le processus d'autocomplétion pour l'index distant. Et vous n'êtes pas limité au préfixe.

Il est ainsi facile de découvrir et d'interroger des ensembles de données distribués sans avoir à mémoriser des conventions de dénomination ou à changer de contexte.

Voici un exemple où l'utilisateur tape simplement "clu:g" pour localiser un index distant :

En revanche, la PPL ne fournit qu'une complétion de base pour les index locaux, avec des suggestions limitées aux correspondances de préfixes. Les clusters distants doivent être saisis manuellement, ce qui augmente la probabilité d'erreurs et ralentit la création de requêtes.

PPL ne fournit une complétion que pour les index locaux et les suggestions sont limitées au préfixe :

ES|QL va plus loin en autorisant les exclusions directement à l'aide d'un signe négatif, ce qui vous permet de contrôler finement les grappes qui participent à votre exploration. Cette fonction est particulièrement utile lorsque vous travaillez avec des environnements hybrides, où vous pouvez vouloir inclure ou omettre des ensembles de données spécifiques lors d'investigations entre clusters.

Ces améliorations reflètent l'accent mis par Elasticsearch sur la réduction des frictions dans la recherche cross-cluster. En facilitant la construction et la gestion des requêtes distribuées, ES|QL Editor permet aux analystes et aux développeurs de se concentrer sur les idées plutôt que sur la syntaxe, alors que PPL laisse une plus grande part de ce fardeau à l'utilisateur. De même que l'éditeur ES|QL simplifie la création de requêtes inter-clusters, il fournit également des outils permettant d'inspecter l'exécution de ces requêtes, garantissant ainsi la transparence et le contrôle des performances sur plusieurs clusters.

Utilisation de l'outil Inspect pour analyser les détails de la recherche transversale

L'outil Inspect, accessible à partir de l'éditeur ES|QL, est conçu pour fournir des métadonnées contenant des informations explicites sur l'exécution de la requête dans tous les clusters. Cette fonctionnalité est activée dans Kibana Discover et est accessible directement dans l'inspecteur de requête, ce qui vous permet d'analyser la progression et les détails de la recherche, ce qui est particulièrement crucial pour la recherche cross-cluster (CCS). Cette fonctionnalité vous permet de suivre l'évolution de la recherche et de comprendre comment les requêtes se déroulent dans des ensembles de données distribués.

Cette visibilité détaillée de l'exécution des requêtes, en particulier pour les recherches distribuées complexes, vous permet de garantir des performances et un dépannage optimaux.

Au-delà de la compréhension des mécanismes des requêtes individuelles, ES|QL Editor améliore encore le parcours de l'utilisateur en intégrant des fonctionnalités essentielles dans l'ensemble de la plateforme Kibana, favorisant ainsi un flux de travail transparent et ininterrompu.

Expérience des requêtes unifiées avec ES|QL et Kibana

Le changement de contexte est l'une des sources de friction les plus courantes dans l'analyse pilotée par les requêtes. Vous devez souvent vous rappeler des requêtes que vous avez déjà écrites. Chaque interruption déconcentre et ralentit les investigations. L'éditeur ES|QL y remédie en intégrant l'historique des requêtes dans Kibana.

Requêtes récentes

La fonction Requêtes récentes de l'éditeur ES|QL vous aide à rester dans le flux en rendant les travaux antérieurs instantanément accessibles. Dans l'éditeur ES|QL de Discover, vous pouvez afficher, réexécuter et enregistrer vos 20 dernières requêtes, de sorte que les requêtes complexes ou fréquemment utilisées ne sont qu'à un clic de souris. Ces requêtes enregistrées se retrouvent également dans Kibana et s'intègrent aux tableaux de bord, aux visualisations, aux alertes et aux cartes, de sorte que vous n'avez pas besoin de quitter votre écran actuel ou de retaper des commandes à partir de zéro. Cela permet de réduire le travail répétitif, d'accélérer les enquêtes et de minimiser le risque d'erreurs.

Par exemple, un utilisateur peut utiliser les requêtes récentes dans l'éditeur ES|QL dans Discover (et les mettre en vedette) :

Les requêtes récentes sont intégrées dans le tableau de bord :

PPL n'offre pas de possibilité comparable, ce qui oblige les utilisateurs à recourir au copier-coller manuel ou à des notes externes pour réutiliser les requêtes. La différence est plus qu'une question de commodité ; elle reflète la stratégie d'Elastic qui consiste à faire d'ES|QL un langage véritablement intégré à l'écosystème Kibana. Avec des fonctionnalités telles que les requêtes récentes, l'éditeur ES|QL ne se contente pas de rationaliser les flux de travail quotidiens, il pose également les bases de fonctionnalités plus avancées, actuellement en phase de prévisualisation technique, ce qui garantit une évolution constante de l'expérience.

Conclusion

ES|QL est plus qu'une syntaxe ; elle reflète la stratégie d'Elastic visant à améliorer la façon dont les utilisateurs recherchent, explorent et analysent les données. Grâce à une autocomplétion intelligente, à des requêtes recommandées en fonction du contexte, à des conseils intégrés à l'éditeur et à des outils comme Inspect, l'éditeur ES|QL accélère l'apprentissage, réduit les erreurs et simplifie les flux de travail complexes tels que l'analyse croisée des clusters. Intégré à Kibana, il relie de manière transparente les requêtes aux tableaux de bord, aux alertes et aux visualisations pour un flux de travail ininterrompu.

En résumé, ES|QL n'est pas simplement un autre langage pipé ; il s'agit d'un moteur de requêtes bien pensé associé à une interface utilisateur intuitive qui redéfinit fondamentalement la façon dont vous interagissez avec vos données, en offrant une expérience intégrée, intelligente et en constante évolution qui contraste fortement avec la nature souvent séquentielle et moins guidée d'OpenSearch PPL.

Prochaines étapes

Ce blog ne fait qu'effleurer la surface d'ES|QL. Les prochains articles approfondiront les comparaisons avec OpenSearch PPL et exploreront les fonctionnalités géospatiales, de visualisation et les futures fonctionnalités de l'éditeur telles que les contrôles (déjà disponibles dans les tableaux de bord), les onglets d'exploration multi-données, la recherche en arrière-plan, l'historique des requêtes plus riche et FUSE.

Essayez ES|QL dès aujourd'hui

Vous pouvez tester ES|QL dans des projets Serverless Elasticsearch entièrement gérés avec un essai gratuit. Il est également disponible dans les versions à partir de la 8.11, mais c'est dans les versions 8.19 et 9.1 qu'il est le plus utile.

Démarrez en quelques minutes sur votre environnement local à l'aide d'une simple commande :

ESQL :

Rubis :

Installation

La gemme peut être installée à partir de RubyGems avec :

Il peut également être ajouté au fichier Gemfile d'un projet :

Utilisation

Vous pouvez soit construire une requête complète en une seule fois, soit créer un objet de requête à l'aide d'une commande source telle que from ou row, puis enchaîner les méthodes ES|QL pour construire à partir de cet objet.

La gemme traduit le code en ES|QL dans la méthode to_s, de sorte qu'elle renvoie la requête ES|QL lorsqu'elle est imprimée ou transformée en chaîne :

Vous pouvez instancier un objet de requête et modifier son état initial en utilisant les équivalents ! de chaque fonction :

L'outil offre des moyens pratiques d'enchaîner des étapes supplémentaires à une fonction ES|QL, comme enrich et sort. Une fois que vous avez appelé enrich sur un objet Elastic::ESQL, vous pouvez enchaîner on et with:

Vous pouvez également enchaîner desc, asc, nulls_first et nulls_last à votre requête après avoir utilisé sort:

Elle prend également en charge les chaînes personnalisées, au cas où vous souhaiteriez écrire vous-même la requête ES|QL ou utiliser une fonctionnalité qui n'a pas encore été ajoutée à la bibliothèque. custom joindra les chaînes à la fin de la requête. Il les ajoutera au fur et à mesure qu'ils sont envoyés à la fonction, sans ajouter de caractères de liaison. Ils seront combinés au reste de la requête par un caractère d'espacement.

Vous pouvez également enchaîner les fonctions de custom:

Utilisation du générateur de requêtes ES|QL avec le client Ruby

Vous pouvez utiliser le constructeur de requêtes directement avec elasticsearch-ruby et l'API esql.query en envoyant l'objet de requête :

Vous pouvez également l'utiliser avec l'ES|QL Helper du client Elasticsearch Ruby, pour en savoir plus :

En tant qu'outil autonome

La gemme est conçue comme un outil autonome pour construire des requêtes ES|QL de manière idiomatique. Il n'a aucune dépendance d'exécution ; vous pouvez l'utiliser avec le client Ruby officiel d'Elasticsearch, ou seul.

La requête générée peut être utilisée avec l'API esql.query de toutes les façons dont une application interagit avec l'API Elasticsearch (Ruby ou non). Une fois qu'une requête est construite avec elastic-esql, la chaîne générée peut être envoyée à l'API en tant que paramètre query dans le corps de la requête.

J'ai déjà écrit sur l'utilisation d'Elasticsearch avec des outils Ruby populaires. Cette gemme peut être utilisée avec n'importe quel outil Ruby populaire pour interroger Elasticsearch avec ES|QL.

Conclusion

Cette bibliothèque est en cours de développement et l'API finale n'a pas encore été finalisée. Il s'agit actuellement d'un aperçu technique. Si vous avez des commentaires sur l'API actuelle ou sur son utilisation générale, n'hésitez pas à ouvrir un nouveau dossier. Veuillez vous référer au README pour en savoir plus sur Ruby ES|QL Query Builder.

Importation de données géospatiales à l'aide de Kibana

Les données que nous avons utilisées pour les exemples du blog précédent étaient basées sur les données que nous utilisons en interne pour les tests d'intégration. Pour vous faciliter la tâche, nous l'avons inclus ici sous la forme de quelques fichiers CSV qui peuvent être facilement importés à l'aide de Kibana. Les données sont un mélange d'aéroports, de villes et de limites de villes. Vous pouvez télécharger les données à partir de :

• aéroports.csv

  • Il s'agit d'une fusion de trois ensembles de données :

    • Aéroports (noms, emplacements et données connexes) de Natural Earth

    • Localisation des villes à partir de SimpleMaps

    • Élévations des aéroports à partir de la base de données mondiale des aéroports

• limites_de_la_ville_de_l'aeroport.csv

  • Il s'agit d'une fusion des noms d'aéroports et de villes ci-dessus avec une nouvelle source :

    • Limites de la ville d'après OpenStreetMap

Comme vous pouvez le deviner, nous avons passé un certain temps à combiner ces sources de données dans les deux fichiers ci-dessus, dans le but de pouvoir tester les fonctionnalités géospatiales d'ES|QL. Il se peut que cela ne corresponde pas tout à fait à vos besoins spécifiques en matière de données, mais j'espère que cela vous donnera une idée de ce qui est possible. En particulier, nous voulons démontrer quelques points intéressants :

• Importation de données contenant des champs géospatiaux avec d'autres données indexables

• Importer les données geo_point et geo_shape et les utiliser ensemble dans les requêtes

• Importation de données dans deux index qui peuvent être reliés à l'aide d'une relation spatiale

• Création d'un pipeline d'ingestion pour faciliter les importations futures (au-delà de Kibana)

• Quelques exemples de processeurs d'acquisition, tels que csv, convert et split

Bien que nous parlions de travailler avec des données CSV dans ce blog, il est important de comprendre qu'il y a plusieurs façons d ' ajouter des données géographiques en utilisant Kibana. Dans l'application Carte, vous pouvez télécharger des données délimitées telles que CSV, GeoJSON et ESRI ShapeFiles et vous pouvez également dessiner des formes directement dans la carte. Pour ce blog, nous nous concentrerons sur l'importation de fichiers CSV à partir de la page d'accueil de Kibana.

Importation des aéroports

Le premier fichier, airports.csv, a quelques particularités intéressantes avec lesquelles nous devons composer. Tout d'abord, les colonnes sont séparées par des espaces blancs supplémentaires, ce qui n'est pas typique des fichiers CSV. Deuxièmement, le champ type est un champ à valeurs multiples, que nous devons diviser en champs distincts. Enfin, certains champs ne sont pas des chaînes de caractères et doivent être convertis dans le bon type. Tout cela peut être fait en utilisant la fonction d'importation CSV de Kibana.

Commencez par la page d'accueil de Kibana. Une section intitulée "Get started by adding integrations" contient un lien intitulé "Upload a file":

En cliquant sur ce lien, vous accéderez à la page "Upload file". Ici, vous pouvez faire glisser et déposer le fichier airports.csv, et Kibana analysera le fichier et vous présentera un aperçu des données. Il aurait dû détecter automatiquement que le délimiteur était une virgule et que la première ligne était la ligne d'en-tête. Cependant, il n'a probablement pas supprimé les espaces blancs supplémentaires entre les colonnes, ni déterminé les types de champs, en supposant que tous les champs sont soit text, soit keyword. Nous devons y remédier.

Cliquez sur Override settings et cochez les cases Should trim fields et Apply pour fermer les paramètres. Nous devons maintenant fixer les types de champs. Elle est disponible à la page suivante, alors cliquez sur Import.

Choisissez d'abord un nom d'index, puis sélectionnez Advanced pour accéder à la page des mappages de champs et du processeur d'ingestion.

Ici, nous devons apporter des modifications aux mappages de champs pour l'index, ainsi qu'au pipeline d'ingestion pour l'importation des données. Tout d'abord, alors que Kibana a probablement auto-détecté le champ scalerank comme étant long, il a perçu par erreur les champs location et city_location comme étant keyword. Modifiez-les à l'adresse geo_point, et vous obtiendrez des correspondances qui ressembleront à quelque chose de semblable :

Vous disposez d'une certaine marge de manœuvre, mais sachez que le type de champ choisi aura une incidence sur la manière dont il sera indexé et sur le type de requêtes possibles. Par exemple, si vous laissez location comme keyword, vous ne pouvez pas effectuer de recherches géospatiales sur ce site. De même, si vous laissez elevation en tant que text, vous ne pouvez pas effectuer de requêtes sur les plages numériques.

Il est maintenant temps de réparer le pipeline d'ingestion. Si Kibana a détecté automatiquement scalerank comme long ci-dessus, il aura également ajouté un processeur pour convertir le champ en long. Nous devons ajouter un processeur similaire pour le champ elevation, en le convertissant cette fois en double. Modifiez le pipeline pour vous assurer que cette conversion est en place. Avant de l'enregistrer, nous souhaitons effectuer une autre conversion, afin de diviser le champ type en plusieurs champs. Ajouter un processeur split au pipeline, avec la configuration suivante :

Le pipeline d'ingestion final devrait ressembler à ceci :

Notez que nous n'avons pas ajouté de processeur de conversion pour les champs location et city_location. Cela s'explique par le fait que le type geo_point dans la correspondance des champs comprend déjà le format WKT des données de ces champs. Le type geo_point peut comprendre une série de formats, notamment WKT, GeoJSON, etc. Si nous avions, par exemple, deux colonnes dans le fichier CSV pour latitude et longitude, nous aurions dû ajouter un processeur script ou set pour les combiner en un seul champ geo_point (par exemple. "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Nous sommes maintenant prêts à importer le fichier. Cliquez sur Import et les données seront importées dans l'index avec les mappings et le pipeline d'ingestion que nous venons de définir. Si des erreurs surviennent lors de l'ingestion des données, Kibana les signale ici, afin que vous puissiez modifier les données sources ou le pipeline d'ingestion et réessayer.

Remarquez qu'une nouvelle ligne d'ingestion a été créée. Il peut être consulté en allant dans la section Stack Management de Kibana, et en sélectionnant Ingest pipelines. Ici, vous pouvez voir le pipeline que nous venons de créer et le modifier si nécessaire. En fait, la section Ingest pipelines peut être utilisée pour créer et tester des pipelines d'ingestion, une fonctionnalité très utile si vous prévoyez d'effectuer des ingérences encore plus complexes.

Si vous souhaitez explorer ces données immédiatement, passez aux sections suivantes, mais si vous souhaitez également importer les limites des villes, continuez à lire.

Importation des limites de la ville

Le fichier des limites des villes disponible à l'adresse airport_city_boundaries.csv est un peu plus simple à importer que l'exemple précédent. Il contient un champ city_boundary qui est une représentation WKT des limites de la ville sous forme de POLYGON, et un champ city_location qui est une représentation geo_point de l'emplacement de la ville. Nous pouvons importer ces données de la même manière que les données aéroportuaires, à quelques différences près :

• Nous avons dû sélectionner le paramètre d'annulation Has header row car il n'était pas détecté automatiquement.

• Nous n'avons pas eu besoin de découper les champs, car les données étaient déjà exemptes d'espaces blancs supplémentaires.

• Nous n'avons pas eu besoin de modifier le pipeline d'ingestion car tous les types étaient soit des chaînes de caractères, soit des types spatiaux.

• Nous avons toutefois dû modifier les correspondances entre les champs afin de définir le champ city_boundary comme étant geo_shape et le champ city_location comme étant geo_point

Nos mappages de champs finaux se présentaient comme suit :

Comme pour l'importation airports.csv, il suffit de cliquer sur Import pour importer les données dans l'index. Les données seront importées avec les mappings que nous avons édités et le pipeline d'ingestion défini par Kibana.

Explorer les données géospatiales avec les outils de développement

Dans Kibana, il est habituel d'explorer les données indexées avec "Discover". Cependant, si votre intention est d'écrire votre propre application en utilisant des requêtes ES|QL, il peut être plus intéressant d'essayer d'accéder à l'API Elasticsearch brute. Kibana dispose d'une console pratique pour expérimenter l'écriture de requêtes. Il s'agit de la console Dev Tools, qui se trouve dans la barre latérale de Kibana. Cette console communique directement avec le cluster Elasticsearch et peut être utilisée pour exécuter des requêtes, créer des index, etc.

Essayez ce qui suit :

Cela devrait donner les résultats suivants :

distance

abbrev

nom

Lieu

pays

ville

élévation

273418.05776847183

HAM

Hambourg

POINT (10.005647830925 53.6320011640866)

Allemagne

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

POINT (13.2903090925074 52.5544287044101)

Allemagne

Hohen Neuendorf

38.0

483713.15032266214

OSL

Oslo Gardermoen

POINT (11.0991032762581 60.1935783171386)

Norvège

Oslo

208.0

522538.03148094116

BMA

Bromma

POINT (17.9456175406145 59.3555902065112)

Suède

Stockholm

15.0

522538.03148094116

ARN

Arlanda

POINT (17.9307299016916 59.6511203397372)

Suède

Stockholm

38.0

624274.8274399083

DHS

Düsseldorf Int'l

POINT (6.76494446612174 51.2781820420774)

Allemagne

Düsseldorf

45.0

633388.6966435644

PRG

Ruzyn

POINT (14.2674849854076 50.1076511703671)

Tchécoslovaquie

Prague

381.0

635911.1873311149

AMS

Schiphol

POINT (4.76437693232812 52.3089323889822)

Pays-Bas

Hoofddorp

-3.0

670864.137958866

FRA

Francfort Int'l

POINT (8.57182286907608 50.0506770895207)

Allemagne

Francfort

111.0

683239.2529970079

WAW

Okecie Int'l

POINT (20.9727263383587 52.171026749259)

Pologne

Piaseczno

111.0

Visualiser des données géospatiales avec Kibana Maps

Kibana Maps est un outil puissant de visualisation des données géospatiales. Il peut être utilisé pour créer des cartes avec plusieurs couches, chaque couche représentant un ensemble de données différent. Les données peuvent être filtrées, agrégées et stylisées de différentes manières. Dans cette section, nous allons vous montrer comment créer une carte dans Kibana Maps en utilisant les données que nous avons importées dans la section précédente.

Dans le menu Kibana, naviguez vers Analytics->Maps pour ouvrir une nouvelle vue de la carte. Cliquez sur Add Layer et sélectionnez Documents, choisissez la vue de données airports et modifiez le style de la couche pour colorer les marqueurs à l'aide du champ elevation, de sorte que nous puissions facilement voir à quelle hauteur se trouve chaque aéroport.

Cliquez sur "Conserver les modifications" pour enregistrer la carte :

Ajoutez maintenant une deuxième couche, en sélectionnant cette fois la vue de données airport_city_boundaries. Cette fois-ci, nous utiliserons le champ city_boundary pour styliser le calque et définir la couleur de remplissage sur un bleu clair. Les limites de la ville apparaissent alors sur la carte. Veillez à réorganiser les couches de manière à ce que les marqueurs d'aéroport soient placés en haut.

Jointures spatiales

ES|QL ne prend pas en charge les commandes JOIN, mais vous pouvez réaliser un cas spécial de jointure à l'aide de la commande ENRICH. Cette commande s'apparente à une "jointure gauche" en SQL, vous permettant d'enrichir les résultats d'un index avec des données d'un autre index sur la base d'une relation spatiale entre les deux ensembles de données.

Par exemple, enrichissons les résultats d'un tableau d'aéroports avec des informations supplémentaires sur la ville qu'ils desservent en trouvant la limite de la ville qui contient l'emplacement de l'aéroport, puis effectuons quelques statistiques sur les résultats :

Si vous exécutez cette requête sans avoir au préalable préparé l'index enrichi, vous obtiendrez un message d'erreur du type

En effet, comme nous l'avons déjà mentionné, ES|QL ne prend pas en charge les véritables commandes JOIN. L'une des raisons principales est qu'Elasticsearch est un système distribué et que les jointures sont des opérations coûteuses qu'il peut être difficile de faire évoluer. Cependant, la commande ENRICH peut être très efficace, car elle utilise des index enrichis spécialement préparés qui sont dupliqués sur l'ensemble du cluster, ce qui permet d'effectuer des jointures locales sur chaque nœud.

Pour mieux comprendre, concentrons-nous sur la commande ENRICH dans la requête ci-dessus :

Cette commande demande à Elasticsearch d'enrichir les résultats extraits de l'index airports et d'effectuer une jointure intersects entre le champ city_location de l'index original et le champ city_boundary de l'index airport_city_boundaries, que nous avons utilisé dans quelques exemples plus tôt. Mais certaines de ces informations ne sont pas clairement visibles dans cette requête. Ce que nous voyons, c'est le nom d'une politique d'enrichissement city_boundaries, et l'information manquante est encapsulée dans cette définition de politique.

Ici, nous pouvons voir qu'il effectuera une requête geo_match (intersects est la valeur par défaut), que le champ à comparer est city_boundary et que les champs enrich_fields sont les champs que nous voulons ajouter au document d'origine. L'un de ces champs, le region, a été utilisé comme clé de regroupement pour la commande STATS, ce que nous n'aurions pas pu faire sans cette capacité de "jointure à gauche". Pour plus d'informations sur les politiques d'enrichissement, voir la documentation d'enrichissement.

Les index et politiques d'enrichissement d'Elasticsearch ont été conçus à l'origine pour enrichir les données au moment de l'indexation, en utilisant les données d'un autre index d'enrichissement préparé. Dans ES|QL, cependant, la commande ENRICH fonctionne au moment de la requête et ne nécessite pas l'utilisation de pipelines d'ingestion. Cela le rend assez similaire à un SQL LEFT JOIN, sauf que vous ne pouvez pas joindre deux index, mais seulement un index normal à gauche avec un index enrichi spécialement préparé à droite.

Dans les deux cas, que ce soit pour les pipelines d'ingestion ou pour l'utilisation dans ES|QL, il est nécessaire d'effectuer quelques étapes préparatoires pour mettre en place l'index et la politique d'enrichissement. Nous avons déjà importé l'index airport_city_boundaries ci-dessus, mais il n'est pas directement utilisable comme index d'enrichissement dans la commande ENRICH. Nous devons d'abord effectuer deux démarches :

• Créez la politique d'enrichissement décrite ci-dessus pour définir l'index source, le champ de l'index source à comparer et les champs à renvoyer une fois la correspondance établie.

• Exécutez cette politique pour créer l'index d'enrichissement. Cela permet de construire un index interne spécial, en lisant l'index source d'origine dans une structure de données plus efficace qui est copiée à travers le cluster.

La politique d'enrichissement peut être créée à l'aide de la commande suivante :

La politique peut être exécutée à l'aide de la commande suivante :

Notez que si vous modifiez le contenu de l'index airport_city_boundaries, vous devrez réexécuter cette politique pour que les changements soient reflétés dans l'index enrichi. Exécutons à nouveau la requête ES|QL d'origine :

Cette méthode permet d'obtenir les 5 régions qui comptent le plus d'aéroports, ainsi que le centroïde de tous les aéroports qui ont des régions correspondantes et la longueur de la représentation WKT des limites des villes à l'intérieur de ces régions :

centroïde

Compte

région

POINT (-12.139086859300733 31.024386116624648)

126

nul

POINT (-83.10398317873478 42.300230911932886)

3

Détroit

POINT (39.74537850357592 47.21613017376512)

3

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

POINT (-156.80986787192523 20.476673701778054)

3

Hawaï

POINT (-73.94515332765877 40.70366442203522)

3

Ville de New York

POINT (-83.10398317873478 42.300230911932886)

3

Détroit

POINT (-76.66873019188643 24.306286952923983)

2

New Providence

POINT (-3.0252167768776417 51.39245774131268)

2

Cardiff

POINT (-115.40993484668434 32.73126147687435)

2

Municipalité de Mexicali

POINT (41.790108773857355 50.302146775648)

2

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

POINT (-73.88902732171118 45.57078813901171)

2

Montréal

Vous pouvez également remarquer que la région la plus fréquemment trouvée est null. Qu'est-ce que cela peut signifier ? Rappelez-vous que j'ai comparé cette commande à une "jointure gauche" en SQL, ce qui signifie que si aucune limite de ville correspondante n'est trouvée pour un aéroport, l'aéroport est toujours renvoyé, mais avec les valeurs null pour les champs de l'index airport_city_boundaries. Il s'avère que 125 aéroports n'ont pas trouvé de correspondance avec city_boundary, et un aéroport avec une correspondance où le champ region était null. Cela a conduit à un décompte de 126 aéroports sans region dans les résultats. Si votre cas d'utilisation exige que tous les aéroports puissent être mis en correspondance avec les limites d'une ville, il faudra trouver des données supplémentaires pour combler les lacunes. Il serait nécessaire de déterminer deux choses :

• les enregistrements de l'index airport_city_boundaries qui n'ont pas de champs city_boundary

• les enregistrements de l'index airports qui ne correspondent pas à l'aide de la commande ENRICH (c'est-à-dire. ne se croisent pas)

Utilisation de ES|QL pour les données géospatiales dans Kibana Maps

Kibana a ajouté la prise en charge de Spatial ES|QL dans l'application Maps. Cela signifie que vous pouvez désormais utiliser ES|QL pour rechercher des données géospatiales dans Elasticsearch et visualiser les résultats sur une carte.

Il existe une nouvelle option de couche dans le menu d'ajout de couches, appelée "ES|QL". Comme toutes les fonctions géospatiales décrites jusqu'à présent, il s'agit d'un aperçu technique "" . Cette option permet d'ajouter une couche à la carte en fonction des résultats d'une requête ES|QL. Par exemple, vous pouvez ajouter une couche à la carte qui montre tous les aéroports du monde.

Vous pouvez également ajouter une couche qui montre les polygones de l'index airport_city_boundaries ou, mieux encore, la requête complexe ENRICH ci-dessus qui génère des statistiques sur le nombre d'aéroports dans chaque région.

Et ensuite ?

Le précédent blog sur la recherche géospatiale s'est concentré sur l'utilisation de fonctions telles que ST_INTERSECTS pour effectuer des recherches, disponibles dans Elasticsearch depuis la version 8.14. Ce blog vous montre comment importer les données que nous avons utilisées pour ces recherches. Cependant, Elasticsearch 8.15 a été doté d'une fonction particulièrement intéressante : ST_DISTANCE qui peut être utilisée pour effectuer des recherches de distance spatiale efficaces, et ce sera le sujet du prochain blog !

Elasticsearch 8.12 et 8.13 ont apporté une prise en charge de base des types géospatiaux à ES|QL. Cette fonction a été considérablement améliorée par l'ajout de capacités de recherche géospatiale dans la version 8.14. Plus important encore, ce support a été conçu pour se conformer étroitement à la norme Simple Feature Access de l'Open Geospatial Consortium (OGC) utilisée par d'autres bases de données spatiales comme PostGIS, ce qui le rend beaucoup plus facile à utiliser pour les experts SIG familiarisés avec ces normes.

Dans ce blog, nous vous montrerons comment utiliser ES|QL pour effectuer des recherches géospatiales, et comment il se compare aux équivalents SQL et Query DSL. Nous vous montrerons également comment utiliser ES|QL pour effectuer des jointures spatiales et comment visualiser les résultats dans Kibana Maps. Notez que toutes les fonctionnalités décrites ici figurent dans l'aperçu technique de "" , et nous serions ravis de recevoir vos commentaires sur la manière dont nous pouvons les améliorer.

Recherche de données géospatiales

Commençons par un exemple de requête :

Cette opération permet de rechercher tous les polygones de limite de ville qui recoupent un polygone de recherche rectangulaire autour de l'aéroport international de Sanya Phoenix (SYX).

Dans un échantillon de données d'aéroports, de villes et de limites de villes, cette recherche trouve le polygone d'intersection et renvoie les champs souhaités à partir du document correspondant :

abbrev

aéroport

région

ville

ville_location

SYX

Sanya Phoenix Int'l

天涯区

Sanya

POINT(109.5036 18.2533)

C'était facile ! Comparez maintenant cela au DSL Elasticsearch Query classique pour la même requête :

Les deux requêtes sont raisonnablement claires dans leur intention, mais la requête ES|QL ressemble beaucoup à SQL. La même requête dans PostGIS se présente comme suit :

Reprenez l'exemple de ES|QL. C'est un peu la même chose, non ?

Nous avons constaté que les utilisateurs existants de l'API Elasticsearch trouvent ES|QL beaucoup plus facile à utiliser. Nous pensons que les utilisateurs de SQL, en particulier ceux de Spatial SQL, trouveront que ES|QL est très proche de ce qu'ils ont l'habitude de voir.

Pourquoi pas SQL ?

Qu'en est-il d'Elasticsearch SQL ? Il existe depuis un certain temps et possède des fonctions géospatiales. Cependant, Elasticsearch SQL a été écrit comme une enveloppe au-dessus de l'API de requête originale, ce qui signifie que seules les requêtes qui pouvaient être transposées vers l'API originale étaient prises en charge. ES|QL n'a pas cette limitation. Le fait qu'il s'agisse d'une pile entièrement nouvelle permet de nombreuses optimisations qui n'étaient pas possibles avec SQL. Nos benchmarks montrent qu'ES|QL est très souvent plus rapide que l'API Query, en particulier avec les agrégations !

Différences avec SQL

Il ressort clairement de l'exemple précédent que ES|QL est quelque peu similaire à SQL, mais qu'il existe des différences importantes. Par exemple, ES|QL est un langage d'interrogation par pipeline, qui commence par une commande source telle que FROM et enchaîne toutes les commandes suivantes à l'aide du caractère de pipeline |. Il est ainsi très facile de comprendre comment chaque commande reçoit un tableau de données et effectue une action sur ce tableau, comme le filtrage avec WHERE, l'ajout de colonnes avec EVAL, ou l'exécution d'agrégations avec STATS. Plutôt que de commencer par SELECT pour définir les colonnes de sortie finales, il peut y avoir une ou plusieurs commandes KEEP, la dernière spécifiant les résultats de sortie finaux. Cette structure simplifie le raisonnement sur la requête.

Si l'on se concentre sur la commande WHERE dans l'exemple ci-dessus, on constate qu'elle ressemble beaucoup à l'exemple PostGIS :

ES|QL

PostGIS

Outre la différence entre les caractères de citation des chaînes, la plus grande différence réside dans la façon dont nous transformons la chaîne de caractères en un type spatial. Dans PostGIS, nous utilisons le suffixe ::geometry, tandis que dans ES|QL, nous utilisons le suffixe ::geo_shape. En effet, ES|QL fonctionne au sein d'Elasticsearch, et l'opérateur de conversion de type :: peut être utilisé pour convertir une chaîne en l'un des types ES|QL pris en charge, dans ce cas, un geo_shape. En outre, les types geo_shape et geo_point dans Elasticsearch impliquent le système de coordonnées spatiales connu sous le nom de WGS84, plus communément désigné par le numéro SRID 4326. Dans PostGIS, cela doit être explicite, d'où l'utilisation du préfixe SRID=4326; pour la chaîne WKT. Si ce préfixe est supprimé, le SRID sera fixé à 0, ce qui est plus proche des types Elasticsearch cartesian_point et cartesian_shape, qui ne sont pas liés à un système de coordonnées spécifique.

ES|QL et PostGIS fournissent également une syntaxe de fonction de conversion de type :

ES|QL

PostGIS

Fonctions de l'OGC

Elasticsearch 8.14 introduit les quatre fonctions de recherche spatiale de l'OGC suivantes :

ES|QL

PostGIS

Description

ST_INTERSECTS

ST_Intersects

Retourne true si deux géométries se croisent, et false dans le cas contraire.

ST_DISJOINT

ST_Disjoint

Retourne true si deux géométries ne se croisent pas, et false dans le cas contraire. L'inverse de ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Retourne true si une géométrie en contient une autre, et false sinon.

ST_WITHIN

ST_Within

Retourne true si une géométrie est à l'intérieur d'une autre, et false dans le cas contraire. L'inverse de ST_CONTAINS.

Ces fonctions se comportent de manière similaire à leurs homologues PostGIS et sont utilisées de la même manière. Par exemple, ST_INTERSECTS renvoie un message vrai si deux géométries se croisent et un message faux dans le cas contraire. Si vous suivez les liens de documentation dans le tableau ci-dessus, vous remarquerez que tous les exemples ES|QL se trouvent dans une clause WHERE après une clause FROM, alors que tous les exemples PostGIS utilisent des géométries littérales. En fait, les deux plates-formes permettent d'utiliser les fonctions dans n'importe quelle partie de la requête où elles sont utiles.

Le premier exemple dans la documentation PostGIS pour ST_INTERSECTS est le suivant :

L'équivalent en ES|QL serait le suivant :

Notez que nous n'avons pas spécifié le SRID dans l'exemple de PostGIS. En effet, dans PostGIS, lorsque l'on utilise le type geometry, tous les calculs sont effectués sur un système de coordonnées planaires et, par conséquent, si les deux géométries ont le même SRID, le SRID n'a pas d'importance. Dans Elasticsearch, c'est également le cas pour la plupart des fonctions, mais il existe des exceptions où geo_shape et geo_point utilisent des calculs sphériques, comme nous le verrons dans le prochain blog sur la recherche de distance spatiale.

ES|QL polyvalence

Nous avons donc vu ci-dessus des exemples d'utilisation de fonctions spatiales dans les clauses WHERE et dans les commandes ROW. Où cela aurait-il un sens ? Un endroit très utile est la commande EVAL. Cette commande permet d'évaluer une expression et de renvoyer le résultat. Par exemple, déterminons si les centroïdes de tous les aéroports regroupés par nom de pays se trouvent à l'intérieur d'une frontière délimitant le pays :

Les résultats sont attendus, les centroïdes des aéroports britanniques sont situés à l'intérieur de la frontière britannique, mais pas à l'intérieur de la frontière islandaise, et vice versa :

centroïde

Compte

in_uk

en_pays

within_uk

à l'intérieur de la patrie

POINT (-21.946634463965893 64.13187285885215)

1

faux

vrai

faux

vrai

POINT (-2.597342072712148 54.33551226578214)

17

vrai

faux

vrai

faux

POINT (0.04453958108176276 23.74658354606057)

873

faux

faux

faux

faux

En fait, ces fonctions peuvent être utilisées dans n'importe quelle partie de la requête où leur signature a un sens. Ils prennent tous deux arguments, qui sont soit un objet spatial littéral, soit un champ d'un type spatial, et renvoient tous une valeur booléenne. Il est important de noter que le système de référence des coordonnées (CRS) des géométries doit correspondre, sinon une erreur sera renvoyée. Cela signifie que vous ne pouvez pas mélanger les types geo_shape et cartesian_shape dans le même appel de fonction. Vous pouvez toutefois mélanger les types geo_point et geo_shape, car le type geo_point est un cas particulier du type geo_shape, et tous deux partagent le même système de référence de coordonnées. La documentation relative à chacune des fonctions définies ci-dessus énumère les combinaisons de types prises en charge.

En outre, chaque argument peut être un littéral spatial ou un champ, dans l'un ou l'autre ordre. Vous pouvez même spécifier deux champs, deux littéraux, un champ et un littéral, ou un littéral et un champ. La seule condition est que les types soient compatibles. Par exemple, cette requête compare deux champs dans le même index :

La requête demande essentiellement si la ville est située à l'intérieur des limites de la ville, ce qui devrait généralement être le cas, mais il y a toujours des exceptions :

cardinalité

Compte

dans_la_ville

peu

29

faux

nombreux

740

vrai

Une question bien plus intéressante serait de savoir si l'emplacement de l'aéroport se trouve à l'intérieur des limites de la ville desservie par l'aéroport. Cependant, l'emplacement de l'aéroport se trouve dans un index différent de celui qui contient les limites de la ville. Il faut donc trouver une méthode pour interroger efficacement les données de ces deux index distincts et les mettre en corrélation.

Jointures spatiales

ES|QL ne prend pas JOIN en charge les commandes, mais vous pouvez réaliser un cas spécial de jointure à l'aide de la ENRICH commande, qui se comporte de la même manière qu'une "jointure gauche" en SQL. Cette commande s'apparente à une "jointure gauche" en SQL, vous permettant d'enrichir les résultats d'un index avec des données d'un autre index sur la base d'une relation spatiale entre les deux ensembles de données.

Par exemple, enrichissons les résultats d'un tableau d'aéroports avec des informations supplémentaires sur la ville qu'ils desservent en trouvant la limite de la ville qui contient l'emplacement de l'aéroport, puis effectuons quelques statistiques sur les résultats :

Cette méthode permet d'obtenir les 5 régions qui comptent le plus d'aéroports, ainsi que le centroïde de tous les aéroports qui ont des régions correspondantes et la longueur de la représentation WKT des limites des villes à l'intérieur de ces régions :

centroïde

Compte

min_wkt

max_wkt

région

POINT (-32.56093470960719 32.598117914802714)

90

207

207

nul

POINT (-73.94515332765877 40.70366442203522)

9

438

438

Ville de New York

POINT (-83.10398317873478 42.300230911932886)

9

473

473

Détroit

POINT (-156.3020245861262 20.176383580081165)

5

307

803

Hawaï

POINT (-73.88902732171118 45.57078813901171)

4

837

837

Montréal

Alors, que s'est-il vraiment passé ? Où s'est produite la supposée JOIN? L'essentiel de la question réside dans la commande ENRICH:

Cette commande demande à Elasticsearch d'enrichir les résultats extraits de l'index airports et d'effectuer une jointure intersects entre le champ city_location de l'index original et le champ city_boundary de l'index airport_city_boundaries, que nous avons utilisé dans quelques exemples plus tôt. Mais certaines de ces informations ne sont pas clairement visibles dans cette requête. Ce que nous voyons, c'est le nom d'une politique d'enrichissement city_boundaries, et l'information manquante est encapsulée dans cette définition de politique.

Ici, nous pouvons voir qu'il effectuera une requête geo_match (intersects est la valeur par défaut), que le champ à comparer est city_boundary et que les champs enrich_fields sont les champs que nous voulons ajouter au document d'origine. L'un de ces champs, le region, a été utilisé comme clé de regroupement pour la commande STATS, ce que nous n'aurions pas pu faire sans cette capacité de "jointure à gauche". Pour plus d'informations sur les politiques d'enrichissement, voir la documentation d'enrichissement. En lisant ces documents, vous remarquerez qu'ils décrivent l'utilisation des index d'enrichissement pour enrichir les données au moment de l'indexation, en configurant les pipelines d'ingestion. Cela n'est pas nécessaire pour ES|QL, car la commande ENRICH fonctionne au moment de la requête. Il suffit de préparer l'index d'enrichissement avec les données et la politique d'enrichissement nécessaires, puis d'utiliser la commande ENRICH dans vos requêtes ES|QL.

Vous pouvez également remarquer que la région la plus fréquemment trouvée est null. Qu'est-ce que cela peut signifier ? Rappelez-vous que j'ai comparé cette commande à une "jointure gauche" en SQL, ce qui signifie que si aucune limite de ville correspondante n'est trouvée pour un aéroport, l'aéroport est toujours renvoyé, mais avec les valeurs null pour les champs de l'index airport_city_boundaries. Il s'avère que 89 aéroports n'ont pas trouvé de correspondance avec city_boundary, et un aéroport avec une correspondance où le champ region était null. Cela a conduit à un décompte de 90 aéroports sans region dans les résultats. Un autre détail intéressant est la nécessité de la commande MV_EXPAND. Cela est nécessaire car la commande ENRICH peut renvoyer plusieurs résultats pour chaque ligne d'entrée, et MV_EXPAND permet de séparer ces résultats en plusieurs lignes, une pour chaque résultat. Cela explique également pourquoi "Hawaii" affiche des résultats différents de min_wkt et max_wkt: il y avait plusieurs régions portant le même nom mais ayant des limites différentes.

Cartes Kibana

Kibana a ajouté la prise en charge de Spatial ES|QL dans l'application Maps. Cela signifie que vous pouvez désormais utiliser ES|QL pour rechercher des données géospatiales dans Elasticsearch et visualiser les résultats sur une carte.

Il existe une nouvelle option de couche dans le menu d'ajout de couches, appelée "ES|QL". Comme toutes les fonctions géospatiales décrites jusqu'à présent, il s'agit d'un aperçu technique "" . Cette option permet d'ajouter une couche à la carte en fonction des résultats d'une requête ES|QL. Par exemple, vous pouvez ajouter une couche à la carte qui montre tous les aéroports du monde.

Vous pouvez également ajouter une couche qui montre les polygones de l'index airport_city_boundaries ou, mieux encore, la requête complexe ENRICH ci-dessus qui génère des statistiques sur le nombre d'aéroports dans chaque région.

Et ensuite ?

Vous avez peut-être remarqué que dans deux des exemples ci-dessus, nous avons inséré une autre fonction spatiale ST_CENTROID_AGG. Il s'agit d'une fonction d'agrégation utilisée dans la commande STATS et de la première des nombreuses fonctions d'analyse spatiale que nous prévoyons d'ajouter à ES|QL. Nous en parlerons sur notre blog lorsque nous en aurons plus à montrer !

Avant cela, nous souhaitons vous parler d'une fonctionnalité particulièrement intéressante sur laquelle nous avons travaillé : la possibilité d'effectuer des recherches spatiales par distance, l'une des fonctionnalités de recherche spatiale les plus utilisées d'Elasticsearch. Pouvez-vous imaginer à quoi pourrait ressembler la syntaxe des recherches à distance ? Peut-être similaire à une fonction de l'OGC ? Restez à l'écoute du prochain blog de cette série pour le découvrir !

Alerte au spoiler : Elasticsearch 8.15 vient d'être publié, et la recherche de distance spatiale avec ES|QL est incluse !

ES|QL

ES|QL est un nouveau langage de requête Elasticsearch introduit dans Elasticsearch 8.11.0. Pour l'instant, il est disponible en aperçu technique. Il offre un moyen puissant de filtrer, de transformer et d'analyser les données stockées dans Elasticsearch.

Il utilise les tuyaux "" (|) pour manipuler et transformer les données étape par étape. Cette approche permet aux utilisateurs de composer une série d'opérations, où la sortie d'une opération devient l'entrée de la suivante, ce qui permet des transformations et des analyses de données complexes.

Par exemple, la requête suivante renvoie les 3 premiers documents (lignes) de l'index sample_data:

Cas d'utilisation : Fonctionnalités ES|QL dans le client PHP officiel

Pour illustrer les fonctionnalités ES|QL développées dans le client PHP officiel, nous avons stocké dans Elasticsearch un fichier CSV de 81 828 livres (54,4 Mo) contenant les informations suivantes :

Nous avons extrait cette liste de l' ensemble de données publiques Amazon Books Reviews.

Nous avons créé un index books avec les mappings Elasticsearch suivants :

La valeur rating est la moyenne des avis de classement tirés du fichier Books_rating.csv de 2,9 Go.

Vous trouverez ici le script PHP que nous avons utilisé pour importer en masse tous les livres dans Elasticsearch. L'opération en bloc a pris 7 secondes et 28 Mo de RAM en utilisant PHP 8.2.17. Avec le mappage proposé, la taille de l'index dans Elasticsearch est d'environ 62 Mo.

Mapper les résultats ES|QL vers un objet PHP ou une classe personnalisée

Nous pouvons exécuter une requête ES|QL en PHP en utilisant le point de terminaison esql()->query(). Le résultat de cette requête est une structure de données sous forme de tableau. Ceci est exprimé en JSON à l'aide des champs columns et values. Dans le champ columns, nous avons les définitions name et type.

Voici un exemple de requête ES|QL permettant d'obtenir les 10 meilleurs livres écrits par Stephen King, classés par ordre d'appréciation des utilisateurs :

Le résultat JSON d'Elasticsearch se présente comme suit :

Dans cet exemple, nous avons 6 propriétés (auteur, description, éditeur, note, titre, année) liées à un livre et 10 résultats, tous des livres de Stephen King.

Une liste de tous les types pris en charge dans ES|QL est présentée ici.

L'objet de réponse $result est accessible sous la forme d'un tableau, d'une chaîne de caractères ou d'un objet (voir ici pour plus d'informations).

L'interface objet permet d'accéder aux valeurs à l'aide de propriétés et d'index. Par exemple, $result->values[0][4] renvoie le titre (4) du premier livre (0) de la liste, $result->values[1][3] renvoie le rang (3) du deuxième livre (1), etc. Rappelez-vous que l'index d'un tableau en PHP commence à zéro.

Cette interface peut être suffisante pour certains cas d'utilisation, mais la plupart du temps, nous aimerions avoir un tableau d'objets comme résultat.

Pour convertir le résultat en un tableau d'objets, nous pouvons utiliser la nouvelle fonction mapTo() d'elasticsearch-php.

Cette fonction est disponible directement dans l'objet de réponse Elasticsearch. Cela signifie que vous pouvez y accéder de la manière suivante :

Si vous disposez d'une classe de livre personnalisée, vous pouvez mapper le résultat en l'utilisant, comme suit :

Si votre classe possède d'autres propriétés en plus de celles incluses dans le résultat ES|QL, cela fonctionnera également. La fonction mapTo() n'utilisera que les propriétés renvoyées sous forme de colonnes dans le résultat ES|QL.

Vous pouvez télécharger tous les exemples présentés dans cet article ici.