Search-as-you-type in Elasticsearch performant umsetzen

1. Was search_as_you_type technisch anders macht

Der Feldtyp search_as_you_type, eingeführt in Elasticsearch 7.2, wurde speziell für Type-Ahead-Suchszenarien entwickelt, bei denen mit jedem zusätzlichen Zeichen der Nutzereingabe eine neue Anfrage an den Suchindex geschickt wird. Anders als eine klassische Volltextsuche, die auf vollständige Wörter oder Phrasen optimiert ist, muss search_as_you_type mit unvollständigen, sich ständig ändernden Präfixen effizient umgehen können, und zwar bei potenziell mehreren Anfragen pro Sekunde und Nutzer.

Technisch löst search_as_you_type dieses Problem, indem beim Indexieren automatisch mehrere Sub-Felder mit unterschiedlichen N-Gram-Shingle-Kombinationen erzeugt werden, die zusammen eine effiziente Prefix-Suche über mehrere Wörter hinweg ermöglichen. Diese Vorverarbeitung beim Indexieren ist der entscheidende Unterschied zu naiven Ansätzen wie wildcard Queries, die zur Laufzeit jeden Term im Index durchsuchen müssten, statt auf vorbereitete Strukturen zurückzugreifen.

Der Preis für diese Performance ist zusätzlicher Speicherbedarf im Index, weil mehrere Sub-Felder parallel gepflegt werden. Wer search_as_you_type performant umsetzen will, muss diesen Tradeoff verstehen und bewusst gegen Latenz-Anforderungen und verfügbaren Speicher abwägen, statt den Feldtyp unreflektiert auf jedes durchsuchbare Feld anzuwenden.

2. Der Feldtyp im Detail: Sub-Felder und deren Zweck

Beim Anlegen eines search_as_you_type Feldes erzeugt Elasticsearch automatisch vier zusammengehörige Felder: das Hauptfeld selbst, sowie _2gram, _3gram und ein _index_prefix Sub-Feld. Die Shingle-Sub-Felder _2gram und _3gram enthalten Kombinationen aus zwei beziehungsweise drei aufeinanderfolgenden Wörtern, was mehrwortige Präfix-Treffer wie "wander schu" für "Wanderschuhe" effizient ermöglicht. Das _index_prefix Sub-Feld enthält zusätzlich Edge N-Gramme für das letzte Wort der Eingabe, um auch unvollständige Wortenden performant zu matchen.

Diese vier Felder werden nicht manuell befüllt, sondern automatisch aus dem Hauptfeldwert abgeleitet, was den Konfigurationsaufwand gegenüber einem manuell gebauten Edge N-Gram Analyzer erheblich reduziert. Der Speicherbedarf dieser Struktur liegt üblicherweise zwischen dem Faktor 1,5 und 3 gegenüber einem einfachen text-Feld, abhängig von der durchschnittlichen Wortanzahl pro Dokument und der Länge der einzelnen Wörter.

PUT /produkte
{
  "mappings": {
    "properties": {
      "titel": {
        "type": "search_as_you_type",
        "max_shingle_size": 3
      }
    }
  }
}

# Erzeugt automatisch:
# titel            (Hauptfeld, Standard-Analyzer)
# titel._2gram     (Zwei-Wort-Shingles)
# titel._3gram     (Drei-Wort-Shingles)
# titel._index_prefix (Edge N-Gramme des letzten Wortes)

PUT /produkte/_doc/1
{
  "titel": "Wanderschuhe fuer den Gebirgstrail"
}

Der Parameter max_shingle_size steuert, wie viele Sub-Felder erzeugt werden, standardmäßig drei. Eine Reduktion auf zwei spart Speicher, verringert aber die Trefferqualität bei Eingaben mit drei oder mehr Wörtern. Eine Erhöhung über drei hinaus ist selten sinnvoll, weil die meisten Type-Ahead-Eingaben in der Praxis selten mehr als drei zusammenhängende Wörter umfassen, bevor der Nutzer ohnehin einen Vorschlag auswählt.

3. Query-Syntax: bool_prefix richtig einsetzen

Die Abfrage eines search_as_you_type Feldes erfolgt über multi_match mit dem speziellen Typ bool_prefix, der intern die Eingabe gegen alle relevanten Sub-Felder gleichzeitig matcht und dabei automatisch das jeweils passende Feld für die aktuelle Eingabelänge bevorzugt. Wichtig ist, alle vier zusammengehörigen Felder explizit in der fields-Liste anzugeben, weil sonst die volle Performance-Optimierung des Feldtyps ungenutzt bleibt.

