Wie MATCH und TO_TEXT die Volltextsuche in beliebigen ES|QL-Ausdrücken ermöglichen

Beginnen wir mit einer Abfrage, die in Elasticsearch 9.4 unmöglich war und den EVAL-Befehl verwendet:

In diesem Beispiel hat Summary keine Mapping- oder Analyzer-Konfiguration. Es ist auch mit keinem invertierten Index verbunden. Es existiert nur für die Dauer dieser Abfrage, kann jetzt aber trotzdem durchsucht werden. Das machen zwei Ergänzungen möglich.

Erstens akzeptiert MATCH nun jeden Ausdruck als erstes Argument, nicht nur ein abgebildetes Feld. Dies umfasst Spalten, die von EVAL erzeugt werden, sowie Funktionsergebnisse, die inline verwendet werden. Es enthält auch nicht zugeordnete Felder, die direkt aus dem Originaldokument geladen wurden. Darüber hinaus werden in diesem neuen Anwendungsfall alle normalerweise von MATCH akzeptierten Datentypen unterstützt.

Der zweite Teil davon ist die neue TO_TEXT-Funktion, die die erste ES|QL-Konvertierungsfunktion ist, die eine Ausgabe vom Typ Text erzeugt. Bisher konnten Textspalten nur aus indizierten zugeordneten Feldern stammen, und alle von ES|QL-Ausdrücken erzeugten Zeichenfolgen waren Schlüsselwortwerte statt Textwerte. Die Unterscheidung ist wichtig, weil MATCH die beiden unterschiedlich behandelt: Textwerte werden analysiert, während Keyword-Werte exakt verglichen werden, was der Umschreibung einer MATCH-Abfrage auf einem indexierten Schlüsselwortfeld in eine Termanfrage ähnelt. TO_TEXT(x) ist die Art, wie Siew ES|QL Folgendes sagen: Behandle diese Zeichenfolge als Volltext.

Dies wird als technische Vorschau in Elasticsearch 9.5 ausgeliefert und hat daher einige Einschränkungen:

• Es wird derzeit nur gefiltert. Ein MATCH-Ergebnis in einem Ausdruck trägt noch nicht zur Relevanzbewertung bei; nur Übereinstimmungen in indizierten Feldern wirken sich auf die Bewertung aus.

• Abfrageoptionen wie Unschärfe und andere werden beim Abgleich eines Ausdrucks noch nicht unterstützt.

• Der Laufzeittext wird mit dem Standard-Analyzer analysiert. Dies ist noch nicht konfigurierbar.

Es wird daran gearbeitet, diese Einschränkungen zu beheben.

Warum sollte man in ES|QL Volltextsuche statt LIKE oder RLIKE verwenden?

ES|QL hatte bereits zwei Möglichkeiten, Zeichenfolgen ohne Index zu suchen: LIKE (Wildcard-Muster) und RLIKE (reguläre Ausdrücke). Beide funktionieren bei jedem Zeichenfolge-Ausdruck, daher ist es fair zu fragen, was MATCH hinzufügt. Die Antwort ist analysis, eine fortgeschrittenere Suchmethode, die Techniken wie Stemming und Synonyme verwendet. Es verwendet auch eine Stoppwortbehandlung.

LIKE ist einfaches Substring-Matching, ohne jegliches Verständnis der Wörter, aus denen eine Zeichenfolge besteht. Nehmen wir beispielsweise an, Sie suchen nach Log-Meldungen über einen Fuchs:

„Fuchs in der Nähe des Hühnerstalls gesichtet“ wird aufgrund der Großschreibung nicht gefunden, während es „Von der Konkurrenz überlistet“ ein Treffer ist, obwohl das überhaupt nichts mit einem Fuchs zu tun hat. Das Verfahren versagt in beiden Richtungen: Es kommt zu falschen Negativbefunden bei der Großschreibung und zu falschen Positivbefunden bei innerhalb anderer Wörter verborgenen Teilzeichenfolgen.

Reguläre Ausdrücke können das Problem der Groß-/Kleinschreibung beheben, aber das Problem der Wortgrenzen wird schnell unübersichtlich. Hier ist ein Beispiel:

Und selbst das stimmt noch nicht. Der Fuchs am Ende eines Satzes, gefolgt von ! oder ?, ist ihm entgangen und es sagt nichts über Tabulatoren, Anführungszeichen oder Klammern aus. Mit jeder Korrektur wird das Muster länger, und die nächste Person, die die Abfrage liest, muss nachvollziehen, was das eigentlich passiert.

MATCH beseitigt das Problem, weil sowohl die Abfrage als auch der Wert durch einen Analyzer laufen, der den Text in Kleinbuchstaben tokenisiert und dann Term für Term abgleicht:

Diese Abfrage passt zu Werten wie „Der schnelle braune Fuchs“ und „FUCHS in der Nähe des Hühnerstalls gesehen“, aber nicht „Von der Konkurrenz überlistet“ oder „FOXTROT-Protokoll aktiviert“, unabhängig von jeglicher Zeichensetzung um die Wörter. Selbstverständlich funktioniert das alles auch für Abfragen mit mehreren Begriffen, wie z. B. MATCH(TO_TEXT(message), „brauner Fuchs“), genau so, wie man es erwarten würde.

Es wird daran gearbeitet, die Nutzung der 36 dedizierten Sprachanalysatoren zu ermöglichen, mit Unterstützung für natürliche Sprachen auf Daten, die nie indexiert oder kartiert wurden.

Anwendungsfälle der Volltextsuche für unindexierte und nicht abgebildete Daten

Die obigen Beispiele suchten Werte, die aus abgebildeten Feldern berechnet wurden. Die interessantesten Anwendungsfälle für ES|QL MATCH bei Ausdrücken betreffen Daten, die zuvor überhaupt nicht durchsuchbar waren. Schauen wir uns einige Beispiele an.

Wie kann man in ES|QL nach nicht zugeordneten Feldern suchen, ohne ein Mapping hinzuzufügen?

Manchmal lässt man absichtlich ein Feld aus den Mappings weg, wie zum Beispiel eine ausführliche Stack-Trace oder eine rohe Anfrage-Nutzlast. Du könntest sogar einen Debug-Blob weglassen. Das Indexieren eines dieser Felder würde Speicherplatz auf der Festplatte und im Heap-Speicher des Dokuments beanspruchen und wäre für ein Feld, das man möglicherweise nur einmal pro Quartal abfragt, nicht lohnenswert.

Diese Entscheidung war immer endgültig, weil nicht zugeordnete Felder für Abfragen völlig unsichtbar waren. In Elasticsearch 9.5 können Sie mit SET unmapped_fields="load" bewirken, dass ES|QL nicht zugeordnete Felder direkt aus dem Quelldokument als Schlüsselwörter lädt. Anschließend wird der Ausdruck in TO_TEXT eingeschlossen, und nun können Sie eine Volltextsuche darauf ausführen:

Hier wurde stack_trace nie zugeordnet. Jeder Wert wird aus den Originaldokumenten abgerufen und direkt analysiert. Sie werden zeilenweise einander zugeordnet. Das ist echte Arbeit und wird niemals so schnell sein wie eine invertierte Index-Suche. Aber jetzt ist das Feld, das Sie nicht indexiert haben, nicht mehr undurchsuchbar. Sie können das Mapping für den Alltag klein halten und trotzdem die einmal im Quartal anstehende Frage beantworten, wenn es darauf ankommt.

Volltextsuche in einem Stichwortfeld ohne Neuindizierung

Keyword-Felder können vieles bewirken. Sie liefern exakte Abgleiche, schnelle Aggregationen und Sortierung, weshalb so viele Felder auf diese Weise zugeordnet werden. Die Mappings der Daten erfolgen jedoch erst, wenn sie eintreffen, und es kann leicht passieren, dass man am Ende etwas anderes mit den Daten machen möchte, als man ursprünglich beabsichtigt hatte. Vielleicht wurde „product_name“ als Keyword zugeordnet, weil die Dashboards darauf aggregieren, und nachdem ein Jahr Produktdaten eingegangen ist, möchte jemand innerhalb der Werte von „product_name“ suchen können.

Die alte Antwort war, das Mapping auf Text zu ändern (oder ein Multi-Feld hinzuzufügen) und alles neu zu indexieren. Das kann sowohl zeitaufwändig als auch kostspielig sein, und in vielen Fällen wollen sich die Nutzer einfach nicht darum kümmern. Die neue Antwort ist ein Funktionsaufruf:

TO_TEXT wandelt die Keyword-Werte spontan in Text um; daher analysiert MATCH sie, anstatt sie exakt zu vergleichen. So können Sie ein Schlüsselwort-Feld abfragen, ohne ein Mapping erstellen oder das Quelldokument neu zu indexieren. Wenn die Suche zu einer alltäglichen Anfrage wird, ist das Indizieren des Feldes als Text zwar immer noch der richtige langfristige Schritt, aber mit TO_TEXT erhalten Sie heute schon eine Antwort, ohne zusätzlichen Aufwand.

Das gleiche Feld in Indizes mit unterschiedlichen Mappings durchsuchen

ES|QL kann viele Indizes umfassen, und dasselbe Feld muss nicht immer in allen gleich aussehen. Wenn dasselbe Feld unterschiedliche Typen in verschiedenen Indizes hat, behandelt ES|QL es als Unionstyp, und eine Konvertierungsfunktion löst den Konflikt. Betrachten wir ein Beispiel, in dem das Message-Feld in der diesjährigen Indexvorlage den Typ „Text“ hat, in der letztjährigen Vorlage aber ein Keyword war:

Jeder Wert wird zur Abfragezeit analysiert, unabhängig davon, ob er aus dem Textindex oder dem Stichwortindex stammt. Die Keywordwerte aus den älteren Indizes werden wie alles andere tokenisiert und kleingeschrieben, sodass „connection reset“ unabhängig davon, in welchem Index es sich befindet, „Connection RESET by peer“ findet.

Ein weiterer interessanter Fall ist, wenn ein Feld nur in einem Index abgebildet wird, aber auch im anderen vorhanden (und nicht abgebildet):

Es gibt eine Nuance, die es wert ist, hier erwähnt zu werden. Wenn error_details in logs-2026, aber nicht in logs-2025 abgebildet ist, kann Elasticsearch diese Abfrage nicht auf Lucene verschieben, da die Indizes, in denen das Feld nicht abgebildet ist, stillschweigend keine Übereinstimmungen liefern würden. Stattdessen stellt der Planer fest, dass das Feld möglicherweise nicht zugeordnet ist und wertet die gesamte MATCH Zeile für Zeile aus, unabhängig davon, woher die Zeilen stammen. Sie müssen nicht wissen, in welchem Ihrer Indizes das Feld zugeordnet ist; die Abfrage beantwortet einfach die Frage.

Wie ES|QL Text zur Abfragezeit ohne invertierten Index analysiert

Wenn ES|QL einen MATCH-Abgleich mit einem Ausdruck plant, analysiert es die Abfragezeichenfolge einmalig, im Voraus, in eine Reihe von Begriffen. Wie jede Zeile anschließend ausgewertet wird, hängt vom Typ des Ausdrucks ab:

Ausdruckstyp

Verarbeitung

Übereinstimmendes Verhalten

Text (über TO_TEXT)

Analyzer tokenisiert Werte in Kleinbuchstaben

Token-gegen-Token-Vergleich; eine Zeile gilt als Treffer, wenn ein Token einem Abfrageterm entspricht (ODER-Semantik)

Schlüsselwort, IP, Datum, numerisch

Keine Analyse; die Abfragekonstante einmal in den nativen Typ konvertiert

Exakter Vergleich pro Zeile

Beide Wege umgehen Lucene vollständig und bewerten Werte Zeile für Zeile. Der Nichttextpfad spiegelt genau das wider, was eine Match-Query tut, wenn sie an Lucene für diese Feldtypen delegiert wird, sodass die Semantik unabhängig davon konsistent bleibt, ob die Abfrage einen Index trifft.

Eine Suche mit invertiertem Index führt ihre Arbeit zur Ingest-Zeit durch und greift bei der Abfrage niemals auf nicht übereinstimmende Dokumente zu. Ein Laufzeit-Match führt diese Analyse zur Abfragezeit für jede Zeile durch, die sie erreicht. Die eine Methode ist schnell, weil die Arbeit bereits erledigt ist; die andere ist flexibel, weil die Daten überhaupt nicht indexiert werden müssen.

Was kommt als Nächstes für die ES|QL-Volltextsuche

Alles in diesem Beitrag ist der erste Teil eines größeren Vorhabens, die Suche in ES|QL auf alles anzuwenden, nicht nur auf das, was man vorher indexiert hat. Die zuvor genannten Einschränkungen werden aktiv bearbeitet und die Roadmap geht weiter:

• Bewertung. Runtime-Matches tragen zu _score bei, sodass Sie nach Relevanz sortieren können, auch wenn die Daten nie indexiert wurden.

• MATCH_PHRASE auf Ausdrücke. Bereits in Elastic Cloud Serverless verfügbar, und kommt im Elastic Stack in Version 9.6.

• Konfigurierbare Analysatoren. Analyzer-Unterstützung für MATCH und MATCH_PHRASE bei Ausdrücken, die Language Analyzer, Stemming und Synonyme zur Abfragezeit ermöglichen.

• Matchoptionen. Optionen wie Unschärfe und Operator für Laufzeitübereinstimmungen.

• Vektorsuche. Generieren von Einbettungen pro Zeile und Ausführen der k-Nearest-Neighbor-Methode (kNN) auf Laufzeit-dense_vector-Ausdrücken, wodurch die semantische Suche auch auf unindizierte Daten ausgeweitet wird.

Probieren Sie noch heute die ES|QL-Volltextsuche für Ausdrücke aus.

Sie können die Laufzeitsuche noch heute ausprobieren. Es ist jetzt in Elastic Cloud Serverless verfügbar, wo neue ES|QL-Fähigkeiten zuerst erscheinen und als technische Vorschau in Elasticsearch 9.5 ausgeliefert werden. Beginnen Sie mit der Suchfunktionsreferenz und prüfen Sie die ES|QL-Einschränkungsseite für die aktuellen Grenzen. Es ist eine technische Vorschau, weil wir Ihr Feedback wollen: Wenn Sie nach etwas suchen, das nie indexiert wurde, und überrascht, sei es positiv oder negativ, würden wir gerne davon hören.

Was ist neu bei der Erstellung von KI-Dashboards in Kibana?

Funktionalität

Technische Vorschau (9.4)

GA (9.5)

Fehlerbehandlung

Kein Wiederholungsversuch bei fehlgeschlagenen ES|QL-Abfragen

Automatischer, bis zu dreimaliger erneuter Versuch mit Abfrageprüfung und Anpassung

ES|QL-Generierungskosten

Alle Abfragen werden über das primäre Modell weitergeleitet

Gestaffelte Modellrouten, bis zu fünfmal günstiger

Zeitbereich

Festgelegtes Standardfenster

Automatische Auswahl basierend auf der Daten-Zeit-Verteilung

Filtersteuerungen

Nein

Automatisch für die relevantesten Felder

Vega-Lite-Diagramme

Nein

Erstellung in natürlicher Sprache, mit Streudiagrammen, Boxplots, bedingter Formatierung und benutzerdefinierten Tooltips

Diagrammbearbeitung

Nein

Bestehende Vega-Lite-Panels können in natürlicher Sprache bearbeitet werden

Automatische Fehlerbehebung bei der KI-Dashboard-Generierung

In der technischen Vorschau wurden fehlgeschlagene ES|QL-Abfragen vom Agenten nicht wiederholt. In Version 9.5 werden Abfragefehler erkannt und die Abfrage bis zu dreimal wiederholt, wobei jeder Fehler untersucht und die Abfrage angepasst wird, bevor der Agent aufgibt. In der Praxis beseitigt dies die meisten Probleme mit leeren Panels und erzeugt Dashboards, die schon beim ersten Versuch korrekt gerendert werden.

Warum ist die Erstellung von KI-Dashboards in Elastic 9.5 günstiger?

Nicht jeder Schritt bei der Dashboard-Erstellung erfordert das gleiche Maß an Argumentation. In Version 9.5 erfolgt die ES|QL-Generierung standardmäßig über ein leichteres Modell und greift nur bei Bedarf auf das primäre Modell zurück. Wenn Ihr Connector Claude Opus 4.8 von Anthropic verwendet, bedeutet das fünfmal günstigere Kosten für die ES|QL-Generierung in allen Panels.

Automatische Zeitbereichsauswahl auf der Grundlage Ihrer Daten

Dashboards sind nur dann nützlich, wenn sie den richtigen Datenausschnitt anzeigen. Der Agent wendet nun eine verbesserte Logik an, um einen für die abgefragten Daten sinnvollen Zeitbereich auszuwählen, es sei denn, der Nutzer fragt nach einem bestimmten Zeitbereich. Er berücksichtigt die Zeitverteilung der Daten und passt sich entsprechend an, seien es die letzte Stunde für einen Live-Vorfall oder die letzten 90 Tage für eine Trendanalyse, anstatt standardmäßig auf ein festes Zeitfenster zurückzugreifen.

