Multi-Field-Mapping-Strategien fuer flexible Abfragen

1. Das Grundproblem: ein Wert, mehrere widerspruechliche Anforderungen

Ein einzelnes Textfeld wie ein Produktname muss in der Praxis oft mehrere Anforderungen gleichzeitig erfuellen, die sich mit einem einzigen Feldtyp nicht abdecken lassen. Fuer die Volltextsuche muss der Wert analysiert und in einzelne Tokens zerlegt werden, damit eine Teilsuche funktioniert. Fuer Sortierung nach Produktname und fuer exakte Filterung nach genau diesem Namen wird dagegen der unveraenderte, exakte String gebraucht. Ein text-Feld allein kann Letzteres nicht leisten, ein keyword-Feld allein kann Ersteres nicht leisten.

Multi-Fields loesen genau dieses Problem, indem sie erlauben, einen einzigen Quellwert in mehreren parallelen Repraesentationen im selben Index zu speichern. Statt Kompromisse einzugehen oder Daten redundant in mehrere separate Felder zu schreiben, definiert man ein Haupt-Feld und zusaetzliche Sub-Felder, die beim Indexieren automatisch mit demselben Wert, aber unterschiedlicher Verarbeitung befuellt werden. Dieser Artikel zeigt, wie Multi-Fields konfiguriert werden, welche Strategien sich bewaehrt haben und wo die Grenzen liegen.

2. Was Multi-Fields sind und wie der fields-Parameter funktioniert

Multi-Fields werden ueber den fields-Parameter im Mapping eines Feldes definiert. Jedes Sub-Field innerhalb von fields hat einen eigenen Namen und eine eigene, vollstaendig unabhaengige Typ- und Analyzer-Konfiguration, wird aber automatisch mit demselben Eingabewert wie das Haupt-Feld befuellt. Es gibt keine separate Schreiblogik in der Anwendung: Ein einziger JSON-Wert im indexierten Dokument reicht aus, Elasticsearch kuemmert sich intern um die parallele Indexierung in allen konfigurierten Repraesentationen.

Technisch gesehen erzeugt jedes Sub-Field ein eigenes Lucene-Feld im zugrunde liegenden Segment, vollstaendig getrennt vom Haupt-Feld. Aus Anwendungssicht bleibt das Dokument aber ein einziges JSON-Objekt mit einem einzigen Schluessel. Diese Trennung von logischer Struktur im Quelldokument und physischer Struktur im Index ist der zentrale Vorteil von Multi-Fields gegenueber der Alternative, mehrere separate Top-Level-Felder mit redundantem Inhalt zu pflegen.

PUT /products
{
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "fields": {
          "keyword": { "type": "keyword", "ignore_above": 256 }
        }
      }
    }
  }
}

// A single value populates both representations automatically
POST /products/_doc
{ "name": "Wireless Kopfhoerer Pro" }
// name          -> analyzed tokens: wireless, kopfhoerer, pro
// name.keyword  -> exact string: "Wireless Kopfhoerer Pro"

3. Das klassische keyword-Sub-Field fuer Sortierung und Filter

Die mit Abstand haeufigste Anwendung von Multi-Fields ist die Kombination aus einem text-Haupt-Feld und einem keyword-Sub-Field, ueblicherweise feldname.keyword genannt. Diese Kombination ist so verbreitet, dass Elasticsearch sie bei aktiviertem Dynamic Mapping automatisch fuer jedes erkannte String-Feld anlegt, was zeigt, wie zentral dieses Muster fuer den praktischen Betrieb ist. Das Haupt-Feld name bleibt fuer Volltextsuche zustaendig, waehrend name.keyword fuer Sortierung, exakte Filterung und Aggregation genutzt wird.

Wichtig ist der Parameter ignore_above beim keyword-Sub-Field: Er verhindert, dass uebermaessig lange Strings, etwa versehentlich eingefuegter Volltext statt eines kurzen Namens, indexiert werden und den Index unnoetig aufblaehen. Werte, die die konfigurierte Zeichenlaenge ueberschreiten, werden im keyword-Sub-Feld einfach nicht indexiert, bleiben aber im Haupt-Feld weiterhin durchsuchbar. Das ist ein einfacher, aber wirksamer Schutzmechanismus gegen ungewoehnlich lange Eingabedaten.

4. Mehrere Analyzer auf demselben Feld kombinieren

Multi-Fields sind nicht auf die Kombination text plus keyword beschraenkt. Ein haeufiger fortgeschrittener Anwendungsfall ist, denselben Textwert mit zwei unterschiedlichen Analyzern zu indexieren, etwa einmal mit einem sprachspezifischen Analyzer fuer Stemming-basierte Suche und einmal mit einem einfacheren Analyzer ohne Stemming fuer exaktere Phrasensuche. Eine Suche kann dann gezielt gegen das passende Sub-Field ausgefuehrt werden, je nachdem, ob eine breite oder eine praezise Treffermenge gewuenscht ist.

