Seite 3 - Elasticsearch

Wer eine neue Suchloesung fuer einen Magento-Shop plant, steht vor einer Grundsatzentscheidung: Self-Hosted Elasticsearch oder OpenSearch mit voller Kontrolle und eigenem Betriebsaufwand, oder eine SaaS-Suchloesung wie Algolia oder Klevu mit nutzungsbasierten Kosten und weniger Infrastrukturarbeit. Dieser Artikel vergleicht Kosten, Kontrolle, Features und Integrationsaufwand aller drei Optionen konkret fuer Magento-Haendler.

Ein Array von Objekten sieht in JSON harmlos aus, wird aber je nach gewaehltem Feldtyp intern vollkommen unterschiedlich gespeichert. Der Standardtyp object macht die Struktur flach und verliert dabei die Zuordnung zwischen Feldern verschiedener Array-Eintraege, was zu Treffern fuehrt, die eigentlich keine sein duerften. Nested bewahrt genau diese Beziehung, kostet dafuer aber mehr Ressourcen.

Legacy-Shops auf Magento 1 oder frueher Magento-2-Basis nutzen oft noch Solr als Suchtechnologie, obwohl Solr seit Magento 2.4 nicht mehr unterstuetzt wird. Die Such-Migration von Solr zu Elasticsearch oder OpenSearch betrifft Schema, Reindex-Prozess und Frontend-Verhalten gleichermassen. Dieser Artikel liefert eine vollstaendige Checkliste, ein Schema-Mapping und einen Rollback-Plan fuer eine risikoarme Umstellung.

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.

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.

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.

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.