Automatische Filtersteuerungen auf KI-generierten Dashboards

Die Erstellung von Dashboards unterstützt nun Steuerelemente; das heißt interaktive Filter, mit denen die Betrachter ein Dashboard nach Feldwerten eingrenzen können, ohne die zugrunde liegenden Abfragen bearbeiten zu müssen. Beim Generieren eines Dashboards fügt der Agent am oberen Rand automatisch Steuerelemente für die relevantesten Filterfelder hinzu.

Vega-Lite-Diagramme aus natürlicher Sprache: Diagrammtypen und Formatierung jenseits der Standardeinstellungen

Vega und Vega-Lite unterstützen in Kibana eine breite Palette von Diagrammtypen und Anpassungen. Mit Version 9.5 können Sie sie aus einfacher Sprache erstellen und müssen den Code nicht selbst schreiben. 

Streudiagramme, Boxplots und weitere Diagrammtypen in Vega-Lite

Streudiagramme, Boxplots, facettierte Small Multiples, Blasendiagramme und Kompositionsdiagramme (z. B. Histogramme, kombiniert mit Heatmaps) sowie viele andere werden von Vega-Lite unterstützt. Ein Prompt wie Zeig mir ein Streudiagramm zu Reaktionszeit vs. Anfragegröße, farbig nach Dienstprogrammname erzeugt ein Vega-Lite-Panel mit den richtigen Datenzuordnungen. Die Diagramme verwenden die Standardfarbpaletten von Kibana, um sich harmonisch in das restliche Dashboard einzufügen.

Bedingte Formatierung, benutzerdefinierte Tooltips und Beschriftungen auf Standarddiagrammen

Selbst bei Diagrammtypen, die in einem Dashboard bereits systemeigen sind, zum Beispiel Balkendiagramme, Liniendiagramme oder Flächendiagramme, benötigen Sie manchmal mehr Kontrolle, als die Standardfunktionen bieten. Vega-Lite schließt diese Lücke über den Chat. Zu den Beispielen gehören:

• Bedingte Farbformatierung: Datenpunkte oberhalb eines Schwellenwerts können farbig anders dargestellt werden; beispielsweise werden Datenpunkte in einem Liniendiagramm oder in Balkendiagrammen rot eingefärbt, wenn eine Kennzahl über das Service Level Objective (SLO) hinausgeht. Bitten Sie den Agenten etwa: Färbe alle Punkte über 500 ms für mein Liniendiagramm rot ein.

  

• Individuelle Markierungen und Beschriftungen: Fügen Sie Emojis, Symbole oder Inline-Textbeschriftungen zu Datenpunkten hinzu, um den Status auf einen Blick zu erkennen.

  

• Individuelle Tooltips: Reichern Sie Hover-Zustände mit zusätzlichen Metriken, Kontext oder berechneten Werten an, die nicht Teil der Diagrammachsen sind. Formulieren Sie etwas wie Füge einen Tooltip hinzu, der die Gesamtzahl der Datensätze und den Prozentsatz pro Balkendiagramm anzeigt.

  

Das funktioniert auch bei der Bearbeitung vorhandener Vega-Charts. Wenn Sie ein Vega-Lite-Panel haben, das eine Anpassung wie z. B. das Ändern einer Farbskala, das Anpassen einer Achse oder ein Umschalten des Markierungstyps benötigt, beschreiben Sie die Änderung im Chat, anstatt sich in den JSON-Code einzuarbeiten.

So haben wir die Vega-Lite-Generierung in natürlicher Sprache in Kibana entwickelt

Das Generieren eines Vega-Lite-Diagramms aus einem Satz heraus ist kein einmaliger Prompt à la Bitte das Modell um JSON. Wir haben eine kleine agentenbasierte Pipeline aufgebaut, die natürliche Sprachabsicht in ein validiertes, datenbasiertes Diagramm umsetzt.

Wenn eine Anfrage eingeht, prüft der Agent zunächst, ob Vega-Lite die richtige Lösung ist. Für Vega-Lite-Anfragen verankert er die Visualisierung in einer echten ES|QL-Abfrage bei Elasticsearch und verwendet dann ein Modell, um den Vega-Lite-Code zu generieren. Vor dem Rendern durchläuft das Ergebnis eine Normalisierungsschicht, die das Schema korrigiert und die kanonische Abfrage bindet. Er wendet außerdem rendersichere Umwandlungen an.

Einige wenige Designentscheidungen machen diesen Workflow zuverlässig:

• Eingetippter Toolaufruf: Die Diagrammerstellung ist ein strukturierter Tool-Aufruf und kein Vega-Lite, das in die Konversation eingefügt wird.

• Beschränkte Generierung: Das Modell erzeugt Vega-Lite-Code innerhalb eines definierten Schemas, was die Ausgabe vorhersehbarer und leichter validierbar macht.

• Kuratierte Beispiele: Strukturelle Muster wie Facetten, geschichtete Markierungen und Heatmaps bieten Orientierung, ohne die zugrunde liegenden Daten zu kopieren.

• Ausführungs- und Verifikationsschleifen: Abfragen werden vor der Diagrammerstellung ausgeführt, und Validierungsfehler lösen Korrekturversuche für die ES|QL-Generierung aus.

Testen Sie die Erstellung von KI-Dashboards und Vega-Lite-Diagrammen in Kibana

Um die Erstellung von Dashboards mit natürlicher Sprache und Vega-Lite-Diagramme auszuprobieren, aktualisieren Sie auf Elastic 9.5 (oder starten eine kostenlose Testversion) und öffnen den Chat in Kibana. Bitten Sie das System anschließend, aus Ihren Daten ein Dashboard zu erstellen. Bei Vega-Lite können Sie versuchen, einen Diagrammtyp anzufordern, den Sie schon immer einmal erstellen wollten, zum Beispiel ein Streudiagramm oder ein Blasendiagramm. Wenn das Ergebnis nicht ganz stimmt, sagen Sie dem Agenten, was er ändern soll. Er wiederholt den Vorgang dann entsprechend.

Dafür ist eine Enterprise-Lizenz erforderlich. Erste Schritte.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.

Ihre erste Abfrage

Definieren Sie zunächst ein einfaches altes CLR-Objekt (POCO), das auf Ihren Elasticsearch-Index abgebildet wird. Eigenschaftsnamen werden über Standardattribute System.Text.Json , wie z. B. [JsonPropertyName], oder über ein konfiguriertes JsonNamingPolicy in ES|QL-Spaltennamen aufgelöst. Die gleichen Regeln für die Quellenserialisierung, die für den Rest des Clients gelten, gelten auch hier.

Nachdem der Typ festgelegt wurde, sieht eine Abfrage folgendermaßen aus:

Der Anbieter übersetzt dies in folgende ES|QL:

Ein paar Details, die zu beachten sind:

• Namensauflösung der Eigenschaften: p.Price wird aufgrund des Attributs [JsonPropertyName] zu price_usd , und p.Brand wird gemäß der Standard-CamelCase-Namenskonvention zu brand .

• Parametererfassung: Die C#-Variablen minPrice und brand werden als benannte Parameter erfasst (?minPrice, ?brand). Sie werden separat von der Abfragezeichenfolge im JSON-Payload gesendet, was Injektionen verhindert und serverseitiges Abfrageplan-Caching ermöglicht.

• Streaming: QueryAsync<T> gibtIAsyncEnumerable<T> zurück. Zeilen werden einzeln materialisiert, sobald sie von Elasticsearch eintreffen.

Sie können auch die generierte Abfrage und ihre Parameter inspizieren, ohne sie auszuführen:

Wie funktioniert das? Eine kurze LINQ-Auffrischung

Der Mechanismus, der LINQ-Anbieter ermöglicht, ist die Unterscheidung zwischen IEnumerable<T> und IQueryable<T>.

Wenn Sie.Where(p => p.Price > 100) auf einem IEnumerable<T>aufrufen, kompiliert die Lambda zu einem Func<Product, bool>, einem regulären Delegierten, den die Laufzeit während des Prozesses ausführt. Dies ist LINQ-to-Objects.

Wenn Sie dieselbe Methode auf einem IQueryable<T>aufrufen, umwickelt der C#-Compiler stattdessen das Lambda in einem Expression<Func<Product, bool>> . Dies ist eine Datenstruktur, die die Struktur des Codes repräsentiert und nicht seine ausführbare Form. Der Ausdrucksbaum kann zur Laufzeit inspiziert, analysiert und in eine andere Sprache übersetzt werden.

Die IQueryProvider Schnittstelle ist der Erweiterungspunkt. Jeder Anbieter kann CreateQuery<T> und Execute<T> implementieren, um diese Ausdrucksbäume in eine Zielsprache zu übersetzen. Entity Framework verwendet dies, um SQL auszugeben. Der LINQ to ES|QL-Anbieter verwendet es, um ES|QL zu emittieren.

Der Ausdrucksbaum für die obige Abfrage sieht wie folgt aus:

Ausdrucksbaum für die Beispielabfrage.

Der Baum ist von innen nach außen verschachtelt: Take umschließt OrderByDescending, welches Where umschließt, welches From umschließt, welches die Wurzel EsqlQueryable<Product> Konstante umschließt. Das Where -Prädikat ist selbst ein Teilbaum von BinaryExpression Knoten für die Operatoren &&, >=, und == , mit MemberExpression Blättern für Eigenschaften-Zugriffe und Abschluss-Erfassungen für die Variablen minPrice und brand . Dies ist die Datenstruktur, die der Provider durchläuft, um das endgültige ES|QL zu erzeugen.

Unter der Haube: Die Übersetzungspipeline

Der Weg von einem LINQ-Ausdruck zu den Abfrageergebnissen folgt einer sechsstufigen Pipeline:

Überblick über die Übersetzungspipeline.

1. Erfassung des Ausdrucksbaums

Wenn man .Where(), .OrderBy(), .Take() und andere Operatoren auf einem IQueryable<T> verkettet, erstellt die Standard-LINQ-Infrastruktur einen Ausdrucksbaum. EsqlQueryable<T> implementiert IQueryable<T> und delegiert an EsqlQueryProvider.

2. Übersetzung

Wenn die Abfrage ausgeführt wird (durch Enumerieren, Aufrufen von ToList() oder Verwenden von await foreach)), durchläuft EsqlExpressionVisitor den Ausdrucksbaum von innen nach außen. Es sendet jeden LINQ-Methodenaufruf an einen spezialisierten Besucher:

Besucher

Übersetzt

In

WhereClauseVisitor

.Where(predicate)

WHERE-Bedingung

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

GroupByVisitor

.GroupBy().Select()

STATISTIKEN ... NACH

OrderByVisitor

.OrderBy() / .ThenBy()

