Seite 5 - Elasticsearch

Klassische Seite-für-Seite-Paginierung mit from und size funktioniert zuverlässig für die ersten Ergebnisseiten, wird aber bei tiefer Paginierung teuer und liefert inkonsistente Ergebnisse, sobald sich der zugrunde liegende Datenbestand zwischen zwei Seitenabrufen ändert. Für Exportfunktionen, die tausende oder Millionen Dokumente zuverlässig und vollständig durchlaufen müssen, reicht das nicht aus. Die Point-in-Time-API löst dieses Problem, indem sie einen konsistenten Snapshot des Index zu einem festen Zeitpunkt festhält, gegen den anschließend über search_after effizient und ohne Duplikate oder fehlende Dokumente paginiert werden kann. Wie diese Kombination technisch funktioniert, worin sie sich vom älteren Scroll-Mechanismus unterscheidet und wie sich eine robuste Exportfunktion damit umsetzen lässt, zeigt dieser Artikel.

Wer Elasticsearch nur zum Volltextsuchen einsetzt, verschenkt den größten Teil seiner Analysefähigkeiten. Bucket-Aggregationen gruppieren Dokumente nach Feldwerten, Wertebereichen oder Zeitintervallen, während Metric-Aggregationen aus diesen Gruppen konkrete Kennzahlen wie Durchschnitt, Summe oder Minimum berechnen. Erst im Zusammenspiel beider Aggregationstypen entstehen die Dashboards, Facetten und Reports, die produktive Suchanwendungen von einfachen Volltextsuchen unterscheiden.

Wer Produktdaten, Logeinträge oder Sensor-Events in Elasticsearch indexiert, steht regelmäßig vor derselben Frage: Soll die Anwendung die Rohdaten vor dem Senden aufbereiten, oder übernimmt Elasticsearch selbst die Normalisierung, bevor ein Dokument tatsächlich im Index landet? Ingest Pipelines beantworten diese Frage mit einer dritten Option. Eine Kette von Prozessoren wie grok, script oder enrich verarbeitet jedes Dokument direkt beim Schreibvorgang, parst unstrukturierte Strings, wendet individuelle Transformationslogik an und reichert Felder aus externen Referenzdaten an, bevor die eigentliche Indexierung beginnt. Dieser Artikel zeigt, wie diese Prozessoren zusammenspielen, wo die Grenze zur anwendungsseitigen Transformation sinnvoll verläuft und wie eine reale Produktdaten-Normalisierung damit aussieht.

Wird die vollständige Elasticsearch Query DSL direkt im Anwendungscode zusammengebaut, verteilt sich Suchlogik über viele Stellen der Codebasis und jede Anpassung an einer zentralen Query erfordert Änderungen an mehreren Orten gleichzeitig. Search Templates lösen dieses Problem, indem sie eine Mustache-basierte Query-Vorlage einmal zentral in Elasticsearch hinterlegen und der Anwendungscode anschließend nur noch benannte Parameter übergibt, ohne selbst eine Zeile Query-DSL zu kennen. Damit wandert die eigentliche Suchlogik dorthin, wo sie technisch verwaltet werden sollte, und Anwendungsentwickler arbeiten mit einer stabilen, klar dokumentierten Schnittstelle. Wie Search Templates aufgebaut sind, welche Vorteile das für die Zusammenarbeit zwischen Suchteam und Anwendungsteam bringt und wie eine parametrisierte Produktsuche damit konkret aussieht, zeigt dieser Artikel.

Das textbasierte BM25-Scoring von Elasticsearch bewertet Relevanz allein anhand von Textübereinstimmung, ignoriert dabei aber geschäftlich relevante Signale wie Lagerbestand oder Marge. Über Painless-Skripte in einer Function-Score-Query lässt sich diese Lücke schließen, allerdings nur, wenn Integration in Magento und Performance-Auswirkungen sauber verstanden werden.

Faceted Navigation lebt von Terms-Aggregationen auf Produktattributen, aber diese Aggregationen sind nur so schnell wie das darunterliegende Mapping. Wer Attribute als analysierten text-Typ statt als keyword indexiert, bekommt zerstückelte Filterwerte, doppelte Facetten und Aggregationen, die bei jeder Kategorieseite unnötig viel Speicher und Rechenzeit verbrauchen.

Eine initiale Katalog-Indexierung mit mehreren Millionen Produktdokumenten läuft mit den Standardeinstellungen von Elasticsearch spürbar langsamer, als es die zugrunde liegende Hardware eigentlich hergeben würde. Die Bulk-API selbst ist dabei selten der Engpass, sondern das Zusammenspiel aus Batch-Größe, Refresh-Interval, Replica-Anzahl und Thread-Pool-Konfiguration, das bei den Standardwerten auf einen ausgewogenen Dauerbetrieb optimiert ist, nicht auf einen kurzen, intensiven Massenimport. Dieser Artikel zeigt, wie sich die optimale Batch-Größe systematisch ermitteln lässt, welche temporären Einstellungsänderungen während einer Massenindexierung den größten Effekt haben, und wie eine praktische Tuning-Checkliste für die initiale Indexierung eines großen Katalogs aussieht.

Dynamic Mapping erspart am Anfang viel Konfigurationsaufwand, kann aber bei unvorhersehbaren Eingabedaten unbemerkt tausende Felder erzeugen und den Cluster in die Knie zwingen. Wer dynamic false, dynamic strict und Dynamic Templates gezielt einsetzt, behaelt die automatische Felderkennung unter Kontrolle, ohne auf ihre Vorteile zu verzichten.

Ein Store View pro Sprache reicht nicht aus, um mehrsprachige Suche in Magento wirklich sauber zu betreiben. Erst store-view-basierte Indexnamen kombiniert mit sprachspezifischen Elasticsearch-Analyzern verhindern, dass deutsche Komposita falsch zerlegt oder englische Stemming-Regeln auf franzoesische Texte angewendet werden.

Die Google-Ergebnisseite besteht längst aus weit mehr als zehn blauen Links: Featured Snippets, Knowledge Panels, Bilder-Karussells und Shopping-Ergebnisse konkurrieren um denselben Bildschirmplatz. Wer versteht, welches Feature realistisch für welche Suchintention erreichbar ist, verschwendet keine Optimierungsenergie auf unerreichbare Ziele.