Das letzte angegebene Feld in der Liste sollte immer _index_prefix sein, weil dieses Feld speziell für das letzte, potenziell unvollständige Wort der Eingabe zuständig ist. Wird es weggelassen, kann Elasticsearch das letzte Wort nur als vollständigen Term matchen, nicht als Präfix, was bei einer laufenden Type-Ahead-Eingabe zu deutlich schlechteren Ergebnissen führt.

GET /produkte/_search
{
  "query": {
    "multi_match": {
      "query": "wander sch",
      "type": "bool_prefix",
      "fields": [
        "titel",
        "titel._2gram",
        "titel._3gram",
        "titel._index_prefix"
      ]
    }
  }
}

Ein häufiger Konfigurationsfehler ist, nur das Hauptfeld titel in der fields-Liste anzugeben und die Shingle-Sub-Felder wegzulassen, in der Annahme, dass Elasticsearch diese automatisch berücksichtigt. Das ist nicht der Fall: Ohne explizite Angabe der Sub-Felder wird lediglich eine normale Prefix-Suche auf dem Hauptfeld ausgeführt, ohne die Vorteile der Shingle-Struktur für mehrwortige Präfixe zu nutzen.

4. Performance-Tradeoffs von Prefix-Matching

Prefix-Matching mit search_as_you_type ist deutlich schneller als naive Wildcard-Queries, aber nicht kostenlos. Jede zusätzliche Sub-Feld-Ebene erhöht sowohl den Indexspeicher als auch die Indexierungszeit, weil bei jedem Dokument-Update alle vier Felder neu berechnet und geschrieben werden müssen. Bei Anwendungen mit sehr hoher Schreibfrequenz, etwa Produktkatalogen mit permanenten Preis- und Bestandsänderungen, kann dieser zusätzliche Indexierungsaufwand spürbar werden, besonders wenn das search_as_you_type Feld unnötigerweise auf häufig aktualisierten Dokumenten liegt.

Eine bewährte Optimierung ist, search_as_you_type ausschließlich auf den Feldern zu aktivieren, die tatsächlich für Type-Ahead relevant sind, typischerweise Titel oder Produktname, statt es pauschal auf alle Textfelder anzuwenden. Zusätzlich lohnt sich eine Begrenzung der Eingabelänge über max_shingle_size und eine bewusste Wahl der size-Begrenzung in der Query, weil eine hohe Trefferanzahl bei jedem Tastenanschlag unnötige Serialisierungs- und Netzwerklast erzeugt.

GET /produkte/_search
{
  "size": 8,
  "query": {
    "multi_match": {
      "query": "wander sch",
      "type": "bool_prefix",
      "fields": ["titel", "titel._2gram", "titel._3gram", "titel._index_prefix"]
    }
  },
  "_source": ["titel", "bild_url"]
}

Die Begrenzung auf _source: ["titel", "bild_url"] reduziert die übertragene Datenmenge auf das Nötigste für eine Type-Ahead-Anzeige, statt das komplette Dokument mit allen Feldern zurückzugeben. Bei Type-Ahead-Endpunkten mit hoher Anfragefrequenz summiert sich diese Reduktion zu einer spürbaren Netzwerk- und Serialisierungsersparnis.

5. Shard-Größe und Latenz bei Type-Ahead-Queries

Type-Ahead-Endpunkte reagieren besonders empfindlich auf eine ungünstige Shard-Verteilung, weil jede einzelne Anfrage eine niedrige Latenz-Anforderung von typischerweise unter 100 Millisekunden hat, während eine normale Suche etwas mehr Spielraum erlaubt. Bei einem Index mit vielen kleinen Shards summiert sich der Overhead für das Zusammenführen von Teilergebnissen über alle Shards hinweg, was bei niedrigen Latenz-Budgets ins Gewicht fällt. Zu wenige, dafür sehr große Shards wiederum verlangsamen die einzelne Shard-Suche selbst, weil mehr Daten pro Shard durchsucht werden müssen.

Für Type-Ahead-optimierte Indizes hat sich in der Praxis eine geringere Anzahl mittelgroßer Shards bewährt, häufig in Kombination mit einem dedizierten, kleineren Index nur für die Autocomplete-relevanten Felder, getrennt vom Haupt-Suchindex mit allen durchsuchbaren Feldern. Dieser separate Index kann kleiner dimensioniert und aggressiver für niedrige Latenz optimiert werden, während der Haupt-Suchindex für komplexere Relevanz-Anforderungen zuständig bleibt.