SORT field [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, string methods

80+ ES|QL functions

Bei der Übersetzung werden in Ausdrücken referenzierte C#-Variablen als benannte Parameter erfasst.

3. Abfragemodell

Die Besucher produzieren nicht direkt Zeichenfolgen. Stattdessen produzieren sie QueryCommand Objekte, eine unveränderliche Zwischenrepräsentation. Ein FromCommand, ein WhereCommand, ein SortCommand und ein LimitCommand, jeweils einen ES|QL-Verarbeitungsbefehl repräsentierend. Diese werden in einem EsqlQuery Modell gesammelt.

Abfragemodell und Befehlsmuster.

Dieses Zwischenmodell ist vom Ausdrucksbaum und vom Ausgangsformat entkoppelt. Es kann inspiziert, abgefangen (über IEsqlQueryInterceptor) oder vor der Formatierung modifiziert werden.

4. Formatierung

EsqlFormatter besucht jede QueryCommand in der richtigen Reihenfolge und erstellt die finale ES|QL-Zeichenfolge. Jeder Befehl wird zu einer Zeile, getrennt durch den Pipe-Operator (|), den ES|QL zur Verkettung von Verarbeitungsbefehlen verwendet. Bezeichner, die Sonderzeichen enthalten, werden automatisch mit Backticks versehen.

5. Ausführung

Die formatierte ES|QL-Zeichenfolge und erfasste Parameter werden als JSON-Payload an den /_query -Endpunkt von Elasticsearch gesendet. Die Schnittstelle IEsqlQueryExecutor abstrahiert die Transportschicht, an der die geschichtete Paketarchitektur zum Tragen kommt.

6. Materialisierung

EsqlResponseReader streamt die JSON-Reaktion, ohne das gesamte Ergebnis-Set in den Speicher zu puffern. Ein ColumnLayout -Baum, der einmal pro Abfrage vorab berechnet wird, ordnet flache ES|QL-Spaltennamen (wie address.street, address.city) verschachtelten POCO-Eigenschaften zu. Jede Zeile wird zu einer T -Instanz zusammengestellt und einzeln über IEnumerable<T> oder IAsyncEnumerable<T> zurückgegeben.

Die mehrschichtige Architektur

Die LINQ-to-ES|QL-Funktionalität ist auf drei Pakete aufgeteilt:

Paketarchitektur. Elastic.Esql ist die reine Übersetzungsmaschine. Es hat keine HTTP-Abhängigkeiten und enthält die Expression Visitors, das Abfragemodell, den Formatter und den Response Reader. Sie können es eigenständig verwenden, um ES|QL-Abfragen ohne Elasticsearch-Verbindung zu erstellen und zu inspizieren, was für Tests, Abfrageprotokollierung oder den Aufbau einer eigenen Ausführungsschicht nützlich ist.

Elastic.Clients.Esql ist ein leichter, eigenständiger ES|QL-Client. Es fügt die HTTP-Ausführung über Elastic.Esql mittels Elastic.Transport hinzu. Wenn Ihre Anwendung nur ES|QL und keine der anderen Elasticsearch-APIs benötigt, ist dies die Option mit den geringsten Abhängigkeiten.

Elastic.Clients.Elasticsearch ist der vollständige Elasticsearch.NET-Client. Es baut außerdem auf Elastic.Esql auf und stellt den LINQ-Provider über den Namespace client.Esql bereit. Dies ist der empfohlene Einstieg für die meisten Anwendungen.

Beide Ausführungsschicht-Pakete bieten ihre eigene Implementierung von IEsqlQueryExecutor, der Strategieschnittstelle, die Übersetzung und Transport miteinander verbindet.

Alle drei Pakete sind mit Native AOT kompatibel, wenn sie mit einem quellgenerierten JsonSerializerContext verwendet werden. Für den vollständigen Client siehe die Native AOT-Dokumentation.

Über die Grundlagen hinaus

Das obige Beispiel umfasste das Filtern, Sortieren und Paginieren. Der Anbieter unterstützt ein breiteres Spektrum an Operationen.

Aggregationen

GroupBy, kombiniert mit Aggregatfunktionen in Select, übersetzt in ES|QL STATS ... BY:

Projektionen

Select, mit anonymen Typen erzeugt die Befehle EVAL, KEEP und RENAME:

Umfassende Funktionsbibliothek

Über 80 ES|QL-Funktionen sind über die EsqlFunctions -Klasse verfügbar und decken Datum/Uhrzeit, Zeichenfolgen, Mathematik, IP, Musterabstimmung und Wertung ab. Die Standardmethoden Math.* und string.* werden ebenfalls übersetzt:

LOOKUP JOIN

Indexübergreifende Suchvorgänge werden in ES|QL LOOKUP JOIN übersetzt:

Raw ES|QL Umgehungsmöglichkeit

Für ES|QL-Features, die vom LINQ-Anbieter noch nicht unterstützt werden, können Sie Rohfragmente anfügen:

Serverseitige asynchrone Abfragen

Bei langlaufenden Abfragen sollten diese zur Hintergrundverarbeitung auf dem Server eingereicht werden:

Serverseitige asynchrone Abfragen sind besonders nützlich für langlaufende analytische Abfragen / die Verarbeitung großer Datensätze, die die typischen Timeout-Schwellenwerte überschreiten könnten, oder in Timeout-sensiblen Umgebungen mit Load-Balancern, API-Gateways oder Proxys, die strikte HTTP-Timeouts durchsetzen. Asynchrone Abfragen vermeiden Verbindungsabbrüche, indem die Übermittlung von dem Abruf der Ergebnisse entkoppelt wird.

Erste Schritte

LINQ to ES|QL ist verfügbar ab:

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

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

Installation über NuGet:

dotnet add package Elastic.Clients.Elasticsearch

Die Einstiegspunkte befinden sich auf client.Esql:

Methode

Rückgaben

Anwendungsfall

Query<T>(...)

IEnumerable<T>

Synchrone Ausführung

QueryAsync<T>(...)

IAsyncEnumerable<T>

Asynchrones Streaming

CreateQuery<T>()

IEsqlQueryable<T>

Erweiterte Zusammensetzung und Inspektion

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

Langlaufende serverseitige Abfragen

Eine vollständige Feature-Referenz – einschließlich Abfrageoptionen, Zugriff auf mehrere Felder, verschachtelter Objekte und der Verarbeitung mehrwertiger Felder – finden Sie in der LINQ to ES|QL-Dokumentation.

Fazit

LINQ to ES|QL bringt die volle Ausdruckskraft von C# LINQ in die ES|QL-Abfragesprache von Elasticsearch, sodass Sie stark typisierte, kombinierbare Abfragen schreiben können, ohne Abfragezeichenfolgen von Hand erstellen zu müssen. Mit automatischer Parametererfassung, Streaming-Materialisierung und einer geschichteten Paketarchitektur, die von eigenständiger Übersetzung zum vollständigen Elasticsearch-Client skaliert, fügt es sich natürlich in .NET-Anwendungen jeder Größe ein. Installieren Sie den neuesten Client, verweisen Sie Ihre LINQ-Ausdrücke auf einen Index und überlassen Sie den Rest dem Provider.

Warum das wichtig ist

Die meisten typischen analytischen Workflows laufen letztendlich auf die Gruppierung von Daten hinaus. Ob es nun um die Berechnung der durchschnittlichen Bytes pro Host, das Zählen von Ereignissen pro Nutzer oder das Aggregieren von Metriken über Dimensionen hinweg geht, die Kernoperation ist immer dieselbe – Schlüssel werden Gruppen zugeordnet und laufende Aggregate aktualisiert.

In kleinem Maßstab funktioniert fast jede vernünftige Hashtabelle einwandfrei. Bei großer Skalierung (Hunderte Millionen Dokumente und Millionen verschiedener Gruppen) beginnen Details eine Rolle zu spielen. Auslastungsfaktoren, Sondierungsstrategie, Speicherlayout und Cache-Verhalten können den Unterschied zwischen linearer Leistung und einer Flut von Cache-Fehlern ausmachen.

Elasticsearch unterstützt diese Workloads seit Jahren und wir suchen stets nach Möglichkeiten, die Kernalgorithmen zu modernisieren. Daher haben wir einen neueren, von Schweizer Tabellen inspirierten Ansatz evaluiert und ihn auf die Art und Weise angewendet, wie ES|QL Statistiken berechnet.

Was genau sind Schweizer Tabellen?

Schweizer Tabellen sind eine Familie moderner Hash-Tabellen, die von Googles SwissTable popularisiert und später in Abseil und anderen Bibliotheken übernommen wurden.

Traditionelle Hash-Tabellen verbringen viel Zeit damit, Zeiger zu verfolgen oder Schlüssel zu laden, nur um festzustellen, dass sie nicht übereinstimmen. Das definierende Feature von Schweizer Tabellen ist die Fähigkeit, die meisten Anfragen mit einer winzigen, im Cache befindlichen Array-Struktur abzulehnen, die getrennt von Schlüsseln und Werten gespeichert wird und als Kontrollbytes bezeichnet wird, um den Speicherverkehr drastisch zu reduzieren.

Jedes Kontrollbyte repräsentiert einen einzelnen Slot und kodiert in unserem Fall zwei Dinge: ob der Slot leer ist und einen kurzen Fingerabdruck, der aus dem Hash abgeleitet wird. Diese Steuerbytes sind zusammenhängend im Speicher angeordnet, typischerweise in Gruppen von 16, was sie ideal für die SIMD-Verarbeitung (Single Instruction, Multiple Data).

Anstatt einen Slot nach dem anderen zu testen, scannen Schweizer Tabellen einen gesamten Kontrollbyte-Block mithilfe von Vektorinstruktionen. In einer einzigen Operation vergleicht die CPU den Fingerabdruck des eingehenden Schlüssels mit 16 Slots und filtert leere Einträge heraus. Nur bei den wenigen Kandidaten, die diesen Schnelltest überstehen, ist das Laden und Vergleichen der tatsächlichen Schlüssel erforderlich.

Dieses Design tauscht eine kleine Menge zusätzlicher Metadaten gegen eine viel bessere Cache-Lokalität und weitaus weniger zufällige Ladevorgänge ein. Wenn die Tabelle wächst und die Sondenketten länger werden, werden diese Eigenschaften immer wertvoller.

SIMD im Mittelpunkt

Der eigentliche Star der Show ist SIMD.

Die Steuerbytes sind nicht nur kompakt, sondern auch explizit für die Verarbeitung mit Vektorbefehlen konzipiert. Ein einzelner SIMD-Vergleich kann 16 Fingerabdrücke gleichzeitig überprüfen und verwandelt, was normalerweise eine Schleife wäre, in eine Handvoll breiter Operationen. Zum Beispiel:

In der Praxis bedeutet das:

• Weniger Zweige.

• Kürzere Testketten.

• Weniger Ladevorgänge aus Schlüssel- und Wertspeicher.

• Viel bessere Nutzung der Ausführungseinheiten der CPU.

Die meisten Suchvorgänge kommen nie über den Control-Byte-Scan hinaus. Wenn sie das tun, ist die verbleibende Arbeit zielgerichtet und vorhersehbar. Das ist genau die Art von Arbeitslast, für die moderne CPUs gut geeignet sind.

SIMD unter der Haube

Für Leser, die gerne einen Blick hinter die Kulissen werfen, hier eine Erklärung, was beim Einfügen eines neuen Schlüssels in die Tabelle passiert. Wir verwenden die Panama Vector API mit 128-Bit-Vektoren und bearbeiten somit 16 Kontrollbytes parallel.

Der folgende Ausschnitt zeigt den Code, der auf einem Intel Rocket Lake mit AVX-512 generiert wurde. Obwohl die Anweisungen diese Umgebung widerspiegeln, hängt das Design nicht von AVX-512 ab. Die gleichen hochstufigen Vektoroperationen werden auf anderen Plattformen mit gleichwertigen Befehlen (zum Beispiel AVX2, SSE oder NEON) ausgesendet.

Jede Anweisung hat eine klare Rolle im Einfügeprozess:

• vmovdqu: Lädt 16 aufeinanderfolgende Steuerbytes in das 128-Bit-xmm0-Register.

• vpbroadcastb: Repliziert den 7-Bit-Fingerabdruck des neuen Schlüssels über alle Spuren des xmm1-Registers.

• vpcmpeqb: Vergleicht jedes Steuerbyte mit dem gesendeten Fingerabdruck und erstellt eine Maske mit möglichen Übereinstimmungen.

• kmovq + test: Verschiebt die Maske in ein allgemeines Register und überprüft schnell, ob ein Match existiert.

Schließlich entschieden wir uns dafür, Gruppen von jeweils 16 Kontrollbytes zu untersuchen, da Benchmarks zeigten, dass eine Erweiterung auf 32 oder 64 Bytes mit breiteren Registern keinen messbaren Leistungsvorteil brachte.

Integration in ES|QL

Die Einführung des Hashing im Schweizer Stil in Elasticsearch war nicht einfach ein direkter Ersatz. ES|QL stellt hohe Anforderungen an die Speicherverwaltung, die Sicherheit und die Integration mit dem Rest der Compute Engine.

Wir haben die neue Hash-Tabelle eng in die Speicherverwaltung von Elasticsearch integriert, einschließlich des Seitenrecyclers und der Abrechnung von Schutzschaltern, um sicherzustellen, dass die Zuweisungen sichtbar und begrenzt bleiben. Die Aggregationen von Elasticsearch werden dicht gespeichert und durch eine Gruppen-ID indexiert, wodurch das Speicherlayout kompakt und schnell für Iterationen bleibt und zudem bestimmte Leistungsoptimierungen durch zufälligen Zugriff ermöglicht werden.

Bei Byte-Schlüsseln mit variabler Länge wird der vollständige Hash zusammen mit der Gruppen-ID zwischengespeichert. Dadurch wird die Neuberechnung teurer Hash-Codes während der Sondierung vermieden und die Cache-Lokalität verbessert, indem zusammengehörige Metadaten nahe beieinander gehalten werden. Während des Rehashings können wir uns auf den zwischengespeicherten Hash und die Kontroll-Bytes verlassen, ohne die Werte selbst zu inspizieren, wodurch die Kosten für die Größenänderung niedrig gehalten werden.

Eine wichtige Vereinfachung in unserer Implementierung besteht darin, dass Einträge niemals gelöscht werden. Dadurch werden Tombstones (Markierungen zur Identifizierung zuvor belegter Steckplätze) überflüssig, und leere Steckplätze bleiben wirklich leer, was das Verhalten der Sonde weiter verbessert und Kontroll-Byte-Scans effizient macht.

Das Ergebnis ist ein Design, das sich nahtlos in das Ausführungsmodell von Elasticsearch einfügt und gleichzeitig die Leistungsmerkmale beibehält, die Schweizer Tabellen so attraktiv machen.

Wie ist die Performance?

Bei kleinen Kardinalitäten schneiden die Schweizer Tabellen in etwa gleich gut ab wie die bestehende Implementierung. Das ist zu erwarten: Bei kleinen Tabellen spielen Cache-Effekte eine geringere Rolle und es gibt wenig Optimierungsbedarf.

Mit zunehmender Kardinalität ändert sich das Bild schnell.

Die obige Heatmap zeigt die Zeitverbesserungsfaktoren für verschiedene Schlüsselgrößen (8, 32, 64 und 128 Byte) über Kardinalitäten von 1.000 bis 10.000.000 Gruppen hinweg. Mit zunehmender Kardinalität steigt der Verbesserungsfaktor stetig an und erreicht bei Gleichverteilungen Werte von bis zu 2–3x.

Dieser Trend entspricht genau dem, was die Konstruktion vorhersagt. Höhere Kardinalität führt zu längeren Prüfketten in traditionellen Hash-Tabellen, während die meisten Suchvorgänge nach wie vor in SIMD-freundlichen Kontroll-Byte-Blöcken gelöst werden.

Das Cache-Verhalten erzählt die Geschichte

Um die Beschleunigungen besser zu verstehen, haben wir denselben JMH-benchmarks unter Linux perf ausgeführt und Cache- sowie TLB-Statistiken erfasst.

Im Vergleich zur ursprünglichen Implementierung benötigt die Schweizer Version insgesamt etwa 60 % weniger Cache-Zugriffe. Die Last-Level-Cache-Ladevorgänge sinken um mehr als das Vierfache, und LLC-Ladefehler gehen um mehr als das Sechsfache zurück. Da LLC-Fehlzugriffe oft direkt in Hauptspeicherzugriffe übersetzt werden, erklärt diese Reduzierung allein einen großen Teil der End-to-End-Verbesserung.

Näher an der CPU beobachten wir weniger L1-Datencache-Fehler und fast 6x weniger TLB-Datenfehler, was auf eine engere räumliche Lokalität und besser vorhersagbare Speicherzugriffsmuster hindeutet.

Dies ist der praktische Nutzen von SIMD-freundlichen Kontrollbytes. Anstatt Schlüssel und Werte immer wieder von verstreuten Speicherplätzen zu laden, werden die meisten Suchvorgänge durch das Durchsuchen einer kompakten, im Cache befindlichen Struktur gelöst. Weniger berührter Speicher bedeutet weniger Fehltritte, und weniger Fehltritte bedeuten schnellere Abfragen.

Fazit

Indem wir einen Hashtabellenentwurf im Schweizer Stil verwendeten und uns stark auf SIMD-freundliche Sondierungen konzentrierten, erreichten wir 2–3-fache Beschleunigungen für ES|QL-Statistik-Workloads mit hoher Kardinalität sowie eine stabilere und vorhersehbarere Leistung.

Diese Arbeit zeigt, wie moderne CPU-fähige Datenstrukturen erhebliche Verbesserungen ermöglichen können, selbst bei bekannten Problemen wie Hash-Tabellen. Hier gibt es mehr Raum für Erkundungen, wie etwa zusätzliche Spezialisierungen von primitiven Typen und die Verwendung in anderen Pfaden mit hoher Kardinalität, wie Joins, die alle Teil der umfassenderen und fortlaufenden Bemühungen sind, die internen Abläufe von Elasticsearch kontinuierlich zu modernisieren.

Wenn Sie an den Details interessiert sind oder die Arbeit verfolgen möchten, schauen Sie sich diesen Pull Request und den Meta-Issue-Fortschritt auf Github an.

Viel Spaß beim Hashing!

Wir haben vor Kurzem zum Open-Source-Projekt Google MCP Toolbox for Databases beigetragen, indem wir Unterstützung für Elasticsearch als Datenbank hinzugefügt haben.

Mit diesem neuen Feature können Sie jetzt die Google MCP Toolbox verwenden, um eine Verbindung zu Elasticsearch herzustellen und direkt mit Ihren Daten zu „kommunizieren“.

Elasticsearch

Wir benötigen eine laufende Elasticsearch-Instanz. Sie können eine kostenlose Testversion auf Elastic Cloud aktivieren oder es lokal mit dem start-local-Skript installieren:

Dadurch werden Elasticsearch und Kibana auf Ihrem Computer installiert und ein API-Schlüssel generiert, der zur Konfiguration der Google MCP Toolbox verwendet wird.

Der API-Schlüssel wird als Ausgabe des vorherigen Befehls angezeigt und in einer .env-Datei im Ordner elastic-start-local gespeichert.

Installieren Sie den Beispieldatensatz

Nach der Installation können Sie sich mit dem Benutzernamen elastic und dem vom start-local-Skript generierten Passwort (gespeichert in einer .env-Datei) bei Kibana anmelden.

Sie können den Datensatz für E-Commerce-Bestellungen , der von Kibana verfügbar ist, installieren. Sie enthält einen einzigen Index namens kibana_sample_data_ecommerce, der Informationen über 4.675 Bestellungen von einer E-Commerce-Website enthält. Für jede Bestellung haben wir folgende Informationen:

• Kundeninformationen (Name, Ausweis, Geburtsdatum, E-Mail-Adresse usw.)

• Bestelldatum

• Bestell-ID

• Produkte (Liste aller Produkte mit Preis, Menge, ID, Kategorie, Rabatt usw.)

• SKU

• Gesamtpreis (ohne Steuern, mit Steuern)

• Gesamtmenge

• Geoinformationen (Stadt, Land, Kontinent, Ort, Region)

Um die Beispieldaten zu installieren, öffnen Sie die Seite Integrationen in Kibana (suchen Sie in der Suchleiste oben nach „Integration“) und installieren Sie die „Beispieldaten“. Weitere Details finden Sie in der Dokumentation hier: https://www.elastic.co/docs/explore-analyze/#gs-get-data-into-kibana.

Ziel dieses Artikels ist es, zu zeigen, wie einfach es ist, die Google MCP Toolbox so zu konfigurieren, dass sie sich mit Elasticsearch verbindet und mit dem kibana_sample_data_ecommerce-Index in natürlicher Sprache interagiert.

Google MCP Toolbox

Die Google MCP Toolbox ist ein Open-Source-MCP-Server, der entwickelt wurde, um Anwendungen und KI-Agenten die sichere und effiziente Interaktion mit Datenbanken zu erleichtern. Das Projekt, das zuvor unter dem Namen „GenAI Toolbox for Databases“ bekannt war, wurde nach der vollständigen Kompatibilität mit dem Model Context Protocol (MCP) umbenannt. Ziel ist es, den üblicherweise beim Verbinden von Agenten mit Datenbanken erforderlichen hohen Aufwand zu reduzieren, indem Verbindungspooling, Authentifizierung, Beobachtbarkeit und andere betriebliche Belange im Hintergrund übernommen werden.

Im Kern ermöglicht es die Toolbox Entwicklern, wiederverwendbare, hochwertige Werkzeuge zu definieren, die Datenbankinteraktionen kapseln. Diese Tools können dann von jedem MCP-kompatiblen Client – wie beispielsweise einem KI-Agenten – aufgerufen werden, ohne dass der Client Low-Level-SQL-Abfragen implementieren oder Datenbankverbindungen verwalten muss. Dieser Ansatz reduziert die Menge an Boilerplate-Code, die für den Aufbau datenbankbewusster Agenten benötigt wird, drastisch und ermöglicht die Integration fortgeschrittener Datenoperationen in nur wenigen Anwendungszeilen. Sobald ein Werkzeug definiert ist, kann es von mehreren Agenten, Frameworks oder Sprachen gemeinsam genutzt werden (Abbildung 1).

Ein großer Vorteil der Nutzung der Toolbox ist das integrierte Sicherheitsmodell. Authentifizierungsabläufe wie OAuth2 und OIDC werden nativ unterstützt, sodass Entwickler:innen die Verarbeitung oder Speicherung sensibler Datenbankzugangsdaten in Agenten vermeiden können. Die Plattform bietet außerdem Beobachtbarkeit-Features – einschließlich Metriken und Tracing – über OpenTelemetry, was für Debugging, Monitoring und Deployments in der Produktionsumgebung unerlässlich ist. Insgesamt dient die MCP Toolbox als einheitliche, sichere und erweiterbare Schnittstelle zur Interaktion mit Ihren Daten von jedem MCP-fähigen System.

So installieren Sie die MCP Toolbox

Sie können den MCP-Toolbox-Server unter Linux mit folgendem Befehl installieren:

Für eine Installation unter macOS oder Windows können Sie den hier beschriebenen Anweisungen folgen.

Toolbox für Elasticsearch konfigurieren

Um die MCP Toolbox für Elasticsearch zu konfigurieren, müssen wir eine tools.yaml-Datei erstellen, und zwar wie folgt:

Sie müssen den Wert <insert-here-api-key> durch einen gültigen Elasticsearch-API-Schlüssel ersetzen. Wenn Sie Elasticsearch lokal mit start-local ausführen, finden Sie den API-Schlüssel in der von start-local generierten .env-Datei unter der Variable ES_LOCAL_API_KEY. Wenn Sie Elastic Cloud verwenden, können Sie einen API-Schlüssel generieren, indem Sie das hier beschriebene Verfahren befolgen.

Die vorherigen Tools enthalten die folgende ES|QL-Abfrage für Elasticsearch:

Falls Ihnen ES|QL nicht geläufig ist: Es handelt sich um eine von Elastic entwickelte Abfragesprache, die ähnlich wie SQL funktioniert und mit der man einen oder mehrere Indizes durchsuchen kann. Mehr über ES|QL finden Sie in der offiziellen Dokumentation hier.

Die obige Abfrage sucht nach allen im kibana_sample_data_ecommerce-Index gespeicherten Bestellungen, die den Namen des:der angegebenen Kund:in enthalten, und verwendet den ?name-Parameter (das Fragezeichen bezeichnet einen Parameter).

Der Name des Kunden wird in der vorherigen YAML-Konfiguration mit dem Typ „Zeichenfolge“ und der Beschreibung „Der Name des Kunden“ definiert.

Mit diesem Tool können Fragen zu den Bestellungen eines:einer Kund:in beantwortet werden – zum Beispiel: Wie viele Bestellungen hat Kund:in Foo im Oktober 2025 aufgegeben?

Die Beschreibungen der Werkzeuge und ihrer Parameter sind unerlässlich, um die relevanten Informationen aus der natürlichsprachlichen Anfrage des:der Nutzer:in zu extrahieren. Diese Extraktion erfolgt mithilfe der Funktionsaufruf-Funktion eines Large Language Models (LLM). In der Praxis kann ein LLM bestimmen, welche Funktion (welches Werkzeug) ausgeführt werden muss, um die notwendigen Informationen zu erhalten, sowie die entsprechenden Parameter für diese Funktion.

Für weitere Informationen zu Funktionsaufrufen empfehlen wir, den Artikel OpenAI Function Calling with Elasticsearch von Ashish Tiwari zu lesen.

Führen Sie den Toolbox-Server aus

Sie können die MCP Toolbox unter Verwendung der vorherigen tools.yaml-Datei mit folgendem Befehl ausführen:

Der Parameter –ui führt eine Webanwendung unter http://127.0.0.1:5000/ui aus (Abbildung 2).

Sie können die Option Tools > customer-orders auswählen und im Feld Parametername einen Kundennamen eingeben (z. B. Gwen Sanders) und anschließend auf die Schaltfläche Tool ausführen klicken. Sie sollten eine JSON-Reaktion sehen, wie in Abbildung 3 dargestellt.

Die Einrichtung ist abgeschlossen, und die MCP Toolbox kann das Tool customer-orders ausführen, um mit Elasticsearch zu kommunizieren und dabei die ES|QL-Anfrage auszuführen.

Verwendung der MCP Toolbox mit Gemini CLI

Wir können jeden beliebigen MCP-Client verwenden, um mit der MCP Toolbox für Datenbanken zu kommunizieren. Zum Beispiel können wir Gemini CLI verwenden, ein Befehlszeilen-Tool zur Nutzung von Gemini. Sie können die Gemini CLI gemäß den hier beschriebenen Anweisungen installieren.

Gemini CLI bietet eine vorkonfigurierte Erweiterung für die MCP Toolbox an, verfügbar unter gemini-cli-extensions/mcp-toolbox. Sie können diese Erweiterung installieren, indem Sie folgenden Befehl ausführen:

Nach der Installation müssen Sie in das Verzeichnis gehen, in dem Sie die Konfigurationsdatei tools.yaml für die MCP Toolbox gespeichert haben, und Gemini CLI wie folgt ausführen (dieser Schritt ist erforderlich, damit die Gemini-CLI automatisch mit der MCP-Toolbox konfiguriert wird):

In Abbildung 4 sollten Sie eine Ausgabeanzeige sehen.

Mit dem folgenden Befehl können Sie überprüfen, ob die MCP Toolbox verbunden ist:

Sie sollten die mcp_toolbox mit den aufgelisteten Tools customer-orders sehen (Abbildung 5).

Wenn die MCP Toolbox mit der Gemini CLI verbunden ist, können wir nun versuchen, einige Fragen zu stellen, wie zum Beispiel: „ Gib mir die Bestellungen für die Kundin Gwen Sanders.“ Anschließend fordert die Gemini CLI die Berechtigung an, das Tool customer-orders vom Server mcp_toolbox auszuführen (siehe Abbildung 6).

Nach der Bestätigung führt Gemini CLI die Anfrage an die MCP Toolbox aus und erhält als Ergebnis eine JSON-Reaktion, die zur Formatierung der Reaktion verwendet wird (Abbildung 7).

Die Reaktion von Gemini CLI wird berichten, dass Gwen Sanders lediglich eine Bestellung über zwei Produkte zum Gesamtpreis von 132 Euro aufgegeben hat.

MCP Toolbox SDKs

Die Google MCP Toolbox bietet außerdem ein SDK an, um alle Funktionen eines in Go, Python und Javascript geschriebenen Programms abzurufen.

Das Python SDK ist beispielsweise auf GitHub unter folgender Seite verfügbar: https://github.com/googleapis/mcp-toolbox-sdk-python.

Wir müssen einen einfachen Agenten erstellen, der mit der MCP Toolbox verbunden werden kann. Wir müssen die folgenden Pakete installieren:

Und erstellen Sie ein neues Agentenprojekt mit folgendem Befehl:

Dadurch wird ein neues Verzeichnis namens my_agent mit einer Datei agent.py erstellt.

Aktualisieren Sie my_agent/agent.py mit dem folgenden Inhalt, um eine Verbindung zu Toolbox herzustellen:

Erstellen Sie eine .env-Datei mit Ihrem Google API-Schlüssel:

Schließlich können wir den Agenten ausführen und die Ergebnisse beobachten. Um den Agenten auszuführen, können Sie folgenden Befehl ausführen:

Alternativ können Sie ihn über eine Webschnittstelle bereitstellen:

In beiden Tickets können Sie mit der MCP Toolbox über eine Q&A-Schnittstelle interagieren. Sie können zum Beispiel die vorherige Frage stellen: Geben Sie mir die Bestellungen der Kundin Gwen Sanders.

Weitere Informationen zu den verschiedenen SDKs finden Sie auf dieser Dokumentationsseite.

Fazit

In diesem Artikel haben wir die Elasticsearch-Integration für die Google MCP Toolbox for Databases demonstriert. Mithilfe einer einfachen YAML-Konfigurationsdatei können wir eine Reihe von Tools definieren, die Fragen in natürlicher Sprache mithilfe der ES|QL-Sprache in Elasticsearch-Abfragen übersetzen.

Wir haben gezeigt, wie man mit dem Datensatz kibana_sample_data_ecommerce interagiert, der Bestellungen von einer Website enthält. Mit dieser Konfigurationsdatei können wir den MCP Toolbox-Server einfach ausführen und uns von jedem MCP-Client aus mit ihm verbinden.

Abschließend haben wir gezeigt, wie man die Gemini-CLI als Client nutzt, um sich mit der MCP Toolbox for Databases zu verbinden und die in Elasticsearch gespeicherten E-Commerce-Daten abzufragen. Wir haben eine Abfrage in natürlicher Sprache ausgeführt, um Informationen über Bestellungen für eine:n bestimmte:n, namentlich identifizierte:n Kund:in abzurufen.

Während das MCP-Ökosystem weiter wächst, schafft dieses Muster – leichte Werkzeugdefinitionen mit sicherer, produktionsreifer Infrastruktur – neue Möglichkeiten, immer leistungsfähigere, datenbewusste Agenten mit minimalem Aufwand zu entwickeln. Ob Sie nun lokal mit den Elastic-Beispieldatensätzen experimentieren oder Suchfunktionen in eine größere Anwendung integrieren, die MCP Toolbox bietet eine zuverlässige, erweiterbare Grundlage für die Interaktion mit Ihren Elasticsearch-Daten unter Verwendung natürlicher Sprache.

Weitere Informationen zur Entwicklung agentischer KI-Anwendungen finden Sie im Artikel Building AI Agentic Workflows with Elasticsearch von Anish Mathur und Dana Juratoni.

Weitere Informationen über die Google MCP Toolbox finden Sie unter https://googleapis.github.io/genai-toolbox/getting-started/introduction/.

Hier ist ein Überblick über die Features in Elasticsearch 9.2, die Ihre Datenanalyse-Workflows mit ES|QL verändern werden.

Revolutionierung der Datenkorrelation: Eine intelligentere, schnellere und flexiblere Lookup-Verknüpfung

Der Befehl LOOKUP JOIN in ES|QL hat in Elasticsearch 9.2 eine bedeutende Transformation durchlaufen und ist deutlich effizienter und vielseitiger geworden. LOOKUP JOIN kombiniert Daten aus Ihrer ES|QL-Abfrageergebnistabelle mit übereinstimmenden Einträgen aus einem angegebenen Lookup-Modus-Index. Es fügt Felder aus dem Lookup-Index als neue Spalten zu Ihrer Ergebnistabelle hinzu, basierend auf übereinstimmenden Werten im Join-Feld. Zuvor war die Verknüpfung von Daten auf ein einziges Feld und einfache Gleichheit beschränkt. Das ist Geschichte! Dank dieser Erweiterungen können Sie komplexe Datenkorrelationsszenarien mühelos bewältigen.

Zu den wichtigsten Verbesserungen von Lookup Join gehören:

• Verknüpfungen mit mehreren Feldern: Einfaches Verknüpfen mehrerer Felder. So verbinden Sie beispielsweise application_logs mit service_registry anhand von service_name, environment und version:

• Freischalten komplexer Join-Prädikate mit Ausdrücken (technische Vorschau):

Sie sind nicht mehr auf einfache Gleichheit beschränkt. LOOKUP JOIN ermöglicht es Ihnen nun, mehrere Kriterien für die Korrelation anzugeben und eine Reihe von binären Operatoren einzubeziehen, darunter ==, !=, <, >, <= und >=. Dies bedeutet, dass Sie hochgradig nuancierte Join-Bedingungen erstellen können, die es Ihnen ermöglichen, viel anspruchsvollere Fragen an Ihre Daten zu stellen.

Beispiel 1: Ermittlung von Anwendungsmetriken mit SLA-Schwellenwert pro Dienst

Beispiel 2: Diese Abfrage berechnet den fälligen Betrag auf Grundlage regionaler Preisrichtlinien, die sich im Laufe der Zeit ändern. Es verknüpft drei Datensätze basierend auf komplexen Datumsbereichs- und Gleichheitsbedingungen, um eine endgültige due_amount zu berechnen. Der zweite Lookup-Join verwendet das Feld measurement_date aus dem Index meter_readings und das Feld region_id aus dem Index customers, um mit dem Index pricing_policies verknüpft zu werden und die richtige Preispolitik für die jeweiligen region und measurement_date zu finden.

• Enorme Leistungsgewinne bei gefilterten Joins:

Wir haben die Leistung für „erweiterte Verknüpfungen” verbessert, die anhand von Lookup-Tabellenbedingungen gefiltert werden. Erweiterte Verknüpfungen führen zu mehreren Übereinstimmungen pro Eingabezeile, wodurch große Zwischenergebnismengen entstehen können. Dies wird noch schlimmer, wenn viele dieser Zeilen durch einen nachfolgenden Filter verworfen werden. In 9.2 optimieren wir diese Verknüpfungen, indem wir unnötige Zeilen herausfiltern, wenn ein Filter auf Suchdaten angewendet wird. Dadurch wird die Verarbeitung von Zeilen vermieden, die verworfen würden. In einigen Szenarien können diese Joins bis zu 1000-mal schneller sein!

Diese Optimierung ist entscheidend bei der Verarbeitung von „expandierenden Joins“, bei denen eine Suche anfänglich viele potenzielle Übereinstimmungen erzeugen kann. Durch intelligentes Herunterdrücken von Filtern werden nur die relevanten Daten verarbeitet, was die Ausführungszeit von Abfragen drastisch verkürzt und die Echtzeitanalyse großer Datensätze ermöglicht. Das bedeutet, dass Sie Ihre Einblicke viel schneller erhalten, selbst bei sehr großen oder komplexen Join-Operationen.

Kompatibilität mit der clusterübergreifenden Suche (CCS) Lookup Join:

Als Lookup Join in den Versionen 8.19 und 9.1 allgemein verfügbar wurde, fehlte die Unterstützung für die clusterübergreifende Suche (CCS). Für Organisationen, die in mehreren Clustern arbeiten, lässt sich LOOKUP JOIN in 9.2 jetzt nahtlos in CCS integrieren. Platzieren Sie einfach Ihren Lookup-Index auf allen Remote-Clustern, mit denen Sie einen Join durchführen möchten, und ES|QL nutzt diese Remote-Lookup-Indizes automatisch, um den Join mit Ihren Remote-Daten durchzuführen. Dies vereinfacht die verteilte Datenanalyse und gewährleistet eine konsistente Anreicherung Ihres gesamten Elasticsearch-Deployments.

Diese Verbesserungen ermöglichen es Ihnen, vielfältige Datensätze mit beispielloser Präzision, Geschwindigkeit und Leichtigkeit zu korrelieren und so tiefere, umsetzbare Einblicke ohne komplexe Workarounds oder Vorverarbeitungsschritte zu gewinnen.

Reichern Sie Ihre Daten mühelos an: Kibana Discover UX für Lookup-Indizes

Die Datenanreicherung sollte unkompliziert sein und keine Hürde darstellen. Wir haben in Kibana Discover eine fantastische neue Nutzererfahrung für die Erstellung und Verwaltung von Lookup-Indizes eingeführt.

Intuitiver Workflow: Die umfassende Autovervollständigung von Discover führt Sie durch den Prozess, schlägt Suchindizes und Join-Felder im ES|QL-Editor vor und macht es unglaublich einfach, Ihre hochgeladenen Daten mit vorhandenen Indizes zu verbinden. Geben Sie den Namen eines Lookup-Index ein, der nicht existiert, und erhalten Sie mit einem Klick direkten Zugriff auf den Lookup-Editor, um den Index zu erstellen. Geben Sie den Namen eines bestehenden Nachschlageindex ein, und wir schlagen eine Option zur Bearbeitung vor:

Inline-Management (CRUD): Halten Sie Ihre Datensätze mit Inline-Bearbeitungsfunktionen (Erstellen, Lesen, Aktualisieren, Löschen) und Liniendiagramm direkt in Discover auf dem neuesten Stand.

Müheloses Hochladen von Dateien: Sie können jetzt Dateien wie CSVs direkt in Discover hochladen und sofort in Ihren LOOKUP JOIN verwenden. Keine Kontextwechsel mehr durch das Springen zwischen verschiedenen Bereichen von Kibana!

Egal, ob Sie Nutzer-IDs mit Namen mappen, Geschäfts-Metadaten hinzufügen oder statische Referenzdateien verknüpfen – dieses Feature demokratisiert die Datenanreicherung und versorgt die Joins direkt in den Händen aller Nutzer:innen mit Energie – schnell, einfach und alles an einem Ort.

Bewahren Sie Ihren Kontext: Einführung von INLINE STATS (technische Vorschau)

Die Aggregation von Daten ist entscheidend, aber manchmal müssen Sie die Aggregate neben Ihren ursprünglichen Daten sehen. Wir freuen uns, INLINE STATS als Tech Preview-Feature vorzustellen.

Im Gegensatz zum Befehl STATS, der Ihre Eingabefelder durch aggregierte Ausgaben ersetzt, behält INLINE STATS alle Ihre ursprünglichen Eingabefelder bei und fügt lediglich die neuen aggregierten Felder hinzu. Dies ermöglicht es Ihnen, nach der Aggregation weitere Operationen auf Ihren ursprünglichen Eingabefeldern durchzuführen und bietet so einen kontinuierlicheren und flexibleren Analyse-Workflow.

Um beispielsweise die durchschnittliche Flugdistanz unter Beibehaltung der einzelnen Flugreihen zu berechnen:

Bei dieser Abfrage wird jeder Zeile avgDist mit der entsprechenden Dest(ination) hinzugefügt, nach der wir gruppiert haben. Da wir dann immer noch die Spalten mit den Fluginformationen haben, können wir die Ergebnisse auf die Flüge mit einer Entfernung, die größer als der Durchschnitt ist, filtern.

Zeitreihenunterstützung in ES|QL (technische Vorschau)

Elasticsearch verwendet Zeitreihen-Datenströme zum Speichern von Metriken. Wir fügen Unterstützung für Zeitreihenaggregationen in ES|QL über den TS Source-Befehl hinzu. Dies ist in Elastic Cloud Serverless und 9.2 Basic als Tech-Vorschau verfügbar.

Die Zeitreihenanalyse basiert größtenteils auf Aggregationsabfragen, die Metrikwerte in Zeit-Buckets zusammenfassen, unterteilt durch eine oder mehrere Filterdimensionen. Die meisten Aggregationsabfragen basieren auf einer zweistufigen Verarbeitung: (a) eine innere Aggregationsfunktion, die Werte pro Zeitreihe zusammenfasst, und (b) eine äußere Aggregationsfunktion, die die Ergebnisse von (a) über Zeitreihen hinweg kombiniert.

Der Quellbefehl TS bietet in Kombination mit STATS eine prägnante und dennoch effektive Möglichkeit, solche Abfragen über Zeitreihen auszudrücken. Betrachten wir konkreter das folgende Beispiel zur Berechnung der Gesamtanforderungsrate pro Host und Stunde:

In diesem Fall wird die Aggregationsfunktion RATE zuerst pro Zeitreihe und Stunde ausgewertet. Die erzeugten Teilaggregate werden dann mit SUM kombiniert, um die endgültigen Aggregatwerte pro Host und Stunde zu berechnen.

Eine Liste der verfügbaren Funktionen zur Aggregation von Zeitreihen finden Sie hier. Zählerrate wird jetzt unterstützt, die wohl wichtigste Aggregationsfunktion für die Verarbeitung von Zählern.

Der Quellbefehl TS ist so konzipiert, dass er mit STATS kombiniert werden kann, wobei die Ausführung so abgestimmt ist, dass sie Zeitreihenaggregationen effizient unterstützt. Zum Beispiel werden die Daten sortiert, bevor sie in die STATS gelangen. Verarbeitungsbefehle, die die Zeitreihendaten oder ihre Reihenfolge anreichern oder verändern können, wie FORK oder INLINE STATS, sind derzeit zwischen TS und STATS nicht zulässig. Diese Beschränkung könnte in Zukunft aufgehoben werden.

Die tabellarische Ausgabe von STATS kann mit einem beliebigen Befehl weiterverarbeitet werden. Zum Beispiel berechnet die folgende Abfrage das Verhältnis des durchschnittlichen cpu_usage pro Host und Stunde bis zum maximalen Wert pro Host:

Zeitreihendaten werden auf unserer zugrunde liegenden spaltenförmigen Speicher-Engine gespeichert, die von Lucene-Doc-Werten betrieben wird. Der TS-Befehl fügt die vektorisierte Abfrageausführung über die ES|QL-Compute-Engine hinzu. Die Abfrageleistung wird im Vergleich zu äquivalenten DSL-Abfragen oft um mehr als eine Größenordnung verbessert und ist mit etablierten, metrikspezifischen Systemen vergleichbar. Wir werden in Zukunft eine detaillierte Architektur- und Leistungsanalyse bereitstellen, also bleiben Sie gespannt.

Erweiterung Ihres Toolkits: Neue ES|QL-Funktionen

Zur weiteren Verbesserung der Nützlichkeit und Vielseitigkeit von ES|QL haben wir eine Reihe neuer Funktionen hinzugefügt:

Zeichenfolgenmanipulation: CONTAINS, MV_CONTAINS, URL_ENCODE, URL_ENCODE_COMPONENT, URL_DECODE für eine robustere Text- und URL-Verarbeitung.

Zeitreihen und Geodaten: TBUCKET für flexible Buckets, TO_DENSE_VECTOR für Vektoroperationen und ein umfassender Satz von Geodatenfunktionen wie ST_GEOHASH, ST_GEOTILE, ST_GEOHEX, TO_GEOHASH, TO_GEOTILE, TO_GEOHEX für fortgeschrittene ortsbezogene Analysen.

Datumsformatierung: DAY_NAME, MONTH_NAME für besser lesbare Datumsdarstellungen.

Diese Funktionen bieten Ihnen eine umfangreichere Auswahl an Werkzeugen, um Ihre Daten direkt innerhalb von ES|QL zu bearbeiten und zu analysieren.

Unter der Haube: Mehr Leistung und Effizienz

Neben den hervorgehobenen Features bietet Elasticsearch 9.2 zahlreiche Leistungsoptimierungen für ES|QL. Wir haben RLIKE (LIST) mit Pushdown beschleunigt, wenn die Funktion mehrere ähnliche RLIKE-Abfragen in einem Ticket ersetzt. Mit RLIKE (LIST) können wir diese Abfragen zu einem einzigen Automaten zusammenführen und einen Automaten anstelle mehrerer anwenden. Wir bieten außerdem ein schnelleres Laden von Schlüsselwortfeldern durch Indexsortierungen und allgemeine Abfrageoptimierungen – diese Verbesserungen gewährleisten, dass Ihre ES|QL-Abfragen effizienter als je zuvor ausgeführt werden.

Legen Sie noch heute los!

Elasticsearch 9.2 ist ein bedeutender Fortschritt für ES|QL und bringt beispiellose Leistung und Flexibilität in Ihre Datenanalyse-Workflows. Wir ermutigen Sie, diese neuen Features zu erkunden und den Unterschied selbst zu erleben.

Eine vollständige Liste aller Änderungen und Verbesserungen in Elasticsearch 9.2 finden Sie in den offiziellen Versionshinweisen. Viel Spaß beim Abfragen!

In diesem Blogbeitrag werden wir die Entwicklererfahrung des ES|QL-Editors in Elasticsearch 9.1 untersuchen, indem wir sie mit PPL im Event Analyzer (kurz PPL) in OpenSearch 3.2 vergleichen.

Die Unterschiede werden schnell deutlich: Der ES|QL Editor bietet intelligente Autovervollständigung, kontextbezogene Hilfe, empfohlene Abfragen und clusterübergreifende Abfrageunterstützung, die nicht nur Anfängern, sondern auch Experten gleichermaßen zugutekommen. Das durchdachte Design für die ES|QL-Erstellung zeigt sich auch in der integrierten Abfrageprüfung und der ganzheitlichen Integration durch Kibana-Workflows, beispielsweise mit den zuletzt verwendeten Abfragen.

PPL hingegen bietet keine vergleichbare Unterstützung für Autovervollständigung, kontextbezogene Hilfestellungen und verteilte Abfragen, was zu einer steileren Lernkurve und mehr Versuch und Irrtum führt.

ES|QL einfacher zu erlernen und anzuwenden

Der Einstieg in eine neue Abfragesprache kann oft überwältigend sein. Der direkt in Kibana Discover integrierte ES|QL - Editor wurde entwickelt, um diesen Prozess zu vereinfachen, indem er nicht nur die Erstellung und das Debuggen von Abfragen unterstützt, sondern auch beschleunigt, wie schnell Sie sich mit der Sprache vertraut machen und sich damit wohlfühlen. Da der Editor dazu beiträgt, Reibungsverluste bei alltäglichen Aufgaben zu reduzieren, können Sie Ihren Fokus von Syntax und Versuch-und-Irrtum-Prinzip auf die Lösungsfindung verlagern. Mehr über diese Prinzipien und wie wir sie in den Editor integriert haben, können Sie hier lesen.

Diese Editor-Oberfläche ist nicht auf Discover beschränkt; es handelt sich um ein wiederverwendbares Code-Modul, dessen Integration in andere Teile von Kibana wir gerade vorantreiben, wie zum Beispiel Dashboards, Kibana-Alerts und Kibana-Maps.

Intelligente Autovervollständigung: Beschleunigt die Erstellung Ihrer Suchanfragen

Die Autovervollständigung im ES|QL Editor ist umfassend und bietet Vorschläge für kompatible Funktionen, Argumente, Literale und sogar verschachtelte Funktionen – eine Fähigkeit, die in PPL deutlich fehlt. Tatsächlich wurde es von Grund auf neu aufgebaut, wie hier beschrieben.

Die Validierung läuft während der Eingabe durch den Benutzer, wie hier beschrieben, und schlägt Felder vor sowie benachrichtigt den Benutzer über Fehler. Dies reduziert die mentale Belastung der Benutzer und hilft, Fehler frühzeitig im Abfrageerstellungsprozess zu vermeiden.

Beispiel: In dieser Verschachtelung werden Felder und kompatible Funktionen vorgeschlagen:

Etwas, das PPL nicht unterstützt:

Selbst wenn eine intelligente Autovervollständigung Sie durch kompatible Funktionen, Argumente und verschachtelte Funktionen führt, möchten Sie vielleicht trotzdem ein tieferes Verständnis der verfügbaren Optionen. Genau hier erweist sich die kontextbezogene Hilfe des ES|QL Editors als unschätzbar wertvoll, da sie sofortige Unterstützung direkt im Editor bietet, um Ihre Abfrageentwicklung zu verdeutlichen und zu verbessern.

Kontextbezogene Hilfe direkt zur Hand

Zusätzliche Informationen zu einem durch die Autovervollständigung generierten Befehl erhalten Sie mit einem Klick Strg+Leertaste. Es erscheint sofort ein Fenster mit Details zu der betreffenden Funktion, dem Argument oder dem Feld. Diese unkomplizierte Interaktion hält die Entwickler im Arbeitsfluss und bietet ihnen bedarfsgerechte Hilfestellung, ohne dass sie den Editor verlassen oder externe Dokumentationen durchsuchen müssen. Dadurch wird der Zeitaufwand für Syntaxprüfungen reduziert und häufige Fehler werden vermieden, bevor sie überhaupt auftreten.

So sieht es in der Praxis aus:

PPL bietet diese Art von integrierter Anleitung nicht, sodass die Benutzer auf externe Dokumente oder das Ausprobieren angewiesen sind. Dieses Fehlen ist nicht nur ein fehlendes Merkmal; es verdeutlicht eine umfassendere Diskrepanz in der Designphilosophie. ES|QL legt Wert auf ein durchdachtes, kontextbezogenes Benutzererlebnis, das sich an die Daten und Arbeitsabläufe des Benutzers anpasst. Dieser Unterschied wird umso deutlicher, je komplexer die Abfragen werden, wodurch der ES|QL Editor eine effizientere und zuverlässigere Umgebung sowohl für Lernzwecke als auch für den Produktiveinsatz darstellt.

Empfohlene Abfragen, die den Datenkontext berücksichtigen

Der ES|QL-Editor bietet empfohlene Abfragen, die automatisch auf die Daten, mit denen Sie arbeiten, wie z. B. Protokolle, zugeschnitten sind. Statt eines leeren Editors werden die relevantesten Ausgangspunkte für gängige Anwendungsfälle angezeigt. Durch die Auswahl einer empfohlenen Abfrage wird eine kanonische Abfrage generiert, die sofort verwendbar ist und bei Bedarf weiter verfeinert werden kann. Dieser Ansatz beschleunigt die Abfrageentwicklung, insbesondere für neue Benutzer, die die vollständige Syntax möglicherweise noch nicht kennen.

Hier ist ein Beispiel, bei dem ein Benutzer die Abfrage „Änderungspunkt erkennen“ auswählt:

Vergleichen Sie das mit der PPL-Erfahrung:

Im Gegensatz dazu bietet PPL hier nur eine einfache Autovervollständigung, sodass man Abfragen ohne Kontext oder Struktur selbst zusammensetzen muss. Dieser Mangel an Anleitung kann zu Frustration und dem Vorgehen nach dem Prinzip „Versuch und Irrtum“ führen. Mit den datenbasierten empfohlenen Abfragen des ES|QL-Editors können Sie vermeiden, bei Routineaufgaben von Grund auf neu zu beginnen oder sich Syntax einzuprägen. Der Editor reduziert die kognitive Belastung, hilft, Fehler zu vermeiden, und ermöglicht es Ihnen, sich auf die Problemlösung und übergeordnete Ziele wie die Durchführung clusterübergreifender Suchen zu konzentrieren, anstatt sich mit der Formulierung von Abfragen auseinanderzusetzen.

Intuitive clusterübergreifende Abfragen

Die Autovervollständigung des ES|QL-Editors ist auch bei der Arbeit mit mehreren Remote-Clustern mit CCS weiterhin überlegen. Hier ist der Grund:

Der ES|QL-Editor bietet nahtlose Autovervollständigung auch clusterübergreifend.

Die Autovervollständigung im ES|QL-Editor unterstützt nicht nur Clusternamen, sondern auch lokale und Remote-Indizes. Wie hier beschrieben, funktioniert dies dank einer Koordinatorknotenarchitektur, die dabei hilft, den Abfrageplan zu validieren und zu generieren, der an die lokalen Knoten gesendet wird, die Abfrage auszuführen und die Ergebnisse zu aggregieren, bevor sie an den Benutzer zurückgesendet werden. Ohne Eingabe des vollständigen Namens des Remote-Clusters startet die Eingabe von „:“ den Autovervollständigungsprozess für den Remote-Index. Und Sie sind nicht auf das Präfix beschränkt.

Dadurch wird es einfach, verteilte Datensätze zu finden und abzufragen, ohne sich Namenskonventionen merken oder den Kontext wechseln zu müssen.

Hier ist ein Beispiel, bei dem der Benutzer einfach „clu:g“ eingibt, um einen Remote-Index zu finden:

Im krassen Gegensatz dazu bietet die PPL nur eine grundlegende Vervollständigung für lokale Indizes, wobei die Vorschläge auf Präfixübereinstimmungen beschränkt sind. Remote-Cluster müssen manuell eingegeben werden, was die Fehlerwahrscheinlichkeit erhöht und die Abfrageerstellung verlangsamt.

PPL bietet Vervollständigung nur für lokale Indizes und die Vorschläge sind auf das Präfix beschränkt:

ES|QL geht noch einen Schritt weiter, indem es Ausschlüsse direkt über ein negatives Vorzeichen ermöglicht und Ihnen so eine detaillierte Kontrolle darüber gibt, welche Cluster in Ihre Untersuchung einbezogen werden. Diese Funktionalität ist besonders wertvoll bei der Arbeit mit hybriden Umgebungen, in denen Sie bei clusterübergreifenden Untersuchungen möglicherweise bestimmte Datensätze ein- oder ausschließen möchten.

Diese Verbesserungen spiegeln den umfassenderen Fokus von Elasticsearch auf die Reduzierung von Reibungsverlusten bei der clusterübergreifenden Suche wider. Durch die Vereinfachung der Erstellung und Verwaltung verteilter Abfragen ermöglicht der ES|QL Editor Analysten und Entwicklern, sich auf Erkenntnisse anstatt auf die Syntax zu konzentrieren, während PPL diese Last eher dem Benutzer überlässt. Und genau wie der ES|QL-Editor die Erstellung clusterübergreifender Abfragen vereinfacht, bietet er auch Werkzeuge zur Überprüfung der Ausführung dieser Abfragen und gewährleistet so Transparenz und Leistungsüberwachung über mehrere Cluster hinweg.

Analyse der Details der clusterübergreifenden Suche mithilfe des Inspektionstools

Das Inspektionstool, das über den ES|QL-Editor zugänglich ist, dient dazu, Metadaten mit expliziten Informationen über die Abfrageausführung in allen Clustern bereitzustellen. Diese Funktionalität ist in Kibana Discover aktiviert und direkt im Query Inspector zugänglich. Dadurch können Sie den Suchfortschritt und Details analysieren, was insbesondere für die Cross-Cluster Search (CCS) von entscheidender Bedeutung ist. Diese Funktion hilft Ihnen, den Suchfortschritt zu überwachen und zu verstehen, wie Abfragen in verteilten Datensätzen abschneiden.

Diese detaillierte Transparenz der Abfrageausführung, insbesondere bei komplexen verteilten Suchvorgängen, ermöglicht es Ihnen, optimale Leistung und Fehlerbehebung zu gewährleisten.

Über das Verständnis der Funktionsweise einzelner Abfragen hinaus verbessert der ES|QL Editor die Benutzererfahrung zusätzlich, indem er wesentliche Funktionalitäten tief in die gesamte Kibana-Plattform einbettet und so einen nahtlosen und unterbrechungsfreien Arbeitsablauf fördert.

Einheitliche Abfrageerfahrung mit ES|QL und Kibana

Eine der häufigsten Ursachen für Reibungsverluste bei abfragegesteuerter Analyse ist der Kontextwechsel. Oftmals müssen Sie sich an bereits formulierte Anfragen erinnern. Jede Unterbrechung stört die Konzentration und verlangsamt die Ermittlungen. Der ES|QL-Editor löst dieses Problem durch die Integration des Abfrageverlaufs in Kibana.

Aktuelle Suchanfragen

Die Funktion „Letzte Abfragen“ im ES|QL Editor hilft Ihnen, im Arbeitsfluss zu bleiben, indem sie frühere Arbeiten sofort zugänglich macht. Im ES|QL-Editor von Discover können Sie Ihre letzten 20 Abfragen anzeigen, erneut ausführen und mit einem Stern markieren. So ist sichergestellt, dass häufig verwendete oder komplexe Abfragen nur einen Klick entfernt sind. Diese gespeicherten Abfragen werden auch in Kibana übernommen und in Dashboards, Visualisierungen, Benachrichtigungen und Karten integriert, sodass Sie Ihren aktuellen Bildschirm nicht verlassen oder Befehle von Grund auf neu eingeben müssen. Dadurch werden sich wiederholende Arbeiten reduziert, die Ermittlungen beschleunigt und das Fehlerrisiko minimiert.

Ein Benutzer kann beispielsweise die zuletzt verwendeten Abfragen im ES|QL-Editor in Discover nutzen (und diese mit einem Stern markieren):

Die neuesten Suchanfragen sind im Dashboard integriert:

PPL bietet keine vergleichbare Funktion, sodass Benutzer auf manuelles Kopieren und Einfügen oder externe Notizen angewiesen sind, um Abfragen wiederzuverwenden. Der Unterschied liegt nicht nur in der Bequemlichkeit; er spiegelt die Strategie von Elastic wider, ES|QL als eine wirklich integrierte Sprache innerhalb des Kibana-Ökosystems aufzubauen. Mit Funktionen wie „Letzte Abfragen“ optimiert der ES|QL Editor nicht nur die täglichen Arbeitsabläufe, sondern legt auch den Grundstein für fortgeschrittenere Funktionen, die sich derzeit in der technischen Vorschau befinden, und gewährleistet so eine kontinuierliche Weiterentwicklung des Benutzererlebnisses.

Fazit

ES|QL ist mehr als nur eine Syntax; es spiegelt die Strategie von Elastic wider, die Art und Weise zu verbessern, wie Benutzer Daten suchen, erkunden und analysieren. Mit intelligenter Autovervollständigung, kontextbezogenen empfohlenen Abfragen, Hilfestellungen im Editor und Tools wie Inspect beschleunigt der ES|QL Editor das Lernen, reduziert Fehler und vereinfacht komplexe Arbeitsabläufe wie die Clusterübergreifende Analyse. Die Integration in Kibana ermöglicht die nahtlose Verbindung von Abfragen mit Dashboards, Warnmeldungen und Visualisierungen für einen unterbrechungsfreien Workflow.

Zusammenfassend lässt sich sagen, dass ES|QL nicht einfach nur eine weitere Pipe-Sprache ist; es ist eine durchdacht entwickelte Abfrage-Engine in Verbindung mit einer intuitiven Benutzeroberfläche, die die Art und Weise, wie Sie mit Ihren Daten interagieren, grundlegend neu definiert und ein integriertes, intelligentes und sich ständig weiterentwickelndes Erlebnis bietet, das sich deutlich von der oft sequenziellen und weniger geführten Natur von OpenSearch PPL abhebt.

Was kommt als Nächstes?

Dieser Blog kratzt nur an der Oberfläche von ES|QL. Zukünftige Beiträge werden sich eingehender mit Vergleichen mit OpenSearch PPL befassen und Geodaten-, Visualisierungs- und kommende Editorfunktionen wie Controls (bereits in Dashboards verfügbar), Registerkarten zur Erkundung mehrerer Daten, Hintergrundsuche, erweiterte Abfragehistorie und FUSE untersuchen.

Testen Sie ES|QL noch heute!

Sie können ES|QL in vollständig verwalteten Elasticsearch Serverless -Projekten mit einer kostenlosen Testversion ausprobieren. Es ist auch in Versionen ab 8.11 verfügbar, bietet aber das beste Nutzungserlebnis in den Versionen 8.19 und 9.1.

Legen Sie in wenigen Minuten in Ihrer lokalen Umgebung mit einem einzigen Befehl los:

ESQL:

Rubin:

Installation

Das Gem kann über RubyGems installiert werden mit:

Alternativ kann es der Gemfile-Datei eines Projekts hinzugefügt werden:

Verwendung

Sie können entweder eine vollständige Abfrage auf einmal erstellen oder ein Abfrageobjekt mit einem Quellbefehl wie from oder row erstellen und dann ES|QL-Methoden verketten, um darauf aufzubauen.

Das Gem übersetzt den Code in ES|QL für die to_s -Methode, sodass es die ES|QL-Abfrage zurückgibt, wenn sie ausgegeben oder als String gecastet wird:

Sie können ein Abfrageobjekt instanziieren und seinen Anfangszustand verändern, indem Sie die ! -Äquivalente jeder Funktion verwenden:

Das Tool bietet bequeme Möglichkeiten, zusätzliche Schritte an eine ES|QL-Funktion anzuhängen, wie z. B. enrich und sort. Sobald Sie enrich auf einem Elastic::ESQL -Objekt aufgerufen haben, können Sie on und with daran anhängen:

Sie können auch desc, asc, nulls_first und nulls_last an Ihre Abfrage anhängen, nachdem Sie sort verwendet haben:

Es unterstützt auch benutzerdefinierte Zeichenketten, falls Sie die ES|QL-Abfrage selbst schreiben oder eine Funktion nutzen möchten, die noch nicht in die Bibliothek aufgenommen wurde. custom wird die Zeichenketten am Ende der Abfrage zusammenfügen. Die Zeichen werden beim Senden an die Funktion hinzugefügt, ohne dabei Pipe-Zeichen einzufügen. Sie werden durch ein Leerzeichen mit dem Rest der Anfrage verbunden.

Sie können auch custom -Funktionen verketten:

Verwendung des ES|QL Query Builders mit dem Ruby-Client

Sie können den Query Builder direkt mit elasticsearch-ruby und der esql.query API verwenden, indem Sie das Query-Objekt senden:

Sie können es auch mit dem ES|QL-Helper des Elasticsearch Ruby-Clients verwenden. Weitere Informationen finden Sie hier:

Als eigenständiges Werkzeug

Das Gem ist als eigenständiges Werkzeug konzipiert, um ES|QL-Abfragen auf idiomatische Weise zu erstellen. Es hat keine Laufzeitabhängigkeiten; Sie können es mit dem offiziellen Elasticsearch Ruby-Client oder auch eigenständig verwenden.

Die generierte Abfrage kann mit der esql.query API auf jede Art und Weise verwendet werden, wie eine Anwendung mit der Elasticsearch API interagiert (Ruby oder nicht). Sobald eine Abfrage mit elastic-esql erstellt wurde, kann die generierte Zeichenkette als Parameter query im Anfragetext an die API gesendet werden.

Ich habe bereits über die Verwendung von Elasticsearch mit gängigen Ruby-Tools geschrieben. Dieses Gem kann mit allen gängigen Ruby-Tools verwendet werden, um Elasticsearch mit ES|QL abzufragen.

Fazit

Diese Bibliothek befindet sich in aktiver Entwicklung, und die endgültige API ist noch nicht fertiggestellt. Es ist aktuell als technische Vorschauversion veröffentlicht. Sollten Sie Feedback zur aktuellen API oder zur allgemeinen Nutzung haben, zögern Sie bitte nicht , ein neues Issue zu eröffnen. Weitere Informationen zum Ruby ES|QL Query Builder finden Sie in der README-Datei .

Importieren von Geodaten mit Kibana

Die Daten, die wir für die Beispiele im vorherigen Blog verwendet haben, basierten auf Daten, die wir intern für Integrationstests verwenden. Zu Ihrer Bequemlichkeit haben wir es hier in Form einiger CSV-Dateien beigefügt, die Sie problemlos mit Kibana importieren können. Die Daten setzen sich aus Flughäfen, Städten und Stadtgrenzen zusammen. Sie können die Daten hier herunterladen:

• airports.csv

  • Dies beinhaltet die Zusammenführung von drei Datensätzen:

    • Flughäfen (Namen, Standorte und zugehörige Daten) von Natural Earth

    • Stadtstandorte von SimpleMaps

    • Flughafenhöhen aus der globalen Flughafendatenbank

• airport_city_boundaries.csv

  • Dies beinhaltet eine Zusammenführung der oben genannten Flughafen- und Städtenamen mit einer neuen Quelle:

    • Stadtgrenzen aus OpenStreetMap

Wie Sie sich vorstellen können, haben wir einige Zeit damit verbracht, diese Datenquellen in den beiden oben genannten Dateien zusammenzuführen, mit dem Ziel, die Geodatenfunktionen von ES|QL testen zu können. Dies entspricht möglicherweise nicht ganz Ihren spezifischen Datenanforderungen, aber hoffentlich gibt Ihnen dies eine Vorstellung davon, was möglich ist. Insbesondere möchten wir einige interessante Dinge demonstrieren:

• Importieren von Daten mit Geodatenfeldern zusammen mit anderen indexierbaren Daten

• Importieren von geo_point und geo_shape -Daten und deren gemeinsame Verwendung in Abfragen

• Importieren von Daten in zwei Indizes, die über eine räumliche Beziehung verknüpft werden können

• Erstellung einer Ingest-Pipeline zur Erleichterung zukünftiger Importe (über Kibana hinaus)

• Einige Beispiele für Ingest-Prozessoren, wie csv, convert und split

In diesem Blogbeitrag geht es zwar um die Arbeit mit CSV-Daten, aber es ist wichtig zu verstehen, dass es mehrere Möglichkeiten  gibt, Geodaten mit Kibana hinzuzufügen . Innerhalb der Kartenanwendung können Sie durch Trennzeichen getrennte Daten wie CSV, GeoJSON und ESRI ShapeFiles hochladen und auch direkt in der Karte Formen zeichnen. In diesem Blogbeitrag konzentrieren wir uns auf den Import von CSV-Dateien von der Kibana-Startseite.

Import der Flughäfen

Die erste Datei, airports.csv, hat einige interessante Eigenheiten, mit denen wir uns auseinandersetzen müssen. Erstens weisen die Spalten zusätzliche Leerzeichen als Trennzeichen auf, was für CSV-Dateien untypisch ist. Zweitens handelt es sich bei dem Feld type um ein Mehrwertfeld, das wir in separate Felder aufteilen müssen. Schließlich handelt es sich bei einigen Feldern nicht um Zeichenketten, sondern um Felder, die in den richtigen Datentyp konvertiert werden müssen. All dies kann mithilfe der CSV-Importfunktion von Kibana erfolgen.

Beginnen Sie auf der Kibana-Startseite. Es gibt einen Abschnitt mit dem Titel „Erste Schritte durch Hinzufügen von Integrationen“, der einen Link mit der Bezeichnung „Datei hochladen“ enthält:

Klicken Sie auf diesen Link, und Sie gelangen zur Seite „Datei hochladen“. Hier können Sie die airports.csv -Datei per Drag & Drop einfügen. Kibana analysiert die Datei und zeigt Ihnen eine Vorschau der Daten an. Das System hätte das Trennzeichen automatisch als Komma und die erste Zeile als Kopfzeile erkennen sollen. Allerdings wurden vermutlich weder die zusätzlichen Leerzeichen zwischen den Spalten entfernt, noch wurden die Typen der Felder bestimmt, da angenommen wurde, dass alle Felder entweder text oder keyword sind. Das müssen wir beheben.

Klicken Sie auf Override settings und aktivieren Sie das Kontrollkästchen für Should trim fields, und anschließend Apply um die Einstellungen zu schließen. Nun müssen wir die Datentypen der Felder korrigieren. Dies ist auf der nächsten Seite verfügbar, also klicken Sie bitte auf Import.

Wählen Sie zuerst einen Indexnamen aus und anschließend Advanced , um zur Seite für Feldzuordnungen und Datenverarbeitung zu gelangen.

Hier müssen wir sowohl die Feldzuordnungen für den Index als auch die Datenaufnahmepipeline anpassen. Erstens hat Kibana wahrscheinlich das Feld scalerank automatisch als long erkannt, aber die Felder location und city_location fälschlicherweise als keyword interpretiert. Ändern Sie sie in geo_point, sodass die Zuordnungen am Ende etwa so aussehen:

Sie haben hier eine gewisse Flexibilität, aber beachten Sie, dass die Wahl des Typs Einfluss darauf hat, wie das Feld indiziert wird und welche Art von Abfragen möglich ist. Wenn Sie beispielsweise location auf keyword belassen, können Sie keine Geodaten-Suchanfragen darauf durchführen. Wenn Sie elevation als text belassen, können Sie keine numerischen Bereichsabfragen darauf durchführen.

Jetzt ist es an der Zeit, die Datenaufnahmepipeline zu reparieren. Falls Kibana scalerank automatisch als long erkannt hat, wurde außerdem ein Prozessor hinzugefügt, um das Feld in long umzuwandeln. Wir müssen einen ähnlichen Prozessor für das Feld elevation hinzufügen, der es diesmal in double umwandelt. Bearbeiten Sie die Pipeline, um sicherzustellen, dass diese Konvertierung vorhanden ist. Bevor wir dies speichern, möchten wir noch eine weitere Konvertierung durchführen, um das Feld type in mehrere Felder aufzuteilen. Fügen Sie der Pipeline einen split -Prozessor mit folgender Konfiguration hinzu:

Die finale Datenaufnahmepipeline sollte wie folgt aussehen:

Beachten Sie, dass wir keinen Konvertierungsprozessor für die Felder location und city_location hinzugefügt haben. Dies liegt daran, dass der Typ geo_point in der Feldzuordnung das WKT- Format der Daten in diesen Feldern bereits versteht. Der Typ geo_point versteht eine Reihe von Formaten, darunter WKT, GeoJSON und mehr. Wenn wir beispielsweise zwei Spalten in der CSV-Datei für latitude und longitude hätten, hätten wir entweder einen script oder einen set Prozessor hinzufügen müssen, um diese zu einem einzigen geo_point Feld zu kombinieren (z. B. "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Wir sind nun bereit, die Datei zu importieren. Klicken Sie auf Import , und die Daten werden mit den soeben definierten Mappings und der Ingest-Pipeline in den Index importiert. Sollten beim Einlesen der Daten Fehler auftreten, werden diese von Kibana hier gemeldet, sodass Sie entweder die Quelldaten oder die Einlesepipeline bearbeiten und es erneut versuchen können.

Beachten Sie, dass eine neue Aufnahmepipeline erstellt wurde. Dies kann angezeigt werden, indem man im Kibana-Bereich Stack Management auf die Option Ingest pipelines klickt. Hier können Sie die soeben erstellte Pipeline sehen und sie bei Bedarf bearbeiten. Tatsächlich kann der Abschnitt Ingest pipelines zum Erstellen und Testen von Ingest-Pipelines verwendet werden, eine sehr nützliche Funktion, wenn Sie noch komplexere Ingests planen.

Wenn Sie diese Daten sofort erkunden möchten, springen Sie zu den späteren Abschnitten. Wenn Sie aber auch die Stadtgrenzen importieren möchten, lesen Sie weiter.

Importieren der Stadtgrenzen

Die unter airport_city_boundaries.csv verfügbare Datei mit den Stadtgrenzen ist etwas einfacher zu importieren als das vorherige Beispiel. Es enthält ein city_boundary Feld, das eine WKT-Darstellung der Stadtgrenze als POLYGON ist, und ein city_location Feld, das eine geo_point Darstellung des Stadtstandorts ist. Wir können diese Daten auf ähnliche Weise wie die Flughafendaten importieren, allerdings mit einigen Unterschieden:

• Wir mussten die Überschreibungseinstellung Has header row auswählen, da diese nicht automatisch erkannt wurde.

• Wir mussten keine Felder kürzen, da die Daten bereits frei von überflüssigen Leerzeichen waren.

• Wir mussten die Datenaufnahmepipeline nicht bearbeiten, da alle Datentypen entweder Zeichenketten oder räumliche Datentypen waren.

• Wir mussten jedoch die Feldzuordnungen bearbeiten, um das Feld city_boundary auf geo_shape und das Feld city_location auf zu setzen. geo_point

Unsere endgültigen Feldzuordnungen sahen wie folgt aus:

Wie beim Import mit airports.csv zuvor, klicken Sie einfach auf Import , um die Daten in den Index zu importieren. Die Daten werden mit den von uns bearbeiteten Mappings und der von Kibana definierten Ingest-Pipeline importiert.

Erkundung von Geodaten mit Entwicklerwerkzeugen

In Kibana ist es üblich, die indizierten Daten mit dem Befehl „Discover“ zu erkunden. Wenn Sie jedoch Ihre eigene Anwendung mit ES|QL-Abfragen schreiben möchten, könnte es interessanter sein, auf die reine Elasticsearch-API zuzugreifen. Kibana verfügt über eine komfortable Konsole zum Experimentieren mit dem Schreiben von Abfragen. Dies wird als Dev Tools -Konsole bezeichnet und befindet sich in der Kibana-Seitenleiste. Diese Konsole kommuniziert direkt mit dem Elasticsearch-Cluster und kann zum Ausführen von Abfragen, Erstellen von Indizes und vielem mehr verwendet werden.

Versuchen Sie Folgendes:

Dies sollte folgende Ergebnisse liefern:

Distanz

Abkürzung

Name

Ort

Land

Stadt

Elevation

273418.05776847183

SCHINKEN

Hamburg

PUNKT (10.005647830925 53.6320011640866)

Deutschland

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

PUNKT (13.2903090925074 52.5544287044101)

Deutschland

Hohen Neuendorf

38,0

483713.15032266214

OSL

Oslo Gardermoen

Punkt (11.0991032762581 60.1935783171386)

Norwegen

Oslo

208.0

522538.03148094116

BMA

Bromma

PUNKT (17.9456175406145 59.3555902065112)

Schweden

Stockholm

15.0

522538.03148094116

ARN

Arlanda

Punkt (17.9307299016916 59.6511203397372)

Schweden

Stockholm

38,0

624274.8274399083

DUS

Düsseldorf Int'l

PUNKT (6,76494446612174 51,2781820420774)

Deutschland

Düsseldorf

45,0

633388.6966435644

PRG

Ruzyn

PUNKT (14.2674849854076 50.1076511703671)

Tschechien

Prag

381,0

635911.1873311149

AMS

Schiphol

Punkt (4,76437693232812 52,3089323889822)

Niederlande

Hoofddorp

-3.0

670864.137958866

FRA

Frankfurt International

PUNKT (8.57182286907608 50.0506770895207)

Deutschland

Frankfurt

111,0

683239.2529970079

WAW

Okecie Int'l

Punkt (20.9727263383587 52.171026749259)

Polen

Piaseczno

111,0

Visualisierung von Geodaten mit Kibana Maps

Kibana Maps ist ein leistungsstarkes Werkzeug zur Visualisierung von Geodaten. Es kann verwendet werden, um Karten mit mehreren Ebenen zu erstellen, wobei jede Ebene einen anderen Datensatz darstellt. Die Daten können auf verschiedene Weise gefiltert, aggregiert und formatiert werden. In diesem Abschnitt zeigen wir Ihnen, wie Sie in Kibana Maps eine Karte mit den Daten erstellen, die wir im vorherigen Abschnitt importiert haben.

Navigieren Sie im Kibana-Menü zu Analytics->Maps , um eine neue Kartenansicht zu öffnen. Klicken Sie auf Add Layer und wählen Sie Documents aus, wählen Sie die Datenansicht airports und bearbeiten Sie dann den Ebenenstil, um die Markierungen mithilfe des Feldes elevation einzufärben, damit wir leicht erkennen können, wie hoch jeder Flughafen liegt.

Klicken Sie auf „Änderungen beibehalten“, um die Karte zu speichern:

Fügen Sie nun eine zweite Ebene hinzu und wählen Sie diesmal die Datenansicht airport_city_boundaries aus. Dieses Mal verwenden wir das Feld city_boundary , um die Ebene zu gestalten, und stellen die Füllfarbe auf ein helles Blau ein. Dadurch werden die Stadtgrenzen auf der Karte angezeigt. Achten Sie darauf, die Ebenen neu anzuordnen, damit die Flughafenmarkierungen ganz oben liegen.

Räumliche Verknüpfungen

ES|QL unterstützt keine JOIN -Befehle, aber mit dem ENRICH -Befehl lässt sich ein Sonderfall eines Joins realisieren. Dieser Befehl funktioniert ähnlich wie ein „Left Join“ in SQL und ermöglicht es Ihnen, Ergebnisse aus einem Index mit Daten aus einem anderen Index anzureichern, basierend auf einer räumlichen Beziehung zwischen den beiden Datensätzen.

Nehmen wir beispielsweise an, wir reichern die Ergebnisse einer Tabelle mit Flughäfen um zusätzliche Informationen über die jeweilige Stadt an, indem wir die Stadtgrenze ermitteln, die den Flughafenstandort enthält, und führen dann einige statistische Auswertungen der Ergebnisse durch:

Wenn Sie diese Abfrage ausführen, ohne vorher den Anreicherungsindex vorzubereiten, erhalten Sie eine Fehlermeldung wie:

Dies liegt daran, dass ES|QL, wie bereits erwähnt, keine echten JOIN -Befehle unterstützt. Ein wichtiger Grund dafür ist, dass Elasticsearch ein verteiltes System ist und Joins aufwändige Operationen sind, die schwer zu skalieren sind. Der Befehl ENRICH kann jedoch sehr effizient sein, da er speziell vorbereitete Anreicherungsindizes nutzt, die im gesamten Cluster dupliziert werden, wodurch lokale Joins auf jedem Knoten durchgeführt werden können.

Um dies besser zu verstehen, konzentrieren wir uns auf den Befehl ENRICH in der obigen Abfrage:

Dieser Befehl weist Elasticsearch an, die aus dem Index airports abgerufenen Ergebnisse anzureichern und einen Join intersects zwischen dem Feld city_location des ursprünglichen Index und dem Feld city_boundary des Index airport_city_boundaries durchzuführen, den wir bereits in einigen Beispielen verwendet haben. Einige dieser Informationen sind in dieser Abfrage jedoch nicht klar ersichtlich. Was wir sehen, ist der Name einer Anreicherungsrichtlinie city_boundaries, und die fehlenden Informationen sind in dieser Richtliniendefinition enthalten.

Hier sehen wir, dass eine geo_match -Abfrage durchgeführt wird (intersects ist der Standardwert), das Feld, mit dem abgeglichen werden soll, ist city_boundary, und die enrich_fields sind die Felder, die wir dem Originaldokument hinzufügen möchten. Eines dieser Felder, nämlich region wurde tatsächlich als Gruppierungsschlüssel für den Befehl STATS verwendet, was ohne diese 'left join'-Funktion nicht möglich gewesen wäre. Weitere Informationen zu Anreicherungsrichtlinien finden Sie in der Anreicherungsdokumentation.

Die Anreicherungsindizes und -richtlinien in Elasticsearch wurden ursprünglich für die Anreicherung von Daten während der Indexierung entwickelt, wobei Daten aus einem anderen vorbereiteten Anreicherungsindex verwendet wurden. In ES|QL hingegen funktioniert der Befehl ENRICH zur Abfragezeit und erfordert keine Verwendung von Ingest-Pipelines. Dadurch ähnelt es im Prinzip einem SQL LEFT JOIN, nur dass man nicht beliebige zwei Indizes verknüpfen kann, sondern nur einen normalen Index auf der linken Seite mit einem speziell vorbereiteten Anreicherungsindex auf der rechten Seite.

In beiden Fällen, ob für Ingest-Pipelines oder die Verwendung in ES|QL, müssen einige vorbereitende Schritte durchgeführt werden, um den Anreicherungsindex und die Richtlinie einzurichten. Wir haben den Index airport_city_boundaries bereits oben importiert, dieser kann jedoch nicht direkt als Anreicherungsindex im Befehl ENRICH verwendet werden. Zunächst müssen wir zwei Schritte durchführen:

• Erstellen Sie die oben beschriebene Anreicherungsrichtlinie, um den Quellindex, das Feld im Quellindex, mit dem abgeglichen werden soll, und die Felder, die nach dem Abgleich zurückgegeben werden sollen, zu definieren.

• Führen Sie diese Richtlinie aus, um den Anreicherungsindex zu erstellen. Dabei wird ein spezieller interner Index erstellt, indem der ursprüngliche Quellindex in eine effizientere Datenstruktur eingelesen und anschließend im gesamten Cluster kopiert wird.

Die Anreicherungsrichtlinie kann mit folgendem Befehl erstellt werden:

Die Richtlinie kann mit folgendem Befehl ausgeführt werden:

Beachten Sie, dass Sie diese Richtlinie erneut ausführen müssen, wenn Sie den Inhalt des Index airport_city_boundaries ändern, damit die Änderungen im Anreicherungsindex sichtbar werden. Führen wir nun die ursprüngliche ES|QL-Abfrage erneut aus:

Dies liefert die Top 5 Regionen mit den meisten Flughäfen, zusammen mit dem Schwerpunkt aller Flughäfen, die übereinstimmenden Regionen zugeordnet sind, und der Längenspanne der WKT-Darstellung der Stadtgrenzen innerhalb dieser Regionen:

Schwerpunkt

Anzahl

Region

PUNKT (-12.139086859300733 31.024386116624648)

126

null

PUNKT (-83.10398317873478 42.300230911932886)

3

Detroit

Punkt (39.74537850357592 47.21613017376512)

3

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

PUNKT (-156.80986787192523 20,476673701778054)

3

Hawaii

PUNKT (-73.94515332765877 40.70366442203522)

3

Stadt New York

PUNKT (-83.10398317873478 42.300230911932886)

3

Detroit

PUNKT (-76.66873019188643 24.306286952923983)

2

New Providence

PUNKT (-3,0252167768776417 51,39245774131268)

2

Cardiff

PUNKT (-115.40993484668434 32,73126147687435)

2

Municipio de Mexicali

Punkt (41.790108773857355 50.302146775648)

2

Zentralbezirk

PUNKT (-73.88902732171118 45.57078813901171)

2

Montréal

Möglicherweise stellen Sie auch fest, dass die am häufigsten vorkommende Region null war. Was könnte das bedeuten? Zur Erinnerung: Ich habe diesen Befehl mit einem 'Left Join' in SQL verglichen. Das bedeutet, dass, wenn keine übereinstimmende Stadtgrenze für einen Flughafen gefunden wird, der Flughafen trotzdem zurückgegeben wird, jedoch mit null Werten für die Felder ab dem airport_city_boundaries Index. Es stellte sich heraus, dass es 125 Flughäfen gab, bei denen kein passender Eintrag city_boundary gefunden wurde, und einen Flughafen mit einer Übereinstimmung, bei dem das Feld region den null hatte. Dies führte zu einer Zählung von 126 Flughäfen ohne region in den Ergebnissen. Falls Ihr Anwendungsfall erfordert, dass alle Flughäfen einer Stadtgrenze zugeordnet werden können, müssten zusätzliche Daten beschafft werden, um die Lücken zu schließen. Es wäre notwendig, zwei Dinge zu ermitteln:

• Welche Datensätze im Index airport_city_boundaries haben keine city_boundary Felder?

• welche Datensätze im Index airports nicht mit dem Befehl ENRICH übereinstimmen (d.h. (überschneiden sich nicht)

Verwendung von ES|QL für Geodaten in Kibana Maps

Kibana hat die Unterstützung für Spatial ES|QL in der Kartenanwendung hinzugefügt. Das bedeutet, dass Sie nun ES|QL verwenden können, um in Elasticsearch nach Geodaten zu suchen und die Ergebnisse auf einer Karte zu visualisieren.

Im Menü „Ebenen hinzufügen“ gibt es eine neue Ebenenoption mit der Bezeichnung „ES|QL“. Wie alle bisher beschriebenen Geodatenfunktionen befindet sich auch diese in der „technischen Vorschauphase“. Durch Auswahl dieser Option können Sie der Karte eine Ebene hinzufügen, die auf den Ergebnissen einer ES|QL-Abfrage basiert. Man könnte beispielsweise eine Ebene zur Karte hinzufügen, die alle Flughäfen der Welt anzeigt.

Oder Sie könnten eine Ebene hinzufügen, die die Polygone ab dem Index airport_city_boundaries anzeigt, oder noch besser, wie wäre es mit der komplexen ENRICH -Abfrage oben, die Statistiken darüber generiert, wie viele Flughäfen sich in jeder Region befinden?

Was kommt als Nächstes?

Der vorherige Blogbeitrag zum Thema Geodaten-Suche konzentrierte sich auf die Verwendung von Funktionen wie ST_INTERSECTS zur Durchführung von Suchvorgängen, die in Elasticsearch seit Version 8.14 verfügbar sind. Und in diesem Blog erfahren Sie, wie Sie die Daten importieren können, die wir für diese Suchvorgänge verwendet haben. Elasticsearch 8.15 brachte jedoch eine besonders interessante Funktion mit sich: ST_DISTANCE , mit der sich effiziente räumliche Distanzsuchen durchführen lassen, und dies wird das Thema des nächsten Blogbeitrags sein!

Elasticsearch 8.12 und 8.13 führten die grundlegende Unterstützung für Geodaten-Typen in ES|QL ein. Dies wurde durch die Hinzufügung von Geodaten-Suchfunktionen in Version 8.14 deutlich verbessert. Wichtiger noch: Diese Unterstützung wurde so konzipiert, dass sie sich eng an den Simple Feature Access- Standard des Open Geospatial Consortium (OGC) anlehnt, der auch von anderen räumlichen Datenbanken wie PostGIS verwendet wird. Dadurch wird die Nutzung für GIS-Experten, die mit diesen Standards vertraut sind, deutlich vereinfacht.

In diesem Blog zeigen wir Ihnen, wie Sie mit ES|QL Geodatenabfragen durchführen und wie sich dies im Vergleich zu den entsprechenden SQL- und Query-DSL-Funktionen verhält. Wir zeigen Ihnen außerdem, wie Sie mit ES|QL räumliche Verknüpfungen durchführen und wie Sie die Ergebnisse in Kibana Maps visualisieren. Bitte beachten Sie, dass sich alle hier beschriebenen Funktionen in der „technischen Vorschau“ befinden. Wir freuen uns über Ihr Feedback, wie wir diese verbessern können.

Suche nach Geodaten

Beginnen wir mit einer Beispielabfrage:

Hierbei wird nach Stadtgrenzenpolygonen gesucht, die sich mit einem rechteckigen Suchpolygon um den internationalen Flughafen Sanya Phoenix (SYX) schneiden.

In einem Beispieldatensatz mit Flughäfen, Städten und Stadtgrenzen findet diese Suche das sich überschneidende Polygon und gibt die gewünschten Felder aus dem übereinstimmenden Dokument zurück:

Abkürzung

Flughafen

Region

Stadt

Stadtstandort

SYX

Sanya Phoenix Int'l

天涯区

Sanya

Punkt(109.5036 18.2533)

Das war einfach! Vergleichen Sie dies nun mit der klassischen Elasticsearch Query DSL für dieselbe Abfrage:

Beide Abfragen sind in ihrer Absicht einigermaßen klar, aber die ES|QL-Abfrage ähnelt stark SQL. Die gleiche Abfrage in PostGIS sieht folgendermaßen aus:

Schauen Sie sich das ES|QL-Beispiel noch einmal an. So ähnlich, nicht wahr?

Wir haben festgestellt, dass bestehende Benutzer der Elasticsearch API ES|QL als wesentlich einfacher zu bedienen empfinden. Wir gehen davon aus, dass bestehende SQL-Anwender, insbesondere Spatial SQL-Anwender, feststellen werden, dass sich ES|QL sehr vertraut anfühlt und ihnen sehr ähnlich ist.

Warum nicht SQL?

Und wie sieht es mit Elasticsearch SQL aus? Es existiert schon eine Weile und verfügt über einige Geodatenfunktionen. Elasticsearch SQL wurde jedoch als Wrapper für die ursprüngliche Query-API geschrieben, was bedeutete, dass nur Abfragen unterstützt wurden, die in die ursprüngliche API transpiliert werden konnten. ES|QL hat diese Einschränkung nicht. Da es sich um einen völlig neuen Stack handelt, sind viele Optimierungen möglich, die in SQL nicht möglich waren. Unsere Benchmarks zeigen, dass ES|QL sehr oft schneller ist als die Query API, insbesondere bei Aggregationen!

Unterschiede zu SQL

Wie das vorherige Beispiel zeigt, ist ES|QL SQL zwar in gewisser Weise ähnlich, es gibt aber auch einige wichtige Unterschiede. ES|QL ist beispielsweise eine Pipe-Abfragesprache, die mit einem Quellbefehl wie FROM beginnt und dann alle nachfolgenden Befehle mit dem Pipe-Zeichen | miteinander verkettet. Dadurch wird es sehr einfach verständlich, wie jeder Befehl eine Datentabelle empfängt und eine bestimmte Aktion an dieser Tabelle durchführt, z. B. Filtern mit WHERE, Hinzufügen von Spalten mit EVAL oder Durchführen von Aggregationen mit STATS. Anstatt mit SELECT zu beginnen, um die endgültigen Ausgabespalten zu definieren, können ein oder mehrere KEEP -Befehle verwendet werden, wobei der letzte Befehl die endgültigen Ausgaberesultate angibt. Diese Struktur vereinfacht die Argumentation bezüglich der Anfrage.

Wenn wir uns den Befehl WHERE im obigen Beispiel genauer ansehen, erkennen wir, dass er dem PostGIS-Beispiel sehr ähnlich sieht:

ES|QL

PostGIS

Abgesehen von den Unterschieden bei den Anführungszeichen für Zeichenketten besteht der größte Unterschied darin, wie wir die Zeichenkette in einen räumlichen Datentyp umwandeln. In PostGIS verwenden wir das Suffix ::geometry , während wir in ES|QL das Suffix ::geo_shape verwenden. Dies liegt daran, dass ES|QL innerhalb von Elasticsearch ausgeführt wird und der Typumwandlungsoperator :: verwendet werden kann, um eine Zeichenkette in einen der unterstützten ES|QL-Typen umzuwandeln, in diesem Fall in einen geo_shape. Darüber hinaus implizieren die Typen geo_shape und geo_point in Elasticsearch das räumliche Koordinatensystem WGS84, das häufiger unter der SRID-Nummer 4326 bezeichnet wird. In PostGIS muss dies explizit angegeben werden, daher die Verwendung des Präfixes SRID=4326; für die WKT-Zeichenkette. Wird dieses Präfix entfernt, wird die SRID auf 0 gesetzt, was eher den Elasticsearch-Typen cartesian_point und cartesian_shape entspricht, die nicht an ein bestimmtes Koordinatensystem gebunden sind.

Sowohl ES|QL als auch PostGIS bieten eine Syntax für Typkonvertierungsfunktionen:

ES|QL

PostGIS

OGC-Funktionen

Elasticsearch 8.14 führt die folgenden vier OGC-Funktionen für die räumliche Suche ein:

ES|QL

PostGIS

Beschreibung

ST_INTERSECTS

ST_Schnittpunkte

Gibt true zurück, wenn sich zwei Geometrien schneiden, und andernfalls false.

ST_DISJOINT

ST_Disjoint

Gibt true zurück, wenn sich zwei Geometrien nicht schneiden, und andernfalls false. Die Umkehrfunktion von ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Gibt true zurück, wenn eine Geometrie eine andere enthält, andernfalls false.

ST_WITHIN

ST_Within

Gibt true zurück, wenn sich eine Geometrie innerhalb einer anderen befindet, und andernfalls false. Das Inverse von ST_CONTAINS.

Diese Funktionen verhalten sich ähnlich wie ihre PostGIS-Pendants und werden auf die gleiche Weise verwendet. Beispielsweise gibt ST_INTERSECTS true zurück, wenn sich zwei Geometrien schneiden, und andernfalls false. Wenn Sie den Dokumentationslinks in der obigen Tabelle folgen, werden Sie feststellen, dass sich alle ES|QL-Beispiele innerhalb einer WHERE -Klausel nach einer FROM -Klausel befinden, während alle PostGIS-Beispiele literale Geometrien verwenden. Tatsächlich unterstützen beide Plattformen die Verwendung der Funktionen in jedem Teil der Abfrage, in dem sie sinnvoll sind.

Das erste Beispiel in der PostGIS-Dokumentation für ST_INTERSECTS lautet:

Das ES|QL-Äquivalent dazu wäre:

Beachten Sie, dass wir im PostGIS-Beispiel die SRID nicht angegeben haben. Dies liegt daran, dass in PostGIS bei Verwendung des Typs geometry alle Berechnungen auf einem planaren Koordinatensystem durchgeführt werden. Wenn also beide Geometrien die gleiche SRID haben, spielt es keine Rolle, welche SRID es ist. In Elasticsearch gilt dies auch für die meisten Funktionen. Es gibt jedoch Ausnahmen, bei denen geo_shape und geo_point sphärische Berechnungen verwenden, wie wir im nächsten Blogbeitrag über die Suche nach räumlichen Distanzen sehen werden.

ES|QL Vielseitigkeit

Wir haben oben also Beispiele für die Verwendung von räumlichen Funktionen in WHERE -Klauseln und in ROW -Befehlen gesehen. Wo sonst würden sie Sinn machen? Eine sehr nützliche Stelle dafür ist der Befehl EVAL . Mit diesem Befehl können Sie einen Ausdruck auswerten und das Ergebnis zurückgeben. Nehmen wir beispielsweise an, wir wollen feststellen, ob die Schwerpunkte aller Flughäfen, gruppiert nach ihren Ländernamen, innerhalb einer Grenze liegen, die das jeweilige Land umschließt:

Die Ergebnisse sind erwartungsgemäß: Die Schwerpunkte der britischen Flughäfen liegen innerhalb der Grenzen Großbritanniens und nicht innerhalb der Grenzen Islands, und umgekehrt.

Schwerpunkt

Anzahl

in_uk

in Island

innerhalb Großbritanniens

innerhalb Islands

PUNKT (-21,946634463965893 64.13187285885215)

1

FALSCH

wahr

FALSCH

wahr

PUNKT (-2,597342072712148 54,33551226578214)

17

wahr

FALSCH

wahr

FALSCH

PUNKT (0,04453958108176276 23,74658354606057)

873

FALSCH

FALSCH

FALSCH

FALSCH

Tatsächlich können diese Funktionen in jedem Teil der Abfrage verwendet werden, in dem ihre Signatur sinnvoll ist. Sie alle nehmen zwei Argumente entgegen, die entweder ein Literal eines räumlichen Objekts oder ein Feld eines räumlichen Typs sind, und sie alle geben einen booleschen Wert zurück. Eine wichtige Überlegung ist, dass das Koordinatenreferenzsystem (CRS) der Geometrien übereinstimmen muss, andernfalls wird ein Fehler zurückgegeben. Das bedeutet, dass Sie die Typen geo_shape und cartesian_shape nicht im selben Funktionsaufruf mischen können. Allerdings können Sie die Typen geo_point und geo_shape mischen, da der Typ geo_point ein Sonderfall des Typs geo_shape ist und beide das gleiche Koordinatenreferenzsystem verwenden. Die Dokumentation zu jeder der oben definierten Funktionen listet die unterstützten Typkombinationen auf.

Darüber hinaus kann jedes Argument ein räumliches Literal oder ein Feld sein, in beliebiger Reihenfolge. Sie können sogar zwei Felder, zwei Literale, ein Feld und ein Literal oder ein Literal und ein Feld angeben. Die einzige Voraussetzung ist, dass die Datentypen kompatibel sind. Diese Abfrage vergleicht beispielsweise zwei Felder im selben Index:

Die Anfrage zielt im Grunde darauf ab, ob sich der Ort innerhalb der Stadtgrenzen befindet, was im Allgemeinen zutreffen sollte, aber es gibt immer Ausnahmen:

Kardinalität

Anzahl

in_city

wenige

29

FALSCH

viele

740

wahr

Eine weitaus interessantere Frage wäre, ob sich der Flughafenstandort innerhalb der Grenzen der Stadt befindet, die der Flughafen bedient. Der Standort des Flughafens befindet sich jedoch in einem anderen Index als derjenige, der die Stadtgrenzen enthält. Dies erfordert eine Methode, um Daten aus diesen beiden separaten Indizes effektiv abzufragen und zu korrelieren.

Räumliche Verknüpfungen

ES|QL unterstützt keine JOIN -Befehle, aber Sie können einen Sonderfall eines Joins mit dem ENRICH -Befehl erreichen, der sich ähnlich wie ein 'left join' in SQL verhält. Dieser Befehl funktioniert ähnlich wie ein „Left Join“ in SQL und ermöglicht es Ihnen, Ergebnisse aus einem Index mit Daten aus einem anderen Index anzureichern, basierend auf einer räumlichen Beziehung zwischen den beiden Datensätzen.

Nehmen wir beispielsweise an, wir reichern die Ergebnisse einer Tabelle mit Flughäfen um zusätzliche Informationen über die jeweilige Stadt an, indem wir die Stadtgrenze ermitteln, die den Flughafenstandort enthält, und führen dann einige statistische Auswertungen der Ergebnisse durch:

Dies liefert die Top 5 Regionen mit den meisten Flughäfen, zusammen mit dem Schwerpunkt aller Flughäfen, die übereinstimmenden Regionen zugeordnet sind, und der Längenspanne der WKT-Darstellung der Stadtgrenzen innerhalb dieser Regionen:

Schwerpunkt

Anzahl

min_wkt

max_wkt

Region

PUNKT (-32.56093470960719 32.598117914802714)

90

207

207

null

PUNKT (-73.94515332765877 40.70366442203522)

9

438

438

Stadt New York

PUNKT (-83.10398317873478 42.300230911932886)

9

473

473

Detroit

PUNKT (-156.3020245861262 20.176383580081165)

5

307

803

Hawaii

PUNKT (-73.88902732171118 45.57078813901171)

4

837

837

Montréal

Was ist hier also wirklich geschehen? Wo trat das vermeintliche JOIN auf? Der Kern der Anfrage liegt im Befehl ENRICH :

Dieser Befehl weist Elasticsearch an, die aus dem Index airports abgerufenen Ergebnisse anzureichern und einen Join intersects zwischen dem Feld city_location des ursprünglichen Index und dem Feld city_boundary des Index airport_city_boundaries durchzuführen, den wir bereits in einigen Beispielen verwendet haben. Einige dieser Informationen sind in dieser Abfrage jedoch nicht klar ersichtlich. Was wir sehen, ist der Name einer Anreicherungsrichtlinie city_boundaries, und die fehlenden Informationen sind in dieser Richtliniendefinition enthalten.

Hier sehen wir, dass eine geo_match -Abfrage durchgeführt wird (intersects ist der Standardwert), das Feld, mit dem abgeglichen werden soll, ist city_boundary, und die enrich_fields sind die Felder, die wir dem Originaldokument hinzufügen möchten. Eines dieser Felder, nämlich region wurde tatsächlich als Gruppierungsschlüssel für den Befehl STATS verwendet, was ohne diese 'left join'-Funktion nicht möglich gewesen wäre. Weitere Informationen zu Anreicherungsrichtlinien finden Sie in der Anreicherungsdokumentation. Beim Lesen dieser Dokumente werden Sie feststellen, dass darin die Verwendung von Anreicherungsindizes zur Anreicherung von Daten während der Indexierung durch die Konfiguration von Aufnahmepipelines beschrieben wird. Dies ist für ES|QL nicht erforderlich, da der Befehl ENRICH zur Abfragezeit funktioniert. Es genügt, den Anreicherungsindex mit den erforderlichen Daten und der Anreicherungsrichtlinie vorzubereiten und dann den Befehl ENRICH in Ihren ES|QL-Abfragen zu verwenden.

Möglicherweise stellen Sie auch fest, dass die am häufigsten vorkommende Region null war. Was könnte das bedeuten? Zur Erinnerung: Ich habe diesen Befehl mit einem 'Left Join' in SQL verglichen. Das bedeutet, dass, wenn keine übereinstimmende Stadtgrenze für einen Flughafen gefunden wird, der Flughafen trotzdem zurückgegeben wird, jedoch mit null Werten für die Felder ab dem airport_city_boundaries Index. Es stellte sich heraus, dass es 89 Flughäfen gab, bei denen kein passender Eintrag city_boundary gefunden wurde, und einen Flughafen mit einer Übereinstimmung, bei dem das Feld region den null hatte. Dies führte zu einer Zählung von 90 Flughäfen, bei denen keine region in den Ergebnissen vorkam. Ein weiteres interessantes Detail ist die Notwendigkeit des Befehls MV_EXPAND . Dies ist notwendig, da der Befehl ENRICH für jede Eingabezeile mehrere Ergebnisse zurückgeben kann, und MV_EXPAND hilft dabei, diese Ergebnisse in mehrere Zeilen aufzuteilen, eine für jedes Ergebnis. Dies erklärt auch, warum für "Hawaii" unterschiedliche min_wkt und max_wkt Ergebnisse angezeigt werden: Es gab mehrere Regionen mit dem gleichen Namen, aber unterschiedlichen Grenzen.

Kibana-Karten

Kibana hat die Unterstützung für Spatial ES|QL in der Kartenanwendung hinzugefügt. Das bedeutet, dass Sie nun ES|QL verwenden können, um in Elasticsearch nach Geodaten zu suchen und die Ergebnisse auf einer Karte zu visualisieren.

Im Menü „Ebenen hinzufügen“ gibt es eine neue Ebenenoption mit der Bezeichnung „ES|QL“. Wie alle bisher beschriebenen Geodatenfunktionen befindet sich auch diese in der „technischen Vorschauphase“. Durch Auswahl dieser Option können Sie der Karte eine Ebene hinzufügen, die auf den Ergebnissen einer ES|QL-Abfrage basiert. Man könnte beispielsweise eine Ebene zur Karte hinzufügen, die alle Flughäfen der Welt anzeigt.

Oder Sie könnten eine Ebene hinzufügen, die die Polygone ab dem Index airport_city_boundaries anzeigt, oder noch besser, wie wäre es mit der komplexen ENRICH -Abfrage oben, die Statistiken darüber generiert, wie viele Flughäfen sich in jeder Region befinden?

Was kommt als Nächstes?

Vielleicht ist Ihnen aufgefallen, dass wir in zwei der obigen Beispiele noch eine weitere räumliche Funktion ST_CENTROID_AGG eingefügt haben. Dies ist eine Aggregationsfunktion, die im Befehl STATS verwendet wird, und die erste von vielen räumlichen Analysefunktionen, die wir ES|QL hinzufügen wollen. Wir werden darüber bloggen, sobald wir mehr zu zeigen haben!

Zuvor möchten wir Ihnen jedoch ein besonders spannendes Feature vorstellen, an dem wir gearbeitet haben: die Möglichkeit, räumliche Distanzsuchen durchzuführen – eine der am häufigsten genutzten räumlichen Suchfunktionen von Elasticsearch. Können Sie sich vorstellen, wie die Syntax für Distanzsuchen aussehen könnte? Vielleicht ähnlich einer OGC-Funktion? Bleiben Sie dran für den nächsten Blogbeitrag dieser Reihe, um es herauszufinden!

Spoiler-Alarm: Elasticsearch 8.15 wurde soeben veröffentlicht und beinhaltet die räumliche Distanzsuche mit ES|QL!

ES|QL

ES|QL ist eine neue Elasticsearch-Abfragesprache, die in Elasticsearch 8.11.0 eingeführt wurde. Aktuell ist es als technische Vorschau verfügbar. Es bietet eine leistungsstarke Möglichkeit, in Elasticsearch gespeicherte Daten zu filtern, zu transformieren und zu analysieren.

Es verwendet "Pipes" (|), um Daten schrittweise zu manipulieren und zu transformieren. Dieser Ansatz ermöglicht es den Benutzern, eine Reihe von Operationen zu erstellen, wobei das Ergebnis einer Operation als Eingabe für die nächste dient, wodurch komplexe Datentransformationen und -analysen möglich werden.

Die folgende Abfrage gibt beispielsweise die ersten 3 Dokumente (Zeilen) des Index sample_data zurück:

Anwendungsfall: ES|QL-Funktionen im offiziellen PHP-Client

Um die im offiziellen PHP-Client entwickelten ES|QL-Funktionen zu veranschaulichen, haben wir eine CSV-Datei mit 81.828 Büchern (54,4 MB) in Elasticsearch gespeichert, die folgende Informationen enthält:

Wir haben diese Liste aus dem öffentlich verfügbaren Datensatz der Amazon-Buchrezensionen extrahiert.

Wir haben einen books -Index mit den folgenden Elasticsearch-Mappings erstellt:

Der Wert rating ist der Durchschnitt der Ranking-Rezensionen aus der 2,9 GB großen Datei Books_rating.csv .

Hier finden Sie das PHP-Skript, mit dem wir alle Bücher in Elasticsearch per Massenimport importiert haben. Die Massenverarbeitung dauerte 7 Sekunden und benötigte 28 MB RAM unter Verwendung von PHP 8.2.17. Mit dem vorgeschlagenen Mapping beträgt die Indexgröße in Elasticsearch etwa 62 MB.

ES|QL-Ergebnisse einem PHP-Objekt oder einer benutzerdefinierten Klasse zuordnen

Wir können ES|QL-Abfragen in PHP über den esql()->query() -Endpunkt ausführen. Das Ergebnis dieser Abfrage ist eine Tabellendatenstruktur. Dies wird in JSON mithilfe der Felder columns und values ausgedrückt. Im Feld columns haben wir die Definitionen name und type .

Hier ist ein Beispiel für eine ES|QL-Abfrage, um die Top-10-Bücher von Stephen King, sortiert nach den Nutzerbewertungen, abzurufen:

Das JSON-Ergebnis von Elasticsearch sieht wie folgt aus:

In diesem Beispiel haben wir 6 Eigenschaften (Autor, Beschreibung, Verlag, Bewertung, Titel, Jahr) zu einem Buch und 10 Ergebnisse, alle Bücher von Stephen King.

Eine Liste aller in ES|QL unterstützten Datentypen finden Sie hier.

Das $result -Antwortobjekt kann als Array, als Zeichenkette oder als Objekt aufgerufen werden (siehe hier für weitere Informationen).

Mithilfe der Objektschnittstelle können wir über Eigenschaften und Indizes auf die Werte zugreifen. Beispielsweise gibt $result->values[0][4] den Titel (4) des ersten Buches (0) in der Liste zurück, $result->values[1][3] die Bewertung (3) des zweiten Buches (1) usw. Denken Sie daran, dass der Index eines Arrays in PHP bei Null beginnt.

Diese Schnittstelle mag für einige Anwendungsfälle ausreichend sein, aber in den meisten Fällen möchten wir als Ergebnis ein Array von Objekten erhalten.

Um das Ergebnis in ein Array von Objekten abzubilden, können wir die neue mapTo()- Funktion von elasticsearch-php verwenden.

Diese Funktion ist direkt im Elasticsearch-Antwortobjekt verfügbar. Das bedeutet, Sie können wie folgt darauf zugreifen:

Wenn Sie eine benutzerdefinierte Buchklasse haben, können Sie das Ergebnis mithilfe dieser Klasse wie folgt abbilden:

Wenn Ihre Klasse neben den im ES|QL-Ergebnis enthaltenen Eigenschaften noch weitere Eigenschaften besitzt, funktioniert dies ebenfalls. Die Funktion mapTo() verwendet nur die Eigenschaften, die als Spalten des ES|QL-Ergebnisses zurückgegeben werden.

Sie können alle in diesem Artikel genannten Beispiele hier herunterladen.