Elastic Stack: Neue Features von der ElasticON 2023

Wir waren für Sie dabei: Auch dieses Jahr gab es auf der ElasticON wieder spannende Einblicke in die aktuelle Entwicklung bei unserem Partner Elastic und Ausblicke auf zukünftige Features des Elastic Stack. Eine Auswahl an Themen haben wir für Sie in diesem Beitrag zusammengefasst. Es geht um Vektorsuche, die neue Elasticsearch Query Language, Ingest Pipelines, kosteneffiziente Loganalyse und Performance-Gewinn im öffentlichen Nahverkehr.

Keynote: Wie geht es weiter mit Elastic CPO?

Ken Exner, Elastics Chief Product Officer, berichtete über die Entwicklung von Elastic und ihre zukünftigen Pläne als Unternehmen. Zunächst blickt er auf die Anfänge zurück: Gestartet hat Elastic mit einer Person, Shay Banon, der in seiner Freizeit mit der Programmierung einer Suchmaschine für das wachsende Rezeptverzeichnis seiner Frau begann. Mittlerweile ist daraus ein Software Stack erwachsen, der eine Vielzahl an Use Cases abbildet: Observability, Security, Search, Ingest, Store, Analyze, Visualize und Explore.

Ken Exner stellte in der Keynote außerdem einige Neuerungen vor:

Security

• Entity Analytics Dashboard (seit 8.5): Das Entity Analytics Dashboard bietet einen zentralen Überblick über aufkommende Insider-Bedrohungen – einschließlich Host-Risiko, Benutzer-Risiko und auffällige Anomalien innerhalb Ihres Netzwerks. Man kann damit diese neuen Bedrohungen einteilen, untersuchen und darauf reagieren.
• Neue Query Language ESQL: Für komplexere Suchanfragen (wurde in einem eigenen Vortrag vorgestellt).

Observability

• universelles Profiling
• synthetisches Monitoring (Beta-Version bald verfügbar)
• AIOps Fähigkeiten: schnelle Ursachenfindung bei Abweichung von erwartetem Verhalten

Search

• kontinuierliche Verbesserungen, z. B. Speicherauslastung
• neue Konnektoren (Azure Blob Storage, Postgres, …)
• verbesserte Vektorsuche

Hosting

• In Planung: Serverless Service (managed by Elastic). Aktuell gibt es nur „self-managed“ und „Elastic Cloud“.

Elasticsearch für Entwickler

Matt Riley, General Manager Enterprise Search bei Elastic, beleuchtete einige technologischen Neuerungen näher. Vor allem die Vektorsuche mit Elasticssearch stand bei diesem Vortrag im Mittelpunkt. Neben der Neuigkeit, dass nun auch eigene Modelle verwendet werden können, stellte er auch das neue Out-of-the-box Modell „SLIM“ (Sparse Interaction Model) vor. SLIM eignet sich besonders für alle ohne Data Science-Expertise.

Ergänzend demonstrierte Matt Riley SLIM an einer Beispielsuchanfrage „Kann ich auch online Videos schauen?“. Die Ergebnisse der Vektorsuche waren dabei deutlich besser als die der normalen Keywordsuche.

Joins und mehr mit der neuen Elasticsearch Query Language

Alvin Richards, Product Lead Elasticsearch stellte in diesem Vortrag die neue Elasticsearch Query Language (ESQL) vor, die sich gerade in der Entwicklung befindet. Sie soll Möglichkeiten bieten, um die Daten „on the fly“ zu filtern, zu aggregieren und zu sortieren. Neue Werte sollen so während der Suche berechnet werden können. Damit wären dann auch Lookups und Joins über mehrere Indizes zur Suchzeit umsetzbar, ein langersehntes Feature bei vielen unserer Kunden. 

Darüber hinaus wird es eine Distributed Compute Engine geben, über die Skalierung unabhängig von Data Nodes und Kapazitäten realisierbar ist. Über Parallelisierung von Tasks sind dann enorme Performance-Verbesserungen denkbar. Im Vortrag wurde ein Beispiel gezeigt, bei der die Suche mit ESQL unfassbare 33-mal schneller war als die aktuelle Elasticsearch-Suche.

Aber noch weitere Optionen sollen über ESQL in Zukunft geschaffen werden, darunter etwa Unterstützung von Inline Conditions und erweiterter Support verschiedener Datentypen.

Google Cloud Keynote: Datenmodernisierung ist der Schlüssel zu einem erfolgreichen digitalen Unternehmen