PUT /produkte_typeahead
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 2,
    "refresh_interval": "5s"
  },
  "mappings": {
    "properties": {
      "titel": { "type": "search_as_you_type" },
      "bild_url": { "type": "keyword", "index": false }
    }
  }
}

Ein dedizierter Type-Ahead-Index mit reduziertem Feldumfang und angepasstem refresh_interval kann deutlich niedrigere Latenzen liefern als eine Anfrage gegen den vollständigen Produktindex mit Dutzenden zusätzlichen Feldern, weil weniger Daten pro Shard verwaltet und durchsucht werden müssen. Zusätzliche Replicas erhöhen die Lesekapazität für Type-Ahead-Anfragen, die typischerweise ein deutlich höheres Anfragevolumen als normale Suchanfragen erzeugen.

6. Debouncing im Frontend: Query-Last strukturell reduzieren

Selbst der performanteste Elasticsearch-Index kann eine schlechte Frontend-Implementierung nicht kompensieren. Ohne Debouncing feuert ein Type-Ahead-Eingabefeld bei jedem einzelnen Tastenanschlag eine neue Anfrage, was bei einem durchschnittlichen Tippverhalten von fünf bis acht Zeichen pro Sekunde zu einer unnötig hohen Anzahl paralleler oder schnell aufeinanderfolgender Requests führt, von denen die meisten durch die nächste Eingabe sofort obsolet werden.

Debouncing verzögert das Absenden der Anfrage um eine kurze, konfigurierbare Zeitspanne, typischerweise 150 bis 300 Millisekunden, und sendet nur dann tatsächlich eine Anfrage, wenn der Nutzer innerhalb dieser Zeitspanne keine weitere Eingabe macht. Das reduziert die Anzahl der tatsächlich an Elasticsearch gesendeten Anfragen drastisch, ohne die gefühlte Reaktionsgeschwindigkeit für den Nutzer spürbar zu verschlechtern, da 150 bis 300 Millisekunden unterhalb der menschlichen Wahrnehmungsschwelle für "sofortige" Reaktion liegen.

// Debouncing im Frontend mit Alpine.js (Pseudocode-Prinzip)
// Verzoegert die Anfrage, bis 200ms lang keine neue Eingabe erfolgt

function typeahead() {
  return {
    query: '',
    results: [],
    debounceTimer: null,

    onInput() {
      clearTimeout(this.debounceTimer);
      this.debounceTimer = setTimeout(() => {
        this.fetchSuggestions();
      }, 200);
    },

    async fetchSuggestions() {
      if (this.query.length < 2) {
        this.results = [];
        return;
      }
      const response = await fetch(`/api/typeahead?q=${encodeURIComponent(this.query)}`);
      this.results = await response.json();
    }
  };
}

Zusätzlich zum reinen Debouncing verhindert eine AbortController-Logik, dass veraltete Antworten eine bereits neuere Anfrage überschreiben: Wird eine neue Anfrage gestartet, während die vorherige noch läuft, wird die vorherige Anfrage aktiv abgebrochen, statt beide Antworten ungeordnet ankommen zu lassen. Ohne diese Absicherung kann eine langsame, veraltete Antwort eine schnellere, aktuellere Antwort im UI überschreiben und dem Nutzer falsche Vorschläge anzeigen.

7. Caching-Strategien für wiederkehrende Präfixe

Type-Ahead-Eingaben folgen einem charakteristischen Muster: Kurze, häufige Präfixe wie "a", "wa" oder "wan" werden von vielen unterschiedlichen Nutzern wiederholt angefragt, während lange, spezifische Präfixe seltener und individueller sind. Dieses Muster eignet sich hervorragend für Caching auf mehreren Ebenen. Der request_cache von Elasticsearch selbst cacht Ergebnisse für identische Queries auf Shard-Ebene, hilft aber wenig bei sich ständig ändernden Nutzereingaben, weil die Query bei jedem zusätzlichen Zeichen anders lautet.

