Elasticsearch

Eine technisch korrekte Suche, die trotzdem die falschen Produkte zuerst zeigt, kostet Umsatz, ohne dass es im Fehlerlog auftaucht. Suchrelevanz in Magento 2 zu tunen bedeutet, die zugrunde liegende multi_match-Query zu verstehen, Attribute gezielt zu gewichten und Business-Signale wie Verkaufszahlen und Lagerbestand aktiv in die Sortierung einfließen zu lassen.

Eine Suche, die "Laptop" findet, aber bei "Notebook" leer ausgibt, oder die "laufen" und "gelaufen" als völlig verschiedene Wörter behandelt, verliert Nutzer schon vor dem ersten Klick. Synonyme und Stemming lösen genau dieses Problem, wenn sie im Analyzer korrekt kombiniert werden, doch die Details bei synonym_graph, Stemmer-Typ und Sprachauswahl entscheiden darüber, ob die Suche präziser oder nur unschärfer wird.

Der Frozen Tier stellt eine radikal andere Frage als die übrigen ILM-Phasen: Warum sollten selten abgefragte Daten überhaupt dauerhaft Speicherplatz auf Cluster-Knoten belegen? Statt Daten vollständig im Cluster vorzuhalten, liegen sie im Frozen Tier ausschließlich als searchable Snapshot in günstigem Objekt-Speicher und werden nur bei einer tatsächlichen Abfrage gezielt nachgeladen. Das senkt die Speicherkosten drastisch, verlangt im Gegenzug aber, den Latenz-Trade-off bewusst zu akzeptieren.

Force Merge ist eine der wirkungsvollsten und gleichzeitig gefährlichsten Wartungsaktionen in Elasticsearch. Richtig eingesetzt, auf abgeschlossenen, nicht mehr beschriebenen Indizes, verdichtet Force Merge fragmentierte Lucene-Segmente und beschleunigt nachfolgende Leseabfragen spürbar. Falsch eingesetzt, auf einem noch aktiv beschriebenen Index, erzeugt dieselbe Aktion eine massive I/O-Spitze, die die Schreibperformance und damit den gesamten Cluster empfindlich stören kann.

Der Standardanalyzer von Elasticsearch behandelt jede Sprache gleich und ignoriert damit Stammformen, Stopwoerter und Sonderzeichen, die fuer Deutsch, Franzoesisch oder Englisch jeweils vollstaendig unterschiedlich sind. Ein Custom Analyzer pro Sprache, kombiniert mit einer Per-Field-per-Language-Mapping-Strategie, macht aus einer generischen Volltextsuche eine Suche, die in jeder Shop-Sprache tatsaechlich die passenden Treffer liefert.

Die Bool Query ist das zentrale Werkzeug der Elasticsearch Query DSL, um mehrere Bedingungen logisch zu verknuepfen. Wer must, should, must_not und filter versteht und weiss, wann Scoring-Kontext gegenueber Filter-Kontext greift, baut Suchanfragen, die sowohl praezise als auch schnell sind, statt einfach alle Klauseln in einen Topf zu werfen und auf gute Ergebnisse zu hoffen.

Die Standard-Relevanz der Magento-Suche behandelt jedes Attribut nach denselben Regeln, unabhaengig davon, ob eine Suchanfrage nach SKU, Marke oder Beschreibung sucht. Wer die Such-Relevanz gezielt ueber Search-Weight, eigene Query-Builder und Function-Score-Boosting steuert, bringt die Produkte nach oben, die fuer den jeweiligen Shop tatsaechlich zaehlen.

BM25 ist der Standard-Scoring-Algorithmus von Elasticsearch und OpenSearch, doch die meisten Entwickler kennen nur den Namen, nicht die Mechanik dahinter. Termhaeufigkeit, inverse Dokumenthaeufigkeit und Feldlaengen-Normalisierung bestimmen gemeinsam, warum ein Dokument hoeher rankt als ein anderes, und wer diese drei Faktoren versteht, kann Relevanzprobleme gezielt diagnostizieren statt nur zu raten.

Sobald ein Produkt mehrere Varianten mit eigener Größe, Farbe und eigenem Preis besitzt, versagt die klassische Aggregation still und zählt falsch. Die nested Aggregation arbeitet auf einem separaten, isolierten Lucene-Index innerhalb des Parent-Dokuments und liefert dadurch korrekte Facetten auf Varianten-Ebene. Mit reverse_nested lässt sich zusätzlich wieder in den Parent-Kontext zurückspringen, um Facetten zu bauen, die sowohl Varianten- als auch Produktebene korrekt verbinden.

Dynamisches Mapping wirkt bequem, bis ein einziger Index tausende Felder ansammelt und der Cluster-State so gross wird, dass jede Mapping-Aenderung spuerbar langsamer laeuft. Mapping-Explosion entsteht meist schleichend aus key-value-artigen Datenstrukturen, die ungebremst neue Felder erzeugen, und laesst sich mit klaren Limits, gezieltem dynamic:false und dem flattened-Datentyp zuverlaessig verhindern, bevor sie zum Produktionsproblem wird.