Elasticsearch-Suchfehler: Anti-Patterns

Kritische Gestaltungsfehler bei Elasticsearch-Suchen (und wie Sie sie vermeiden)

In Elasticsearch-Suchprojekten wiederholen Engineering-Teams immer wieder dieselben grundlegenden Fehler. Diese Probleme treten unabhängig von der Erfahrung des Teams in allen Systemen auf. Dieser Artikel analysiert sie als Anti-Patterns: bewährte Vorgehensweisen, die garantiert zu schlechterer Performance, geringerer Relevanz und höheren Betriebskosten führen.

Frühzeitiges Erkennen dieser Muster ist entscheidend für Entwickler mittlerer und höherer Erfahrungsstufe. Obwohl die Beispiele sich auf Elasticsearch konzentrieren, gelten die Prinzipien universell – für Solr, OpenSearch oder maßgeschneiderte Suchstacks.

Datenqualität ignorieren

Suche beginnt mit Inhalten – nicht mit Algorithmen. Schmutzige Daten sind der häufigste Grund für das Scheitern von Suchsystemen. Duplikate, unstrukturierte Texte und inkonsistente Formate untergraben die Relevanz direkt.

Häufige Probleme:

• Keine Normalisierung von Produktbezeichnungen (z. B. „iPhone 14“ vs. „Apple iPhone14“).
• Ungeprüfte Beschreibungen voller Tippfehler und überflüssiger Sonderzeichen.
• Doppelte Datensätze ohne Deduplizierung.

Die Verbesserung der Datenqualität wirkt stärker als jede Feinabstimmung der Ranking-Logik. Diese Aufgabe fällt oft Junior-Entwicklern zu – erfordert aber einen systemischen Ansatz: robuste ETL-Pipelines, Validierung zum Zeitpunkt des Datenimports und kontinuierliches Monitoring der Index-Qualität.

Ohne saubere Daten retten auch BM25 oder neuronale Reranker Sie nicht. In der Praxis entfallen 70–80 % des Aufwands auf die Datenqualität – nicht auf die Abfrage-Logik.

Anforderungen und Metriken nicht definieren

„Machen Sie es wie Yandex“ ist ein klassisches, vages Anforderungsdokument. Ohne dokumentierte, messbare Ziele wird die Suche subjektiv – und Teams vernachlässigen die Definition geschäftlicher Kennzahlen: Top-K-Relevanz, Null-Treffer-Rate oder Click-Through-Rate.

Wichtige Bewertungsmetriken:

• Precision@K – Anteil relevanter Dokumente unter den ersten K Ergebnissen.
• Recall@K – Anteil aller relevanten Dokumente, die unter den ersten K Ergebnissen erscheinen.
• NDCG – Positionsabhängige Relevanzbewertung mit gestufter Relevanz.
• CTR und Konversionsrate, gemessen pro Suchsession.
• Latenz und QPS, unter realistischer Last.

Manuelle Auswertung häufiger Suchanfragen ersetzt kein A/B-Testing oder Offline-Metriken. Ohne diese bleiben Regressionen unbemerkt: Rankings verschlechtern sich schleichend, Nutzer geben die Suche stillschweigend auf.

Die „Königsabfrage“: Monolith versus Skalierbarkeit

Eine einzige monolithische Abfrage, die Filterung, Aggregationen, Ranking und Paginierung abdeckt, ist ein weit verbreitetes Anti-Pattern. Ihr Reiz scheint offensichtlich: Konsistenz, weniger Netzwerkaufrufe. Doch die Kosten sind hoch.

Nachteile des Monoliths:

• Ausführungszeit >1 s bei komplexen Abfragen.
• Pflegeaufwand: Ein neues Feature erzwingt eine komplette Neustrukturierung der Abfrage.
• Sharding und Replikation werden ineffizient durch Abfragengröße und Ressourcenbelastung.

| Ansatz | Latenz | Wartbarkeit | Konsistenz |

|--------|--------|-------------|------------|

| Königsabfrage | 1–3 s | Gering | Hoch |

| Mikroabfragen + Caching | 50–200 ms | Hoch | Mittel (mit Cache) |

Teilen Sie die Suche in Phasen auf: Match + Filter → Anreichern → Reranken. Nutzen Sie ESQL oder Ingest-Pipelines zur Optimierung.

Fuzzy-Suche als Allheilmittel

Die Annahme, dass fuzziness automatisch Tippfehler korrigiert, ist ein weitverbreiteter Elasticsearch-Mythos. Für eine Abfrage wie „apliphone“ generiert Elasticsearch Hunderte Varianten – „applesiphone“, „aplfone“ usw.

Folgen:

• Recall steigt, doch Precision bricht ein.
• Relevanz leidet: Störrauschen dominiert die Top-Ergebnisse.
• Abfragekosten vervielfachen sich um das 10–50-Fache.

Parameter-Tuning behebt nicht die Ursache:

{
  "query": {
    "multi_match": {
      "query": "apliphone",
      "fuzziness": "AUTO",
      "prefix_length": 2,
      "max_expansions": 50
    }
  }
}

prefix_length=2 reduziert zwar das Rauschen – löst aber das Kernproblem nicht. Bessere Lösungen: Client-seitige Rechtschreibkorrektur (Hunspell/Yandex.Speller) und Synonymgraphen, die bereits beim Import angewendet werden.

Geschachtelte Objekte und Joins im Index

E-Commerce benötigt Beziehungen: Produkt → Preis → Lagerbestand → Bewertungen. Eine Normalisierung über Parent-Child-Joins wirkt logisch – zerstört aber die Performance.

Probleme mit has_child/parent:

• Tiefe Paginierung funktioniert gar nicht mehr.
• Scoring aggregiert Beziehungen nicht korrekt.
• Schemaänderungen erzwingen eine vollständige Neuindexierung.

Empfehlungen:

• Denormalisierung: Preis und Lagerbestand direkt ins Produkt-Dokument einbetten.
• Separate Indizes nutzen (z. B. goods, prices) und Joins clientseitig durchführen.
• nested-Felder nur für eng gekoppelte, niedrig-kardinalitätsreiche Daten reservieren.

Wichtigste Erkenntnisse

• Daten > Algorithmen: 80 % der Suchqualität stammen aus der Datenqualität.
• Metriken sind zwingend: Precision, Recall und NDCG müssen für jeden Anwendungsfall verfolgt werden.
• Abfragen zerlegen: Die Königsabfrage garantiert Latenzen über 2 s.
• Fuzzy sparsam einsetzen: Nur für seltene Begriffe – und immer mit Rechtschreibkorrektur kombinieren.
• Aggressiv denormalisieren: Joins in Elasticsearch sind ein echtes Anti-Pattern für Produktionssysteme.

— Editorial Team