Seite 4 - Elasticsearch

In einem gemeinsam genutzten Elasticsearch-Index liegen häufig Dokumente, die nicht jede Nutzerrolle vollständig sehen darf. Ein Produktdokument enthält neben öffentlichen Feldern wie Name und Beschreibung oft auch interne Daten wie Einkaufspreise, Lieferantenkonditionen oder Margenkalkulationen, die ausschließlich für bestimmte Abteilungen bestimmt sind. Getrennte Indizes für jede Sichtbarkeitsstufe zu pflegen ist aufwendig und fehleranfällig, sobald sich Rollen oder Datenmodelle ändern. Die Security-API von Elasticsearch bietet dafür zwei ergänzende Mechanismen direkt auf Rollenebene: Field-Level Security blendet einzelne Felder für bestimmte Rollen aus der Antwort aus, während Document-Level Security ganze Dokumente über einen Query-Filter unsichtbar macht, bevor sie überhaupt in die Trefferliste gelangen. Wie beide Mechanismen konfiguriert werden, wie sie sich kombinieren lassen und welche Fallstricke bei Aggregationen und Performance lauern, zeigt dieser Artikel an einem praxisnahen

Ein Type-Ahead-Feld, das bei jedem Tastenanschlag eine neue Query an Elasticsearch feuert, kann einen Cluster unter reale Last bringen, lange bevor der eigentliche Trefferindex überhaupt groß ist. search_as_you_type liefert die Datenstruktur für performantes Prefix-Matching, aber erst die richtige Kombination aus Query-Design, Shard-Verteilung und Frontend-Debouncing macht daraus eine Suche, die auch unter Last stabil bleibt.

Bei kaum einem technischen SEO-Thema entstehen so viel unnötiger Traffic-Verlust wie bei schlecht geplanten Redirects im Rahmen einer Migration. Mehrfach verkettete Redirect-Chains verschwenden Crawl-Budget, verwässern Linkjuice und lassen sich mit einem systematischen URL-Mapping vollständig vermeiden.

Wenn die Suche im Shop falsche oder fehlende Ergebnisse liefert, hilft Raten selten weiter. Systematisches Such-Debugging beginnt mit dem Mitschnitt der tatsaechlichen Elasticsearch-Query, die Magento generiert, laesst diese Query direkt gegen den Cluster laufen und trennt so zuverlaessig, ob das Problem in der Magento-Logik oder im Elasticsearch-Index selbst liegt. Dieser Artikel beschreibt die Methodik Schritt fuer Schritt.

Ein neues Produktattribut landet nicht automatisch dort im Elasticsearch-Index, wo es fuer Suche und Filter gebraucht wird. Erst ein durchdachtes Custom-Attribute-Mapping mit eigenen FieldMapper-Klassen sorgt dafuer, dass searchable, filterable und der richtige Feldtyp zusammenpassen, statt sich auf Magentos Standardableitung zu verlassen.

Wer versucht, alle Buckets eines hochkardinalitären Feldes über eine Terms Aggregation mit riesigem size-Wert zu exportieren, stößt unweigerlich an Speichergrenzen. Die Composite Aggregation löst dieses Problem mit einem after_key-Cursor, der Seite für Seite durch beliebig viele Buckets iteriert, ohne jemals mehr als eine Seite gleichzeitig im Speicher zu halten. Dieser Beitrag zeigt, wie sich vollständige Exporte, Reports und Data-Pipeline-Iterationen mit der Composite Aggregation robust und speicherschonend umsetzen lassen.

Wer eine neue Suchloesung fuer einen Magento-Shop plant, steht vor einer Grundsatzentscheidung: Self-Hosted Elasticsearch oder OpenSearch mit voller Kontrolle und eigenem Betriebsaufwand, oder eine SaaS-Suchloesung wie Algolia oder Klevu mit nutzungsbasierten Kosten und weniger Infrastrukturarbeit. Dieser Artikel vergleicht Kosten, Kontrolle, Features und Integrationsaufwand aller drei Optionen konkret fuer Magento-Haendler.

Ein Array von Objekten sieht in JSON harmlos aus, wird aber je nach gewaehltem Feldtyp intern vollkommen unterschiedlich gespeichert. Der Standardtyp object macht die Struktur flach und verliert dabei die Zuordnung zwischen Feldern verschiedener Array-Eintraege, was zu Treffern fuehrt, die eigentlich keine sein duerften. Nested bewahrt genau diese Beziehung, kostet dafuer aber mehr Ressourcen.

Legacy-Shops auf Magento 1 oder frueher Magento-2-Basis nutzen oft noch Solr als Suchtechnologie, obwohl Solr seit Magento 2.4 nicht mehr unterstuetzt wird. Die Such-Migration von Solr zu Elasticsearch oder OpenSearch betrifft Schema, Reindex-Prozess und Frontend-Verhalten gleichermassen. Dieser Artikel liefert eine vollstaendige Checkliste, ein Schema-Mapping und einen Rollback-Plan fuer eine risikoarme Umstellung.

Ein einzelner, unbegrenzt wachsender Index ist selten die richtige Antwort auf kontinuierliche Datenzuflüsse. Die Rollover-API löst dieses Problem, indem sie einen Schreibalias transparent auf einen neuen, physischen Index umhängt, sobald definierte Bedingungen wie Größe, Dokumentanzahl oder Alter erfüllt sind. Richtig konfiguriert bemerkt die Anwendung davon nichts, sie schreibt weiterhin gegen denselben Alias, während im Hintergrund kontinuierlich neue, überschaubare Indizes entstehen.