Google Cloud und Elastic haben seit Beginn ihrer Partnerschaft im Jahr 2017 bereits über 2400 Kunden bedient. Die Integration bietet eine konsolidierte Abrechnung mit einfacher Beschaffung und Überwachung der Ausgaben. Außerdem ermöglicht sie Elasticsearch Zugang zu allen Google-Produkten wie Drive, Photos, Docs usw. und die Suche in allen Google-Diensten.

Elasticsearch und OpenSearch: Nicht dasselbe

George Kobar, Product Marketing Director Elastic, erläuterte in diesem Vortrag die Unterschiede zwischen Elasticsearch und OpenSearch. Letzteres wurde 2020 von AWS gestartet und baut auf einer früheren Version von Elasticsearch auf. Einige Funktionen haben zwar die gleichen Namen, aber die OpenSearch-Variante bietet weniger Möglichkeiten. Die clusterübergreifende Suche beispielsweise fehlt darin.

In OpenSearch werden die Funktionen als Plug-ins bereitgestellt, die es ermöglichen, es leicht zu erweitern. Das jedoch führt häufig zu Leistungs- und Interoperabilitätsproblemen sowie Problemen bei der Verwaltung der Plug-ins. In der Suche in Elasticsearch ist im Vergleich dazu alles integriert. Sogar die Suche über Frozen Tiers in Elasticsearch kann mit der Performance der Hot Tier Suche anderer Anbieter mithalten. Und dabei geht Elasticsearch sehr sparsam mit Speicherplatz, Speicher und Rechenleistung um.

Hybride Suche (Vektorsuche und traditionelle Suche) ist sowohl in OpenSearch als auch in Elasticsearch möglich. Im Vergleich der Leistungsfähigkeit siegt hier aber Elasticsearch. OpenSearch liegt ein wenig vorn bei den Optionen des „serverless“ Hostings, aber die Möglichkeiten wird es bald in Elasticsearch ebenso geben.

Verwendung der Ingest-Pipeline zur Verwaltung von Indexnamen

Haydar Kulekci, Senior Data Engineer bei Browzzin Ltd., stellte verschiedene Ansätze zur Datenmodifikation vor. Benutzerdefinierte Skripte, über welche die Daten an Elasticsearch gesendet werden, funktionieren zwar gut, verursachen aber Probleme, wenn sich die Anforderungen ändern.

Logstash eignet sich für die Datenmanipulation, dabei ist es aber relevant, wie weit das Logstash-Cluster vom Elasticsearch-Cluster entfernt sind. Je näher sie sich zueinander befinden, desto besser die Performance. Bei der dritten Option für die Datenmodifikation – den Ingest Pipelines – ging Haydar Kulekci im Vortrag mehr ins Detail. Im Vergleich zu Logstash sind die Ingest Pipelines in Elasticsearch eine leichtgewichtigere Möglichkeit, Daten zu ändern, da hier kein Overhead für den Betrieb eines zusätzlichen Clusters entsteht.

Die Ingest Pipelines weisen dazu auch eine geringere strukturelle Komplexität auf. Dafür müssen aber auch gewisse Einschränkungen in Kauf genommen werden: Das Teilen von Dokumenten ist hier nicht möglich und bei der Verarbeitung mehrerer Dokumente zur gleichen Zeit kommt es zu Problemen.

Verwendung des Elastic Stack für einen sofortigen Checkout

Chris Dicken, Global Head of UX bei Rezolve, erklärte in diesem Vortrag die Idee hinter „Instant Checkouts“. Der übliche Kaufprozess umfasst viele Schritte. Jeder Schritt birgt die Gefahr, dass der Kunde den Kauf abbricht. Ein schneller, direkter Checkout (z. B. ausgelöst durch Links, QRs oder Buttons in Online-Shops) löst dieses Problem. Zum Beispiel könnte so in einem Post in den sozialen Medien ein Produkt gezeigt werden, zusammen mit einem Link, der direkt zum Checkout des Online-Shops führt.

Technische Herausforderungen lagen unter anderem an der mangelnden Geschwindigkeit von Datenbankabfragen (z. B. zur Verfügbarkeit des Produkts). Deshalb wurde Elasticsearch zum Backend hinzugefügt. Der Instant Checkout Service fragt nun Elasticsearch ab. Elasticsearch wird mit der Datenbank synchronisiert, sodass die Daten immer aktuell sind. Die verteilte flexible Architektur erlaubt bessere Reaktionsfähigkeit sowie höhere Verfügbarkeit und schnitt in den Tests wesentlich besser ab als eine Lösung ohne Elasticsearch.