Ein weiteres Muster ist die Kombination aus standard-Analyzer und einem asciifolding-Analyzer, der Akzente und Sonderzeichen normalisiert. So findet eine Suche nach "cafe" auch Dokumente mit "café", waehrend das Haupt-Feld weiterhin die praezisere, akzentsensitive Variante fuer Faelle bereithaelt, in denen die Unterscheidung relevant ist. Diese Kombinationen erlauben es, mehrere Suchqualitaets-Stufen im selben Query mit unterschiedlicher Gewichtung anzufragen, etwa ueber eine multi_match-Query mit mehreren Feldern und Boost-Faktoren.

PUT /articles
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "standard",
        "fields": {
          "stemmed": { "type": "text", "analyzer": "german" },
          "folded":  { "type": "text", "analyzer": "simple" }
        }
      }
    }
  }
}

// Query multiple representations with different weights
GET /articles/_search
{
  "query": {
    "multi_match": {
      "query": "Cafe Ecke",
      "fields": ["title^3", "title.stemmed^2", "title.folded"]
    }
  }
}

5. Autocomplete-Sub-Fields mit eigenem Tokenizer

Ein weiteres etabliertes Muster ist ein Sub-Field mit edge_ngram-Tokenizer fuer Autocomplete-Funktionen. Waehrend das Haupt-Feld ganze Woerter fuer normale Suche indexiert, zerlegt das Sub-Field name.autocomplete denselben Wert in ueberlappende Praefixe, sodass bereits nach den ersten drei bis vier eingegebenen Zeichen passende Vorschlaege erscheinen. Diese Technik erspart eine separate Suggest-Infrastruktur fuer viele einfache Autocomplete-Anwendungsfaelle.

Bei diesem Muster ist entscheidend, dass der edge_ngram-Tokenizer nur beim Indexieren angewendet wird, nicht bei der Suche selbst, da sonst auch der Suchbegriff in Praefixe zerlegt und mit sich selbst auf unerwartete Weise verglichen wuerde. Der Parameter search_analyzer auf dem Sub-Field wird deshalb typischerweise auf einen einfachen standard-Analyzer gesetzt, waehrend nur der Index-Analyzer die edge_ngram-Zerlegung vornimmt.

6. Multi-Fields in Queries ansprechen: die Punkt-Notation

In Queries werden Multi-Fields ueber die Punkt-Notation angesprochen, also feldname.subfeldname, wie bei name.keyword in einer term-Query oder sort-Klausel. Diese Notation ist rein syntaktisch fuer die Query-DSL und hat nichts mit einer tatsaechlich verschachtelten JSON-Struktur im Quelldokument zu tun, die weiterhin flach bleibt. Diese Trennung fuehrt gelegentlich zu Verwirrung bei Entwicklern, die neu mit Elasticsearch arbeiten, weil die Punkt-Notation an verschachtelte Objekte erinnert, obwohl hier ein einzelnes flaches Feld mit mehreren internen Repraesentationen gemeint ist.

Ein haeufiger Fehler ist der Versuch, ein Sub-Field direkt im Dokument beim Indexieren zu setzen, etwa {"name.keyword": "Wert"}. Das erzeugt tatsaechlich ein neues, separates Top-Level-Feld mit einem Punkt im Namen, nicht das gewuenschte Sub-Field. Multi-Fields werden ausschliesslich automatisch aus dem Wert des Haupt-Feldes befuellt und koennen beim Indexieren nicht direkt adressiert werden. Diese Regel zu kennen erspart eine der haeufigsten Verwirrungen im Umgang mit Multi-Field-Mapping.

7. Speicher- und Indexierungskosten von Multi-Fields

Jedes zusaetzliche Sub-Field verursacht eigene Speicher- und CPU-Kosten, weil es als vollstaendig separates Lucene-Feld indexiert wird. Bei einem Produktnamen mit zwei oder drei Sub-Feldern ist dieser Overhead meist vernachlaessigbar, kann aber bei sehr grossen Textfeldern, etwa vollstaendigen Artikelinhalten, die mit mehreren Analyzer-Varianten dupliziert werden, spuerbar werden. Ein Index mit fuenf Sub-Feldern auf einem langen Beschreibungstext verfuenffacht grob den Speicherbedarf und die Indexierungszeit fuer genau dieses Feld.

Die praktische Konsequenz: Multi-Fields sollten gezielt fuer Felder eingesetzt werden, bei denen tatsaechlich mehrere Abfragearten gebraucht werden, nicht pauschal fuer jedes Textfeld im Mapping. Ein reines Beschreibungsfeld, das nur durchsucht, aber nie sortiert oder aggregiert wird, braucht kein keyword-Sub-Field. Diese bewusste Abwaegung zwischen Abfrageflexibilitaet und Ressourcenverbrauch ist Teil jeder durchdachten Mapping-Strategie.

