Seite 4 - Elasticsearch

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.

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 Elastic im Januar 2021 und dem darauffolgenden Fork zu OpenSearch entwickeln sich beide Suchmaschinen technisch und lizenzrechtlich in unterschiedliche Richtungen. Dieser Artikel ordnet die Geschichte des Forks ein, zeigt die konkrete Feature-Divergenz und liefert Kriterien fuer eine fundierte Migrationsentscheidung zwischen Elasticsearch und OpenSearch.

Ein sauberes Cluster-Health-Monitoring hoert nicht beim einfachen green/yellow/red Status auf, sondern beobachtet die Metriken, die tatsaechlich auf ein sich anbahnendes Problem hindeuten: unassigned Shards, wachsender Heap-Druck und abgelehnte Requests aus vollen Thread-Pool-Queues. Dieser Beitrag zeigt, welche Signale wirklich Alarm ausloesen sollten und wie man sie zuverlaessig ueberwacht.

Index-Aliases sind mehr als ein Alternativname fuer einen Index: strategisch eingesetzt werden sie zum zentralen Versionierungswerkzeug, das Clients dauerhaft von physischen Indexnamen entkoppelt. Zwischen gefilterten Aliases fuer Multi-Tenancy, Routing-Aliases fuer Shard-Optimierung und dem Write-Index-Flag fuer kontrollierte Rollovers entsteht eine Architektur, in der sich Indizes austauschen lassen, ohne dass eine einzige Anwendung ihre Konfiguration anfassen muss.

Fuzzy Search faengt Tippfehler ab, indem sie Woerter zulaesst, die dem Suchbegriff aehnlich, aber nicht identisch sind. Der fuzziness-Parameter steuert dabei ueber die Levenshtein-Distanz, wie viele Zeichenaenderungen toleriert werden. Wer diesen Parameter falsch kalibriert, bekommt entweder zu viele irrelevante Treffer oder verpasst genau die Tippfehler, die eigentlich abgefangen werden sollten.

Die Magento CatalogSearch-Architektur wirkt von aussen wie eine Blackbox: Man aktualisiert ein Attribut, wartet auf den Reindex und hofft, dass die Suche das richtige Ergebnis liefert. Wer versteht, wie Indexer, Fulltext-Scope-Tabellen und der Elasticsearch-Adapter zusammenspielen, kann gezielt debuggen, erweitern und Performance-Probleme an der richtigen Stelle loesen statt am Symptom.

Eine Trefferliste ohne Highlighting zwingt Nutzer, jeden Treffer selbst nach dem gesuchten Begriff zu durchsuchen. Elasticsearch Highlighting markiert relevante Textstellen automatisch im Suchergebnis, doch die Wahl zwischen Unified, Plain und FVH Highlighter sowie die Feinjustierung von Fragment-Size entscheiden darüber, ob die Hervorhebung tatsächlich hilfreich oder nur ablenkend wirkt.