Kostengünstiges Protokollmanagement im großen Maßstab mit Elastic Observability

Luca Wintergerst, Product Marketing Director bei Elastic, zeigte in dem Vortrag typische Probleme und deren Lösungen bei der Verarbeitung von Logdateien auf. Darunter nannte er exponentielles Wachstum durch mehr Anwendungen oder ausführlichere Protokolle sowie Fragmentierung von Observability-Lösungen (Metriken vs. Logs vs. Traces oder kurz- vs. langfristiger Zugriff).

Warum sich Elasticsearch für eine verbesserte Lösung anbietet

• Daten müssen über Jahre gespeichert werden à Data Tiers Konzept in Elasticsearch
• schnelle aber teure SSD ist nicht kosteneffizient à z. B. Blob-Store für Langzeitspeicherung
• günstiger Speicher ist oft langsam à Elastic hat sehr optimierte Datenstrukturen
• Einige Lösungen erfordern zusätzliche, manuelle Schritte, um alte Protokolle verfügbar zu machen. Dies verlangsamt die Analysen à In Elasticsearch / Kibana verhalten sich alle Daten gleich. Es sind keine zusätzlichen Schritte notwendig.

Um schnellen Zugriff mit gewohnter Suchlogik auch auf ältere Daten zu ermöglichen, werden verschiedene Datenebenen geschaffen. Diese könnten zum Beispiel so gestaltet sein:

1. Hot Realtime (in der Regel die letzten 7 Tage) à SSDs, viele CPUs
2. Warm Realtime/Longterm (7 – 30 Tage) à HDDs (langsamer, aber wirtschaftlicher)
3. Cold Longterm (bis zu 90 Tage) à HDDs
4. Frozen Longterm storage (> 90 Tage) à Blob-Speicher

Die Strategie für das Verschieben auf die unterschiedlichen Ebenen ist vollständig frei konfigurierbar. Die Suche in „kälteren“ Tiers kann zwar etwas langsamer sein, es bedarf aber keiner gesonderten „Rehydrierung“, bevor die Daten erreichbar sind. Die Kosten für den Frozen Tier können bei etwa 1,5 % (!) der Kosten für dieselbe Datenmenge auf einem heißen Knoten liegen.

Die Performance-Vorteile der Reisedatenerfassung mit Elasticsearch

Jeremy Foran, Co-Founder und CEO bei Blue Flag Consulting stellte in diesem Vortrag vor, wie Echtzeit-Analysen mit Elasticsearch die Betreiber im öffentlichen Nahverkehr dazu befähigen, einen effizienten und schnellen Transport zu gewährleisten. 

Durch das Beobachten von Fahrgastrouten sollen geschäftliche Herausforderungen wie 24/7-Betrieb, Staus und Unterbrechungen gemeistert werden. Technisch stieß das in dem vorgestellten Fall auf veraltete Infrastruktur, beschränkte Ressourcen und das Problem, dass jede U-Bahn einzigartig ist.

Über WiFi-Stationen in der U-Bahn konnten Informationen über die Stationen der Fahrgäste gesammelt werden. Auf dieser Basis werden über Graphen- und Pfadfindung die Routen der Fahrgäste analysiert. Graphendatenbanken kamen allerdings hierfür nicht infrage, da die Abfrage ein Problem darstellt und auch die Skalierung schwierig ist. Die Routenberechnung ist zu langsam und auch die Integration der Graphendatenbank mit verschiedenen Clients ist umständlich.

Aus den genannten Gründen wurde Elasticsearch als alternative Lösung in Betracht gezogen. Elasticsearch hält alle möglichen Routen zwischen zwei Stationen und die Abfrage kann als Suche nach bestimmten Parametern ausgeführt werden. Die Abfrage ist so um ein Vielfaches vereinfacht, Anforderungen sind linear und nicht mehr exponentiell und auch die Integration ist simpler.

Eine Milliarde generierter Routen könnten auf einem einfachen 3-Node-Cluster gespeichert und in Millisekunden abgefragt werden! Damit sind schnelle Vorhersagen möglich, die es ermöglichen, die Kund:innen in Echtzeit über Verzögerungen zu informieren und alternative Routen anzubieten.

Wie profitieren Sie von den neuen Features im Elastic Stack?

Denken Sie darüber nach, Elastic für Ihre Suche zu nutzen? Sie haben Elastic bereits im Einsatz und möchten wissen, wie Sie das größte Potenzial ausschöpfen können? Wir beraten Sie gerne in einem kostenlosen und unverbindlichen Gespräch!