Effektiver ist ein dediziertes Caching auf Anwendungsebene, etwa mit Redis, das die häufigsten zwei- bis dreistelligen Präfixe und ihre Top-Ergebnisse separat vorhält und bei einem Cache-Hit die Elasticsearch-Anfrage komplett umgeht. Da diese kurzen Präfixe statistisch einen unverhältnismäßig großen Anteil aller Type-Ahead-Anfragen ausmachen, kann ein solcher Cache-Layer die tatsächliche Last auf den Elasticsearch-Cluster erheblich reduzieren, während lange, spezifische Präfixe weiterhin direkt gegen den Index laufen.

8. search_as_you_type vs. Completion Suggester: Wann was

Die Wahl zwischen search_as_you_type und dem Completion Suggester ist keine reine Geschmacksfrage, sondern hängt von konkreten Anforderungen ab. search_as_you_type ist die richtige Wahl, wenn die Type-Ahead-Suche mit normalen Filtern, Aggregationen oder Bool-Queries kombiniert werden muss, etwa um nur Produkte einer bestimmten Kategorie oder eines bestimmten Lagerbestands vorzuschlagen. Der Completion Suggester ist überlegen, wenn absolute Minimal-Latenz das wichtigste Kriterium ist und keine komplexe Filterlogik benötigt wird, weil seine In-Memory-FST-Struktur strukturell schneller ist als eine reguläre invertierte Index-Suche.

In der Praxis entscheiden sich viele Teams für search_as_you_type als pragmatischen Standardweg, weil die Integration in die reguläre Query-Infrastruktur den langfristigen Wartungsaufwand reduziert und die Performance bei korrekter Shard- und Caching-Konfiguration für die allermeisten Anwendungsfälle völlig ausreichend ist. Der Completion Suggester bleibt die richtige Wahl für Nischenanwendungen mit extrem hohem Anfragevolumen und einfachen, unfilterten Vorschlagslisten.

9. Monitoring und Lasttests für Type-Ahead-Endpunkte

Type-Ahead-Endpunkte erzeugen ein deutlich anderes Lastprofil als normale Suchanfragen: hohes Anfragevolumen, kurze Query-Strings, hohe Redundanz zwischen aufeinanderfolgenden Anfragen desselben Nutzers. Ein Monitoring, das nur die durchschnittliche Latenz über alle Endpunkte hinweg misst, verschleiert häufig Latenz-Spitzen speziell bei Type-Ahead-Anfragen, weil deren absolute Anzahl den Durchschnitt anderer, selteneren Endpunkte dominieren kann. Ein separates Latenz-Dashboard nur für den Type-Ahead-Endpunkt mit p50, p95 und p99 Perzentilen ist deutlich aussagekräftiger als ein globaler Durchschnittswert.

Für Lasttests eignet sich ein Szenario, das reale Tippgeschwindigkeit simuliert, statt alle möglichen Präfixe gleichzeitig und ohne Verzögerung abzufragen. Ein realistisches Lasttest-Szenario sendet für jeden simulierten Nutzer eine Sequenz von Anfragen mit steigender Präfixlänge und einer Verzögerung von 100 bis 200 Millisekunden zwischen den Anfragen, um das tatsächliche Debouncing-Verhalten und die reale Lastcharakteristik nachzubilden. Nur so lassen sich realistische Aussagen über die Belastbarkeit der Type-Ahead-Infrastruktur unter Produktionslast treffen.

10. Zusammenfassung

Eine performante search_as_you_type Implementierung besteht aus mehreren zusammenwirkenden Ebenen. Der Feldtyp selbst erzeugt automatisch Shingle-Sub-Felder für effizientes mehrwortiges Prefix-Matching, muss aber korrekt über bool_prefix mit allen vier Sub-Feldern abgefragt werden, um seine volle Performance zu entfalten. Ein dedizierter, kleiner Type-Ahead-Index mit angepasster Shard-Konfiguration reduziert Latenz gegenüber einer Anfrage gegen den vollständigen Produktindex erheblich.

Frontend-seitiges Debouncing mit 150 bis 300 Millisekunden Verzögerung und eine AbortController-Logik gegen veraltete Antworten sind unverzichtbar, um die Anzahl tatsächlich gesendeter Anfragen strukturell zu reduzieren. Ein Redis-basierter Cache für häufige, kurze Präfixe entlastet den Elasticsearch-Cluster zusätzlich. Wer search_as_you_type performant umsetzen will, sollte alle diese Ebenen gemeinsam betrachten, nicht nur die Elasticsearch-Konfiguration isoliert.

11. FAQ: Search-as-you-type performant umsetzen