Seite 3 - Elasticsearch

Eine ILM-Richtlinie beschreibt nicht nur, wie lange ein Index leben soll, sondern welche konkrete Aktion in welcher Phase auf ihn angewendet wird: Rollover in der Hot-Phase, Shrink und Force Merge beim Übergang in die Warm-Phase, Replikaten-Reduktion in der Cold-Phase und schließlich die endgültige Löschung. Wer diese Bausteine versteht und richtig verzahnt, bekommt eine Datenverwaltung, die ohne manuelles Eingreifen läuft und trotzdem exakt zum tatsächlichen Zugriffsmuster der Daten passt.

Klassische Textsuche findet Dokumente, die dieselben Wörter enthalten wie die Anfrage. Sie erkennt aber nicht, dass eine Suche nach wasserdichter Jacke auch ein Produkt namens regenfeste Outdoor-Jacke treffen sollte, obwohl kein einziges Wort übereinstimmt. Vektorsuche löst genau dieses Problem: Texte werden als Embeddings, also als Punkte in einem hochdimensionalen Raum, dargestellt, und ähnliche Bedeutung ergibt räumliche Nähe. Die eigentliche Herausforderung beginnt danach, denn über Millionen Vektoren hinweg den nächsten Nachbarn zu finden ist teuer. Approximate kNN mit dem HNSW-Algorithmus löst dieses Skalierungsproblem, indem es einen kleinen Genauigkeitsverlust gegen enorme Geschwindigkeitsgewinne eintauscht. Dieser Artikel zeigt, wie HNSW technisch funktioniert, wo exaktes kNN weiterhin sein Einsatzgebiet hat und wie sich die zentralen Stellschrauben num_candidates und Similarity-Metrik in der Praxis konfigurieren lassen.

Bei Katalogen mit mehreren hunderttausend SKUs wird der catalogsearch_fulltext-Indexer schnell zum Flaschenhals im Betrieb: volle Reindex-Laeufe dauern Stunden, der Cron-Job blockiert andere Jobs, und PHP-Worker geraten an ihre Speichergrenze. Dieser Artikel zeigt, wie Batch Size, Partial-Reindex-Strategien und die Elasticsearch Bulk API zusammenspielen, um die Indexer-Performance bei grossen Katalogen spuerbar zu verbessern.

Ein Elasticsearch-Node, dem der Heap-Speicher ausgeht, reagiert nicht elegant: Statt einer kontrollierten Fehlermeldung droht im schlimmsten Fall ein kompletter Absturz des Node-Prozesses durch einen Out-of-Memory-Fehler der JVM, mit potenziellem Datenverlust und einem aufwändigen Recovery. Circuit Breaker sind Elasticsearchs eingebaute Verteidigungslinie gegen genau dieses Szenario: Sie überwachen den geschätzten Speicherverbrauch verschiedener Operationen und brechen eine Anfrage kontrolliert mit einer Fehlermeldung ab, statt die JVM tatsächlich an ihre Grenze zu bringen. Wer die verschiedenen Breaker-Typen, ihre typischen Auslöser und die richtige Diagnose bei einem ausgelösten Breaker versteht, kann Speicherprobleme erkennen, bevor sie zum kompletten Node-Ausfall eskalieren.

Wer taeglich neue Indizes fuer Logs, Metriken oder Bestellungen anlegt, kennt das Problem: ohne zentrale Vorgabe driften Mappings und Settings auseinander, bis Abfragen inkonsistente Ergebnisse liefern. Composable Index-Templates und wiederverwendbare Component-Templates loesen genau das, indem sie Mapping-Regeln einmal definieren und automatisch auf jeden neuen Index anwenden, der zu einem Namensmuster passt.

Reine Vektorsuche findet thematisch passende Ergebnisse, selbst wenn kein Wort der Anfrage im Dokument vorkommt, verliert aber gelegentlich exakte Begriffstreffer, etwa eine konkrete Artikelnummer oder einen Markennamen, die BM25 zuverlässig findet. Reine Textsuche wiederum übersieht semantisch passende, aber wörtlich abweichende Formulierungen komplett. Hybrid Search versucht, das Beste aus beiden Welten zu vereinen, indem zwei unterschiedliche Rankings, eines aus BM25 und eines aus Vektorsuche, zu einer gemeinsamen Ergebnisliste zusammengeführt werden. Die technische Herausforderung dabei ist, dass BM25-Scores und Vektor-Distanzwerte auf vollkommen unterschiedlichen, nicht vergleichbaren Skalen liegen. Reciprocal Rank Fusion löst dieses Problem elegant, indem es nicht die Scores selbst, sondern die relativen Rangpositionen kombiniert. Dieser Artikel erklärt, wie RRF funktioniert, wann Hybrid Search reiner Vektorsuche tatsächlich überlegen ist und wie sich das Ganze konkret in einer Elasticsearch-Suchanfrage

Langsame Magento-Suchanfragen bleiben ohne systematisches Monitoring oft unbemerkt, bis Kunden sich über träge Ladezeiten beschweren. Der Elasticsearch beziehungsweise OpenSearch Slow Log protokolliert genau die Anfragen, die einen konfigurierten Schwellenwert überschreiten, und liefert damit die Grundlage für gezielte statt geratene Performance-Optimierung.

Für Unternehmen mit stationärer Präsenz oder regionalem Einzugsgebiet entscheidet oft nicht die klassische Domain-Autorität über Sichtbarkeit, sondern ein gepflegtes Google Business Profile in Kombination mit lokalen Rankingfaktoren. Wer beides systematisch pflegt, dominiert den lokalen Suchergebnis-Ausschnitt, den viele Nutzer zuerst sehen.

Ein Cluster-Umzug klingt zunächst nach Snapshot erstellen, irgendwo zwischenspeichern und im Zielcluster wiederherstellen, mit allen Fallstricken rund um Speicherorte, Berechtigungen und Versionskompatibilität. Die Reindex-API bietet mit der Option source.remote einen direkteren Weg: Der Zielcluster liest Dokumente über die REST-Schnittstelle direkt aus dem Quellcluster und schreibt sie unmittelbar in den eigenen Index, ganz ohne Snapshot-Repository oder Datei-Export als Zwischenschritt. Dieser Artikel zeigt, welche Whitelisting-Voraussetzungen dafür nötig sind, wie sich Migrationen mit Slicing parallelisieren lassen und wie ein praktischer Workflow bei einem Versionswechsel oder einem Umzug in eine andere Infrastruktur abläuft.

JVM-Heap-Tuning in Elasticsearch ist keine Frage von "je mehr Heap, desto besser", sondern eine Balance zwischen dem JVM-Heap fuer Java-Objekte und dem Betriebssystem-Dateicache, den Lucene fuer Segmentzugriffe nutzt. Wer den Heap zu gross oder ohne Ruecksicht auf die 32-Gigabyte-Grenze fuer Compressed Oops setzt, verschenkt Performance und riskiert lange Garbage-Collection-Pausen genau bei hoher Last.