8. Multi-Fields automatisch per Dynamic Template anlegen

Bei Indizes mit vielen aehnlich strukturierten Feldern, etwa Custom-Attributen in einem Produktkatalog, lohnt sich die Kombination aus Multi-Fields und Dynamic Templates. Statt fuer jedes neue String-Attribut manuell ein keyword-Sub-Field im Mapping zu ergaenzen, definiert ein Dynamic Template automatisch, dass jedes neu erkannte String-Feld mit einem keyword.raw-Sub-Field ausgestattet wird. Neue Attribute erhalten so ohne manuellen Eingriff konsistente Multi-Field-Strukturen.

Diese Automatisierung reduziert Konfigurationsaufwand erheblich, sollte aber mit denselben Ueberlegungen zu Speicherkosten kombiniert werden wie ein manuell gepflegtes Mapping. Ein Dynamic Template, das jedem String automatisch mehrere teure Sub-Fields hinzufuegt, kann in Verbindung mit unkontrolliertem Dynamic Mapping zu einer Vervielfachung des ohnehin schon riskanten Feldwachstums fuehren. Die Kombination beider Techniken erfordert deshalb dieselbe Sorgfalt wie jede einzelne fuer sich.

PUT /catalog
{
  "mappings": {
    "dynamic_templates": [
      {
        "strings_with_keyword": {
          "match_mapping_type": "string",
          "mapping": {
            "type": "text",
            "fields": {
              "raw": { "type": "keyword", "ignore_above": 256 }
            }
          }
        }
      }
    ]
  }
}

9. Ein vollstaendiges Praxisbeispiel: Produktname mit drei Feldern

Ein realistisches Beispiel fasst die vorgestellten Techniken zusammen. Ein Produktname in einem Onlineshop soll drei Anforderungen gleichzeitig erfuellen: Volltextsuche ueber das Haupt-Feld mit standard-Analyzer, exakte Sortierung und Aggregation ueber ein keyword-Sub-Field, und Autocomplete-Vorschlaege waehrend der Eingabe ueber ein drittes Sub-Field mit edge_ngram-Tokenizer. Alle drei Repraesentationen entstehen aus demselben einzelnen JSON-Wert beim Indexieren, ohne dass die Anwendung mehrfach denselben Wert schreiben muss.

In der Suchoberflaeche kombiniert man diese drei Felder gezielt: Der Autocomplete-Vorschlag waehrend der Eingabe fragt name.autocomplete an, die eigentliche Suche nach Bestaetigung nutzt das Haupt-Feld name fuer breite Relevanz, und die Ergebnisliste sortiert bei Bedarf nach name.keyword fuer eine stabile, alphabetische Reihenfolge. Diese saubere Trennung nach Zweck ist der Kern jeder guten Multi-Field-Strategie: nicht moeglichst viele Sub-Felder anlegen, sondern genau die, die einem konkreten Abfragezweck dienen.

Fuer Magento-Betreiber mit dem Elasticsearch-Katalogindex ist relevant, dass die Standard-Indexierung bereits fuer viele Attribute automatisch Multi-Field-Strukturen anlegt, etwa fuer den Produktnamen. Wer eigene Custom-Attribute mit Volltextsuche und Sortierbarkeit gleichzeitig braucht, sollte pruefen, ob die generierte Mapping-Struktur bereits ein passendes Sub-Field enthaelt, bevor eine eigene Loesung ueber einen Plugin- oder Indexer-Eingriff entwickelt wird.

Diese Uebersicht zeigt vier bewaehrte Muster, die sich beliebig auf einem Feld kombinieren lassen. Der Schluessel ist, jedes Sub-Field bewusst fuer einen konkreten Abfragezweck einzurichten, statt vorsorglich alle moeglichen Varianten anzulegen und damit unnoetige Kosten zu erzeugen.

10. Zusammenfassung

Multi-Fields loesen den Zielkonflikt zwischen Volltextsuche, exakter Filterung, Sortierung und Aggregation auf demselben logischen Wert, indem sie eine einzige Quelle mehrfach parallel indexieren. Der fields-Parameter im Mapping macht das ohne Aenderung der Anwendungslogik moeglich: Ein einziger JSON-Wert genuegt, Elasticsearch kuemmert sich um die interne Vervielfaeltigung in verschiedene Repraesentationen.

Das klassische keyword-Sub-Field deckt den haeufigsten Fall ab, waehrend zusaetzliche Analyzer-Varianten und edge_ngram-Sub-Fields fortgeschrittenere Anforderungen wie mehrstufige Relevanz oder Autocomplete abdecken. Da jedes Sub-Field Speicher- und Indexierungskosten verursacht, sollten Multi-Fields gezielt fuer tatsaechliche Abfrageanforderungen eingesetzt werden, nicht pauschal fuer jedes Feld im Mapping.

11. FAQ: Multi-Field-Mapping in Elasticsearch