Produktsuche, die sitzt: OpenSearch mit Autocomplete, Facetten und robuster Indizierung

Index-Mapping und Analyzer: Hier entscheidet sich die Suchqualität

Die Suchqualität wird nicht im Frontend gebaut, sondern im Index-Mapping. Drei Bausteine haben sich als entscheidend erwiesen:

Edge-Ngram für Autocomplete. Damit "Dich" schon den Dichtungsring vorschlägt, wird jeder Produktname beim Indizieren in Präfix-Fragmente zerlegt: "Di", "Dic", "Dich" und so weiter. Die Rechenarbeit passiert einmal beim Indizieren – die Suchanfrage selbst ist dann ein simpler, schneller Lookup. Wichtig: Der Search-Analyzer darf die Ngram-Zerlegung nicht wiederholen, sonst matcht "Dichtung" plötzlich auf alles, was mit "Di" beginnt.

Multi-Fields. Dasselbe Feld wird mehrfach indiziert, für unterschiedliche Zwecke: einmal als sprachanalysierter Volltext (mit Stemming für die Trefferliste), einmal als Autocomplete-Variante mit Edge-Ngram, einmal als keyword für exakte Matches und Sortierung. Eine Quelle, drei Sichten – ohne die Daten dreimal zu pflegen.

Asciifolding. "Müller" und "Mueller", "Résistance" und "Resistance": Sonderzeichen werden auf ihre ASCII-Basis normalisiert, bei Indizierung und Suche. Gerade bei mehrsprachigen Katalogen mit internationalen Nutzern ist das kein Nice-to-have, sondern Grundausstattung.

Vereinfacht sieht die Analyzer-Konfiguration so aus:

{
 "analysis": {
   "filter": {
     "autocomplete_ngram": {
       "type": "edge_ngram",
       "min_gram": 2,
       "max_gram": 20
     }
   },
   "analyzer": {
     "autocomplete_index": {
       "tokenizer": "standard",
       "filter": ["lowercase", "asciifolding", "autocomplete_ngram"]
     },
     "autocomplete_search": {
       "tokenizer": "standard",
       "filter": ["lowercase", "asciifolding"]
     }
   }
 }
}

Zwei Analyzer, ein Prinzip: Beim Indizieren werden die Ngram-Fragmente erzeugt, bei der Suche nicht. Tippfehlertoleranz für die Volltextsuche kommt zusätzlich über Fuzzy-Matching in der Query – mit Bedacht dosiert, denn zu viel Fuzziness produziert Treffer, die niemand versteht.

Facetten in einem eigenen Index

Ein Detail, das auf den ersten Blick übertrieben wirkt: Die Facetten (Kategorien, Attribute, Wertebereiche samt Trefferzahlen) leben in einem eigenen Index, getrennt vom Produkt-Index. Warum?

Facetten haben andere Anforderungen als Produkttreffer. Sie brauchen keine Textanalyse, keine Relevanz-Scores, kein Highlighting – sie brauchen exakte Werte und schnelle Aggregationen. Im gemeinsamen Index müsste jede Facetten-Änderung (etwa eine umbenannte Kategorie) ein Re-Indizieren aller betroffenen Produkte auslösen. Getrennt ist es ein Update in einem kleinen Index.

Dazu kommt die Mehrsprachigkeit: Facetten-Labels sind übersetzt, ihre zugrunde liegenden Werte nicht. Der Facetten-Index hält beides – den stabilen technischen Wert fürs Filtern, die übersetzten Labels fürs Anzeigen. Die Produktdokumente referenzieren nur den technischen Wert. Das hält den Produkt-Index schlank und die Übersetzungspflege an einer Stelle.

Robustheit: Der unsexy Teil, der den Unterschied macht

Eine Suche, die zu 99% läuft, ist eine Suche, die regelmäßig kaputt ist. Drei Mechanismen sorgen dafür, dass das System auch dann funktioniert, wenn etwas schiefgeht:

Fehlerbehandlung pro Dokument. Wie beim PIM-Sync gilt: Ein fehlerhaftes Produkt bricht nie den Bulk-Import ab. Fehler werden gesammelt, geloggt und gemeldet – der Rest des Laufs geht durch.

Re-Index über Alias-Switch. Ändert sich das Mapping (neuer Analyzer, neues Feld), wird nicht der Live-Index umgebaut. Stattdessen entsteht ein komplett neuer Index, der im Hintergrund voll aufgebaut wird. Erst wenn er fertig und geprüft ist, zeigt der Alias – der Name, unter dem das Frontend sucht – auf den neuen Index. Der Wechsel ist atomar, die Suche hat null Downtime, und wenn etwas nicht stimmt, zeigt der Alias in Sekunden wieder auf den alten Stand.

Monitoring auf Symptome, nicht nur auf Technik. CPU und Speicher überwacht AWS von Haus aus. Interessanter sind fachliche Signale: Wie alt ist der letzte erfolgreiche Sync-Lauf? Weicht die Dokumentenzahl im Index plötzlich stark vom Sollwert ab? Wie viele Suchanfragen liefern null Treffer? Gerade die Null-Treffer-Quote ist doppelt wertvoll – sie zeigt technische Probleme und Lücken im Sortiment oder in den Suchbegriffen der Nutzer.

Diese Signale laufen als Alarme in den Kanal, in dem das Team ohnehin arbeitet. Der Unterschied zwischen "die Suche war drei Tage kaputt und der Kunde hat es gemerkt" und "der Sync ist heute Nacht fehlgeschlagen und lief vor dem Frühstück wieder" ist kein technischer – es ist die Frage, ob jemand hinschaut, bevor es der Nutzer tut.

Zusammenspiel mit Cloudflare: Schnell wird erst richtig schnell

OpenSearch antwortet schnell – aber die schnellste Anfrage ist die, die gar nicht erst beim Cluster ankommt. Vor dem Such-Endpoint sitzt Cloudflare als Caching-Layer: Autocomplete-Anfragen sind hochgradig repetitiv ("di", "dic", "dich" tippen viele Nutzer), die Antworten ändern sich aber nur, wenn der Index sich ändert. Kurze Cache-Zeiten von wenigen Minuten reichen, um einen Großteil der Requests am Edge zu beantworten – für den Nutzer fühlt sich das an wie eine lokale Anwendung.

Wichtig dabei: Cache-Invalidierung und Sync-Intervall müssen zusammenpassen. Ein frisch indiziertes Produkt, das eine Stunde im Cache-Schatten hängt, macht den schnellsten Sync wertlos. Bei uns gilt: Cache-TTL deutlich kürzer als das Sync-Intervall, fertig.