Seite 2 - Elasticsearch

Pipeline-Aggregationen rechnen nicht über einzelne Dokumente, sondern über die Ergebnisse anderer Aggregationen. Damit werden Trends, gleitende Durchschnitte und kumulierte Summen direkt in der Query berechnet, statt sie fehleranfällig im Anwendungscode nachzubilden. Wer Sibling- und Parent-Pipelines verwechselt, bekommt Aggregationsfehler oder falsch verschachtelte Ergebnisse.

Ein Snapshot ist erst dann eine Backup-Strategie, wenn das Repository korrekt eingerichtet, die Snapshot-Frequenz ueber eine SLM-Policy automatisiert und der Restore-Weg regelmaessig getestet ist. Dieser Artikel zeigt, wie Snapshot-Repositories auf S3 und Dateisystem funktionieren, wie inkrementelle Snapshots Speicher sparen und wie ein Restore in der Praxis ablaeuft, ohne den produktiven Cluster zu gefaehrden.

Reines BM25-Scoring kennt nur Textrelevanz, keine Geschaeftsziele. Die Function Score Query schliesst diese Luecke, indem sie den textuellen Score mit zusaetzlichen Faktoren wie Verkaufszahlen, Lagerbestand oder Aktualitaet kombiniert. Wer field_value_factor und Decay-Funktionen beherrscht, kann Suchergebnisse gezielt nach Geschaeftslogik steuern, ohne die textuelle Relevanz zu opfern.

Jede Filteroption in der Magento Layered Navigation, von der Markenauswahl bis zum Preis-Slider, ist das Ergebnis einer Elasticsearch-Aggregation, die im Hintergrund parallel zur eigentlichen Suchanfrage berechnet wird. Wer versteht, wie Terms- und Range-Aggregationen aufgebaut sind, kann eigene Facetten ergaenzen und Performance-Probleme in der Navigation gezielt loesen.

Wer zum ersten Mal ein dense_vector-Feld anlegt, wählt die Vektor-Dimension meist danach, was das gewählte Embedding-Modell nun einmal liefert, ohne die tatsächlichen Speicher- und Performance-Kosten zu hinterfragen. Bei einem kleinen Testkatalog fällt das kaum auf, bei mehreren Millionen Produkten in mehreren Sprachen summieren sich die Kosten pro Vektor jedoch schnell zu einem spürbaren Infrastrukturproblem. Zwischen der Wahl der Dimension, der Quantisierungsstrategie und den HNSW-Graphparametern bestehen enge Wechselwirkungen, die über Speicherbedarf, Indexierungsgeschwindigkeit und Suchqualität gemeinsam entscheiden. Dieser Artikel zeigt, welche Trade-offs bei der Dimensionswahl tatsächlich relevant sind, wie int8- und int4-Quantisierung Speicher spart, ohne die Suchqualität unbrauchbar zu machen, und wie sich die Indexierungsgeschwindigkeit bei großen Produktkatalogen praktisch verbessern lässt.

Log-Einträge, Suchanfragen oder Sensor-Events haben eine Eigenschaft, die klassische Produktdaten nicht haben: Sie werden fortlaufend geschrieben, wachsen unbegrenzt und sollen nach einer gewissen Zeit automatisch aus dem Index verschwinden. Vor Data Streams musste diese Zeitreihen-Verwaltung manuell über eine Kombination aus täglich neu angelegten Indizes, einem Schreib-Alias und einer ILM-Policy nachgebaut werden, mit vielen Stellen, an denen sich ein Fehler einschleichen konnte. Data Streams bündeln genau dieses Muster in einem einzigen, deklarativen Konzept. Dieser Artikel zeigt, wie Data Streams automatisch rotierende Backing-Indizes verwalten, wie sie sich vom klassischen Alias-Muster unterscheiden, und wie ein praktisches Suchanfragen-Log für die spätere Analyse damit aufgebaut wird.

Die klassische Suche nimmt eine Suchanfrage entgegen und findet passende Dokumente in einem Index. Manche Anwendungsfälle brauchen jedoch genau die umgekehrte Richtung: Ein neues Dokument trifft ein, und die Anwendung muss herausfinden, welche von vielen gespeicherten Suchanfragen darauf zutreffen würden. Ein typisches Beispiel ist ein Preisalarm, bei dem tausende Kunden individuelle Suchkriterien hinterlegt haben und benachrichtigt werden sollen, sobald ein neues Produkt genau diese Kriterien erfüllt. Elasticsearch bietet dafür die Percolator Query, die gespeicherte Suchanfragen als eigene Dokumente indexiert und bei jedem neuen Produkt effizient prüft, welche davon zutreffen. Wie das funktioniert, wie sich der Anwendungsfall Preisalarm konkret umsetzen lässt und wo bei sehr vielen gespeicherten Queries die Performance-Grenzen liegen, zeigt dieser Artikel.

Die date_histogram Aggregation gruppiert Dokumente in feste Zeit-Buckets und ist damit das Fundament fast jeder Zeitreihen-Auswertung in Elasticsearch und OpenSearch. Wer calendar_interval und fixed_interval verwechselt oder Zeitzonen ignoriert, bekommt Dashboards mit verschobenen Balken und falschen Tagesgrenzen, ohne dass die Query einen Fehler wirft.

Ein Durchschnittswert verschluckt genau die Latenzspitzen, die Nutzer tatsächlich spüren, weil wenige sehr langsame Requests von vielen schnellen Requests überdeckt werden. Die percentiles Aggregation in Elasticsearch berechnet stattdessen Verteilungspunkte wie p50, p95 und p99 und macht damit sichtbar, wie langsam die langsamsten Requests wirklich sind.

Während Elasticsearch Zugriffskontrolle über das kommerzielle X-Pack Security Modul anbietet, setzt OpenSearch von Anfang an auf ein quelloffenes Security Plugin mit eigener Konfigurationsphilosophie. Wer einen Magento-Suchcluster produktiv betreibt, muss Rollen, Backend-Konfiguration und Audit-Logging verstehen, um Indexer-Service-User, Administratoren und Read-Only-Zugriffe sauber voneinander zu trennen.