Seite 6 - Elasticsearch

Elasticsearch bringt zwei unterschiedliche, oft verwechselte Caching-Mechanismen mit, die beide die Antwortzeit wiederkehrender Anfragen verbessern, dabei aber auf völlig unterschiedlichen Ebenen ansetzen: der Shard-Level Request Cache, der vollständige Suchantworten inklusive Aggregationen node-seitig zwischenspeichert, und der Node Query Cache, oft auch Shard Query Cache genannt, der einzelne, wiederkehrende Filterklauseln auf Shard-Ebene cacht. Wer für eine facettenlastige Magento-Shop-Seite mit Layered Navigation die Performance verbessern will, muss verstehen, welcher der beiden Caches in welcher Situation tatsächlich greift, wie beide bei Schreiboperationen invalidiert werden und wie sich die Query-Struktur gezielt so gestalten lässt, dass beide Caching-Ebenen optimal genutzt werden.

Autocomplete ist keine einfache Prefix-Suche, sondern eine eigene Disziplin mit drei unterschiedlichen Implementierungsansätzen in Elasticsearch, die sich in Latenz, Speicherbedarf und Flexibilität deutlich unterscheiden. Wer den Completion Suggester, den Edge N-Gram Ansatz und search_as_you_type kennt, wählt für jeden Anwendungsfall die passende Lösung, statt eine Universalimplementierung zu erzwingen.

Runtime Fields berechnen ein Feld erst zur Abfragezeit mit einem Painless-Skript, statt es beim Indexieren fest im Mapping zu speichern. Damit lassen sich neue Auswertungsideen sofort ausprobieren, ohne Milliarden Dokumente neu zu indexieren, bevor feststeht, ob sich die Idee überhaupt lohnt.

Ein Elasticsearch-Index ohne durchdachtes Mapping funktioniert am ersten Tag meist problemlos und wird ab dem ersten produktiven Suchproblem zur Baustelle. Wer Feldtypen, Unveraenderlichkeit und Analyzer-Zuordnung vor dem Indexieren klaert, spart sich spaeter aufwendiges Reindexing und inkonsistente Suchergebnisse.

Match Query und Term Query sehen auf den ersten Blick austauschbar aus, funktionieren aber grundlegend verschieden. Die Match Query analysiert Text vor dem Vergleich, die Term Query vergleicht exakt und ungefiltert. Wer diesen Unterschied ignoriert, bekommt auf Text-Feldern leere Ergebnislisten und auf Keyword-Feldern falsch tolerante Treffer, ohne zu verstehen warum.

Full Text Search ist einer der Bereiche, in denen der SQL Standard bewusst wenig vorschreibt und jede Datenbank eine eigene, proprietaere Loesung entwickelt hat. Dieser Artikel vergleicht die Volltextsuche-Implementierungen von PostgreSQL, MySQL und SQL Server, zeigt Indizierung und Relevanz-Ranking anhand konkreter Beispiele und ordnet ein, wo dedizierte Suchmaschinen wie Elasticsearch sinnvoller sind als Full Text Search direkt in der Datenbank.

Jede Volltextsuche in Elasticsearch steht und faellt mit dem Analyzer, der Text beim Indexieren und beim Suchen in vergleichbare Tokens zerlegt. Wer Character Filter, Tokenizer und Token Filter als Pipeline versteht, kann eigene Analyzer bauen und nachvollziehen, warum eine Suche Treffer liefert oder eben nicht.

Volltextsuche, exakte Filterung, Sortierung und Aggregation stellen widerspruechliche Anforderungen an denselben Feldwert. Multi-Fields loesen diesen Konflikt, indem sie einen Wert gleichzeitig mehrfach unterschiedlich indexieren, sodass jede Abfrageart die passende Repraesentation nutzt, ohne Daten zu duplizieren.

Die Terms Aggregation gehört zu den am häufigsten genutzten Elasticsearch-Features, wird aber bei hoher Feldkardinalität schnell zum Performance-Engpass. Der shard_size-Parameter, doc_count_error_upper_bound als Genauigkeitsindikator und eager global ordinals zur Vorberechnung teurer Datenstrukturen entscheiden gemeinsam darüber, ob eine Facetten-Query im einstelligen oder dreistelligen Millisekundenbereich antwortet. Dieser Beitrag zeigt, wie sich Terms Aggregationen bei Millionen eindeutiger Werte gezielt optimieren lassen, ohne die Ergebnisqualität aus dem Blick zu verlieren.

Seit dem Lizenzwechsel von Elasticsearch und Kibana im Januar 2021 entwickeln sich OpenSearch Dashboards und Kibana als zwei eigenständige Projekte auseinander. Für Magento-Betreiber, die Suchanalysen, Layered-Navigation-Auswertungen oder Reindex-Monitoring visualisieren wollen, stellt sich damit die Frage, welches Werkzeug langfristig die passendere Basis ist.