ECK erfordert deutlich mehr Aufwand als die Marketplace-basierten Elastic Cloud-Lösungen, ist aber stärker automatisiert als die manuelle Bereitstellung von VMs, da der Kubernetes-Operator die Systemorchestrierung und die Skalierung der Knoten übernimmt.

Dieses Mal werden wir mit dem Azure Kubernetes Service (AKS) arbeiten und dabei die automatische Methode verwenden. In den anderen Artikeln erfahren Sie, wie Sie Azure VM und Azure Marketplace nutzen.

Was ist AKS Automatic?

Der Azure Kubernetes Service (AKS) verwaltet automatisch die Clusterkonfiguration, weist Ressourcen dynamisch zu und integriert bewährte Sicherheitspraktiken bei gleichzeitiger Beibehaltung der Flexibilität von Kubernetes. Dadurch können Entwickler innerhalb von Minuten vom Container-Image zur bereitgestellten Anwendung gelangen.

AKS Automatic beseitigt den Großteil des Aufwands für die Clusterverwaltung und schafft ein gutes Gleichgewicht zwischen Einfachheit und Flexibilität. Die richtige Wahl hängt von Ihrem Anwendungsfall ab, aber die Entscheidung wird einfacher, wenn Sie Folgendes planen:

• Bereitstellung einer Testumgebung: Die Bereitstellung ist schnell und unkompliziert und eignet sich daher ideal für schnelle Experimente oder kurzlebige Cluster.

• Arbeiten Sie ohne strenge VM-, Speicher- oder Netzwerkanforderungen: AKS Automatic bietet vordefinierte Standardeinstellungen. Wenn diese Ihren Bedürfnissen entsprechen, erspart Ihnen das zusätzliche Konfigurationsaufwand.

• So starten Sie zum ersten Mal mit Kubernetes: AKS Automatic übernimmt einen Großteil der Cluster-Einrichtung, senkt die Lernkurve und ermöglicht es Teams, sich auf ihre Anwendungen zu konzentrieren.

Für Elasticsearch werden wir Elastic Cloud on Kubernetes (ECK) verwenden, den offiziellen Elastic Kubernetes Operator, der die Orchestrierung von Kubernetes-Bereitstellungen des Elastic Stack vereinfacht.

So richten Sie AKS Automatic ein

1. Melden Sie sich beim Microsoft Azure Portal an.

2. Klicken Sie oben rechts. Klicken Sie auf die Schaltfläche „Cloud Shell“ , um auf die Konsole zuzugreifen und den AKS-Cluster von dort aus bereitzustellen. Alternativ können Sie die Azure Cloud Shell verwenden.

Denken Sie daran, die Projekt-ID während des Tutorials durch Ihre eigene zu ersetzen.

Das Öffnen des AKS sollte wie im obigen Screenshot aussehen.

3. Installieren Sie die Azure CLI-Erweiterung aks-preview. Diese Vorabversion ermöglicht es uns, bei der Clustererstellung --sku automatic auszuwählen, wodurch die AKS-Automatikfunktion aktiviert wird.

Wenn Sie diese Meldung sehen, bedeutet dies, dass die AKS-Erweiterung ordnungsgemäß installiert wurde.

4. Registrieren Sie Feature-Flags mit dem Befehl az feature register

Sie sehen nun die Details zu dem soeben erstellten Funktionsabonnement:

Überprüfen Sie den Registrierungsstatus, bis er sich von „ Registrierung läuft“ in „ Registriert“ ändert. Die Registrierung kann einige Minuten dauern.

Führen Sie az provider register aus, um die Änderungen zu verbreiten.

5. Erstellen Sie eine Ressourcengruppe

Eine Ressourcengruppe ist eine logische Gruppe von Azure-Ressourcen, die verwaltet und bereitgestellt werden sollen.

6. Erstellen Sie einen Autopilot-Cluster. Wir werden es myAKSAutomaticCluster nennen und die soeben erstellte Ressourcengruppe verwenden. Stellen Sie sicher, dass auf einer der folgenden VM-Größen 16 vCPUs verfügbar sind: Standard_D4pds_v5, Standard_D4lds_v5, Standard_D4ads_v5, Standard_D4ds_v5, Standard_D4d_v5, Standard_D4d_v4, Standard_DS3_v2, Standard_DS12_v2, damit AKS Ressourcen zuweisen kann.

* FallsMissingSubscriptionRegistration-Fehler auftreten , gehen Sie mit den fehlenden Abonnements zurück zu Schritt 4. Beispielsweise erfordert The subscription is not registered to use namespace 'microsoft.insights'die Ausführung vonaz provider register --namespace Microsoft.Insights.

Folgen Sie dem interaktiven Login:

Es erscheint eine Meldung mit der Aufforderung, „az login“ auszuführen. Sie müssen diesen Befehl ausführen und dann warten.

7. Warten Sie, bis es fertig ist. Die Erstellung dauert etwa 10 Minuten.

8. Konfigurieren Sie den Zugriff auf die kubectl-Befehlszeile.

Beachten Sie, dass die von uns installierte Erweiterung AKS Automatic aktiviert.

9. Bestätigen Sie, dass die Knoten bereitgestellt wurden.

Es wird eine Fehlermeldung angezeigt, die den Zugriff verweigert. Kopieren Sie die Benutzer-ID aus der Fehlermeldung.

10. Fügen Sie Ihren Benutzer zur AKS-Zugriffskontrolle hinzu.

AKS-ID abrufen. Kopiere die Ausgabe des Befehls.

Erstellen Sie eine Rollenzuweisung mithilfe der AKS-ID und der Principal-ID Ihres Benutzers.

11. Versuchen Sie erneut zu überprüfen, ob die Knoten bereitgestellt wurden.

12. Installieren Sie den Elastic Cloud on the Kubernetes (ECK)-Operator.

13. Wir erstellen eine Elasticsearch-Instanz mit einem einzelnen Knoten und den Standardwerten.

Wir haben nmap deaktiviert, da die Standard-AKS-Maschine einen zu niedrigen Wert für vm.max_map_count hat. Für den Produktivbetrieb wird von einer Deaktivierung abgeraten, stattdessen sollte der Wert von vm.max_map_count erhöht werden. Mehr dazu können Sie hier nachlesen.

14. Wir werden auch einen Kibana-Einzelknotencluster bereitstellen. Für Kibana werden wir einen Load Balancer hinzufügen, der uns eine externe IP-Adresse bereitstellt, über die wir Kibana von unserem Gerät aus erreichen können.

Standardmäßig konfiguriert AKS Automatic den Load Balancer als öffentlich; Sie können dieses Verhalten ändern, indem Sie die Metadaten-Annotation festlegen:

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

15. Überprüfen Sie, ob Ihre Pods ausgeführt werden.

16. Sie können auch kubectl get elasticsearch und kubectl get kibana ausführen, um spezifischere Statistiken wie Elasticsearch-Version, Knoten und Zustand zu erhalten.

17. Greifen Sie auf Ihre Dienste zu.

Hier wird Ihnen die externe URL für Kibana unter EXTERNAL-IP angezeigt. Es kann einige Minuten dauern, bis der Load Balancer bereitgestellt ist. Kopieren Sie den Wert von EXTERNAL-IP.

18. Ermitteln Sie das Elasticsearch-Passwort für den Benutzer „elastic“:

19. Greifen Sie über Ihren Browser auf Kibana zu :

a. URL: https://:5601<EXTERNAL_IP>

b. Benutzername:elastic

c. Passwort:c44A295CaEt44D6xIzN6Zs5m (aus dem vorherigen Schritt)

20. Wenn Sie Elastic Cloud über Ihren Browser aufrufen, wird Ihnen der Begrüßungsbildschirm angezeigt.

Wenn Sie die Spezifikationen des Elasticsearch-Clusters ändern möchten, z. B. die Anzahl oder Größe der Knoten anpassen, können Sie das YML-Manifest mit den neuen Einstellungen erneut anwenden:

In diesem Beispiel fügen wir einen weiteren Knoten hinzu und modifizieren RAM und CPU. Wie Sie sehen können, zeigt kubectl get elasticsearch jetzt 2 Knoten an:

Das Gleiche gilt für Kibana:

Wir können die CPU/RAM-Auslastung des Containers sowie die Speichernutzung von Node.js (max-old-space-size) anpassen.

Beachten Sie, dass bestehende Volumenansprüche nicht reduziert werden können. Nach der Installation des Updates kann der Betreiber die Änderungen mit minimalen Unterbrechungszeiten vornehmen.

Denken Sie daran, den Cluster nach Abschluss der Tests zu löschen, um unnötige Kosten zu vermeiden.

Fazit

Die Verwendung von Azure AKS Automatic mit ECK bietet eine ausgewogene Lösung für die Bereitstellung von Elasticsearch und Kibana: Sie reduziert die operative Komplexität, gewährleistet automatisierte Skalierung und Aktualisierungen und nutzt die Flexibilität von Kubernetes. Dieser Ansatz ist ideal für Teams, die einen zuverlässigen, wiederholbaren und wartungsfreundlichen Bereitstellungsprozess wünschen, ohne jedes Infrastrukturdetail manuell verwalten zu müssen. Daher ist er eine praktische Wahl sowohl für Test- als auch für Produktionsumgebungen.

Wie geht es weiter?

Wenn Sie mehr über Kubernetes erfahren möchten, können Sie die offizielle Dokumentation hier einsehen:

• Elastic Cloud auf Kubernetes | Elastic Docs

• Einführung in Azure Kubernetes Service (AKS) Automatisch (Vorschau)

• AKS Automatic – AKS Engineering Blog

Was ist rekursives Chunking?

Bei der rekursiven Segmentierung wird eine Liste von vorgegebenen Abschnittstrennungsmustern durchlaufen, um ein Dokument schrittweise in kleinere Segmente zu unterteilen, bis eine gewünschte maximale Segmentgröße erreicht ist.

Wie konfiguriere ich rekursives Chunking?

Folgende Werte können vom Benutzer für die rekursive Segmentierung konfiguriert werden:

• (erforderlich) max_chunk_size: Die maximale Anzahl von Wörtern in einem Chunk.

• Entweder eines von beiden:

  • separatorsEine Liste von regulären Ausdrücken, die verwendet werden, um das Dokument in Abschnitte zu unterteilen.

  • separator_groupEine Zeichenkette, die einer von Elastic definierten Standardliste von Trennzeichen zugeordnet wird, die für bestimmte Dokumenttypen verwendet werden. Aktuell sind markdown und plaintext verfügbar.

Wie funktioniert rekursives Chunking?

Der Prozess des rekursiven Chunkings bei gegebenem Eingabedokument, einem max_chunk_size (gemessen in Wörtern) und einer Liste von Trennzeichenketten verläuft wie folgt:

1. Wenn das Eingabedokument bereits innerhalb der maximalen Chunk-Größe liegt, wird ein einzelner Chunk zurückgegeben, der die gesamte Eingabe umfasst.

2. Teile den Text anhand des Vorkommens des Trennzeichens in mögliche Abschnitte auf. Für jeden potenziellen Teil:

   1. Wenn der potenzielle Datenblock innerhalb der maximalen Datenblockgröße liegt, fügen Sie ihn der Liste der an den Benutzer zurückzugebenden Datenblöcke hinzu.

   2. Andernfalls wiederholen Sie ab Schritt 2, wobei Sie nur den Text aus dem potenziellen Chunk verwenden und diesen anhand des nächsten Trennzeichens in der Liste aufteilen. Wenn keine weiteren Trennzeichen mehr übrig sind, sollte man auf satzbasierte Segmentierung zurückgreifen.

Beispiele für die Konfiguration von rekursivem Chunking

Abgesehen von der Chunk-Größe besteht die wichtigste Konfiguration für rekursives Chunking in der Auswahl der Trennzeichen, die zum Aufteilen der Dokumente verwendet werden sollen. Wenn Sie nicht sicher sind, wo Sie anfangen sollen, bietet Elasticsearch einige Standardtrennzeichengruppen an, die für gängige Anwendungsfälle verwendet werden können.

Verwendung von Trenngruppen

Um eine Trenngruppe zu verwenden, geben Sie einfach den Namen der Gruppe an, die Sie bei der Konfiguration der Chunking-Einstellungen verwenden möchten. Zum Beispiel:

Dies führt zu einer rekursiven Chunking-Strategie, die die Trennzeichenliste ["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")] verwendet. Dies funktioniert gut für allgemeine Klartextanwendungen, wobei der Text an zwei Zeilenumbruchzeichen, gefolgt von einem weiteren Zeilenumbruchzeichen, geteilt wird.

Wir bieten außerdem eine Trennzeichengruppe markdown an, die die Trennzeichenliste verwendet:

Diese Trennzeichenliste eignet sich gut für allgemeine Markdown-Anwendungsfälle, da sie an jeder der 6 Überschriftenebenen und den Abschnittsumbruchzeichen aufteilt.

Beim Erstellen einer Ressource (Inferenzendpunkt/semantisches Textfeld) wird die Liste der Trennzeichen, die der Trennzeichengruppe zu diesem Zeitpunkt entsprechen, in Ihren Konfigurationen gespeichert. Wenn die Trenngruppe zu einem späteren Zeitpunkt aktualisiert wird, ändert sich dadurch das Verhalten Ihrer bereits erstellten Ressourcen nicht.

Verwendung einer benutzerdefinierten Trennliste

Falls eine der vordefinierten Trennzeichengruppen für Ihren Anwendungsfall nicht geeignet ist, können Sie eine benutzerdefinierte Liste von Trennzeichen definieren, die Ihren Anforderungen entspricht. Beachten Sie, dass reguläre Ausdrücke innerhalb der Trennzeichenliste angegeben werden können. Nachfolgend ein Beispiel für Chunking-Einstellungen mit benutzerdefinierten Trennzeichen:

Die oben beschriebene Chunking-Strategie teilt an zwei Zeilenumbruchzeichen, gefolgt von einem Zeilenumbruchzeichen und schließlich an der Zeichenkette “<my-custom-separator>” auf.

Ein Beispiel für rekursives Chunking in der Praxis

Schauen wir uns ein Beispiel für rekursives Chunking in der Praxis an. In diesem Beispiel verwenden wir die folgenden Chunking-Einstellungen mit einer benutzerdefinierten Liste von Trennzeichen, die ein Markdown-Dokument anhand der beiden obersten Header-Ebenen aufteilen:

Werfen wir einen Blick auf ein einfaches, unstrukturiertes Markdown-Dokument:

Nun verwenden wir die oben definierten Chunking-Einstellungen, um das Dokument in Chunking-Elemente zu unterteilen:

Hinweis: Der Zeilenumbruch am Ende jedes Abschnitts (außer Abschnitt 3) ist nicht hervorgehoben, befindet sich aber innerhalb der eigentlichen Abschnittsgrenzen.

Legen Sie noch heute mit rekursivem Chunking los!

Weitere Informationen zur Nutzung dieser Funktion finden Sie in der Dokumentation zur Konfiguration der Chunking-Einstellungen.

Darüber hinaus sind diese Anwendungsfälle in der Regel zeitkritisch, und das Durchlaufen der typischen Entwicklungsphasen (Erstellen eines Codezweigs und anschließendes Warten auf eine neue Version) ist ein zeitaufwändiger Prozess.

Was wäre, wenn wir diesen gesamten Prozess mit einem einzigen API-Aufruf oder, noch besser, mit nur wenigen Klicks in Kibana erledigen könnten?

Benutzeroberfläche für Abfrageregeln

Elasticsearch 8.10 führte Abfrageregeln und Regelabrufer ein. Hierbei handelt es sich um Tools, die entwickelt wurden, um festgelegte Ergebnisse in die Suchanfragen einzufügen, ohne die Rangfolge der organischen Ergebnisse gemäß den Regeln zu beeinträchtigen. Sie fügen den Ergebnissen lediglich auf deklarative und einfache Weise Geschäftslogik hinzu.

Einige gängige Anwendungsfälle für Abfrageregeln sind:

• Hervorhebung von beworbenen Angeboten oder Verkäufen: Anzeige von reduzierten oder gesponserten Artikeln ganz oben.

• Ausschluss nach Kontext oder Standort: Ausblenden bestimmter Elemente, wenn deren Anzeige aufgrund lokaler Vorschriften nicht zulässig ist.

• Priorisierung wichtiger Ergebnisse: Sicherstellen, dass beliebte oder feste Suchanfragen unabhängig vom organischen Ranking immer ganz oben stehen.

Um auf die Benutzeroberfläche zuzugreifen und mit diesen Tools zu interagieren, müssen Sie im Kibana-Seitenmenü auf „Abfrageregeln“ unter „Relevanz“ klicken:

Sobald das Menü mit den Abfrageregeln erscheint, klicken Sie auf „Erstes Regelset erstellen“:

Als Nächstes müssen Sie Ihrem Regelsatz einen Namen geben.

Das Formular zur Definition jeder Regel besteht aus drei Hauptkomponenten:

• Kriterien: Die Bedingungen, die erfüllt sein müssen, damit die Regel Anwendung findet. Zum Beispiel: „wenn das Feld query_string den Wert Christmas enthält“ oder „wenn das Feld country CO ist“.

• Aktion: Das soll passieren, wenn die Bedingungen erfüllt sind. Es kann angeheftet (ein Dokument wird an der Spitze der Suchergebnisse fixiert) oder ausgeschlossen (ein Dokument wird ausgeblendet) werden.

• Metadaten: Dies sind die Felder, die bei der Ausführung der Abfrage mitgeführt werden. Sie können sowohl Benutzerinformationen (wie Standort oder Sprache) als auch Suchdaten (Query-String) enthalten. Dies sind die Werte, anhand derer die Kriterien entscheiden, ob eine Regel angewendet werden soll oder nicht.

Beispiel: beliebte Artikel

Stellen wir uns vor, wir hätten eine E-Commerce-Website mit verschiedenen Artikeln. Bei der Überprüfung der Kennzahlen stellen wir fest, dass einer der meistverkauften Artikel in der Kategorie Konsolen der „DualShock 4 Wireless Controller“ ist, insbesondere wenn Nutzer nach den Schlüsselwörtern „PS4“ oder „PlayStation 4“ suchen. Deshalb haben wir beschlossen, dieses Produkt ganz oben in den Suchergebnissen anzuzeigen, wenn ein Nutzer nach diesen Schlüsselwörtern sucht.

Als Erstes indizieren wir die Dokumente für jeden Artikel mithilfe einer Bulk-API-Anfrage:

Wenn wir nicht in die Abfrage eingreifen, erscheint der Eintrag normalerweise an vierter Stelle. Hier die Anfrage:

Und hier sind die Ergebnisse.

Lasst uns eine Abfrageregel erstellen, um dies zu ändern. Als Erstes fügen wir es dem Regelwerk folgendermaßen hinzu:

Oder eine entsprechende API-Anfrage:

Um das Regelset in unserer Abfrage verwenden zu können, müssen wir einen Abfrageregeltyp verwenden. Diese Art von Anfrage besteht aus zwei Hauptteilen:

• match_criteria: Dies sind die Metadaten, die zum Vergleich mit der Benutzeranfrage verwendet werden. In diesem Beispiel wird das Regelset aktiviert, wenn das Feld query_string den Wert „PlayStation 4“ hat.

• Suchanfrage: Die eigentliche Suchanfrage, die verwendet wird, um die organischen Suchergebnisse zu finden.

Auf diese Weise führen Sie zuerst die organische Abfrage aus, und anschließend wendet Elasticsearch die Regeln aus Ihrem Regelsatz an:

Beispiel: benutzerbasierte Metadaten

Eine weitere interessante Anwendung von Abfrageregeln besteht darin, Metadaten zu verwenden, um bestimmte Dokumente basierend auf Kontextinformationen des Benutzers oder der Webseite anzuzeigen.

Nehmen wir beispielsweise an, wir möchten Artikel oder personalisierte Angebote basierend auf dem Loyalitätsgrad eines Nutzers hervorheben, der als numerischer Wert dargestellt wird.

Dies erreichen wir, indem wir diese Metadaten direkt in die Abfrage einbinden, sodass die Regeln aktiviert werden, wenn der genannte Wert bestimmte Kriterien erfüllt.

Zunächst indexieren wir ein Dokument, das nur Nutzer mit einer hohen Loyalitätsstufe sehen können:

Jetzt erstellen wir eine neue Regel innerhalb desselben Regelsatzes, sodass der Artikel ganz oben in den Ergebnissen erscheint, wenn der Loyalitätswert (loyality_level) gleich oder höher als 80 ist.

Speichern Sie die Regel und das Regelwerk.

Hier ist die entsprechende REST-Anfrage:

Beim Ausführen einer Abfrage muss nun der neue Parameter loyalty_level in die Metadaten aufgenommen werden. Wenn die Bedingung in der Regel erfüllt ist, erscheint das neue Dokument ganz oben in den Suchergebnissen.

Beispiel: Senden einer Anfrage, bei der der Loyalitätsgrad 80 beträgt:

Das Treuezertifikat wird oben auf den Ergebnissen angezeigt:

Im folgenden Fall ist die Regel aufgrund des Loyalitätslevels von 70 nicht erfüllt, und der Artikel sollte nicht oben erscheinen:

Hier die Ergebnisse:

Beispiel: sofortiger Ausschluss

Nehmen wir an, unser DualShock 4 Wireless-Controller (ID 2) ist vorübergehend nicht verfügbar und kann nicht verkauft werden. Anstatt das Dokument manuell zu löschen oder auf die Verarbeitung der Daten zu warten, beschließt das Business-Team, es in der Zwischenzeit aus den Suchergebnissen zu entfernen.

Wir werden ein ähnliches Verfahren anwenden wie das, das wir gerade bei den beliebten Artikeln angewendet haben, aber diesmal wählen wir anstelle von "Angeheftet" die Option "Ausschließen". Diese Regel funktioniert wie eine Art Blacklist. Ändern Sie das Kriterium auf „Immer“ , damit der Ausschluss bei jeder Ausführung der Abfrage funktioniert.

Die Regel sollte folgendermaßen aussehen:

Speichern Sie die Regel und das Regelset, um die Änderungen anzuwenden. Hier ist die entsprechende REST-Anfrage:

Wenn wir die Abfrage nun erneut ausführen, werden Sie feststellen, dass das Element nicht mehr in den Ergebnissen enthalten ist, obwohl die vorherige Regel vorsah, es zu fixieren. Dies liegt daran, dass Ausschlüsse Vorrang vor dem Anheften von Ergebnissen haben.

Fazit

Mit Abfrageregeln lässt sich die Relevanz ganz einfach und ohne Codeänderungen anpassen. Die neue Kibana -Benutzeroberfläche ermöglicht IhnenDiese Änderungen lassen sich in Sekundenschnelle vornehmen, wodurch Sie und Ihr Team mehr Kontrolle über Ihre Suchergebnisse erhalten.

Über den E-Commerce hinaus können Abfrageregeln in vielen anderen Szenarien eingesetzt werden: Hervorhebung von Anleitungen zur Fehlerbehebung in Supportportalen, Auffinden wichtiger interner Dokumente in Wissensdatenbanken, Förderung aktueller Meldungen auf Nachrichtenseiten oder Herausfiltern abgelaufener Stellen- oder Inhaltsangebote. Sie können sogar Compliance-Regeln durchsetzen, wie beispielsweise das Ausblenden von eingeschränktem Material nach Benutzerrolle oder Region.

Wir werden den Elastic Cloud Service auf AWS nutzen, den offiziellen verwalteten Elasticsearch-Service, der die Bereitstellung und Orchestrierung aller Elastic Stack-Komponenten über die native Infrastruktur von AWS vereinfacht.

Wenn Sie erfahren möchten, wie Sie Elasticsearch auf AWS EC2 installieren und konfigurieren, schauen Sie sich diesen Blog an.

Was ist AWS Marketplace?

Elastic auf AWS Marketplace bietet ein vollständig verwaltetes Such- und Analyseerlebnis, bei dem AWS die Infrastrukturbereitstellung, Sicherheit und Skalierung übernimmt, während sich die Entwickler auf die Erstellung von Suchanwendungen konzentrieren. Dies ermöglicht es Teams, Elasticsearch-Cluster der Enterprise-Klasse innerhalb von Minuten mit integrierten AWS-Integrationen bereitzustellen.

Wann sollte man Elastic auf dem AWS Marketplace verwenden?

Elastic auf AWS Marketplace eignet sich am besten für Organisationen mit einer bestehenden AWS-Infrastruktur, die Elasticsearch mit Managed Services, integrierter Sicherheit und nahtloser AWS-Integration ohne operativen Mehraufwand bereitstellen möchten.

So richten Sie Elastic Cloud auf dem AWS Marketplace ein

Schritt 1: Zugriff auf den AWS Marketplace

1. Melden Sie sich bei AWSan.

• Suchen Sie in der Suchleiste nach AWS Marketplace.

2. Klicken Sie im linken Navigationsbereich auf „Produkte entdecken“ und suchen Sie dann nach Elasticsearch.

3. Klicken Sie auf Elastic Cloud (Elasticsearch-Dienst).

Schritt 2: Abonnieren Sie den Dienst

1. Wählen Sie Ihre Kaufoptionen oder klicken Sie auf „Kostenlos testen“.

2. Überprüfen Sie die Preisdetails, die Allgemeinen Geschäftsbedingungen und die Kaufdetails .

3. Klicken Sie auf die Schaltfläche „Abonnieren“ .

4. Jetzt müssen wir das Elastic-Konto einrichten. Folgen Sie den Schritten von AWS.

a. Klicken Sie auf die Schaltfläche „Integration aktivieren“.

b. Klicken Sie auf die Schaltfläche „Anmelden oder ein Händlerkonto erstellen“.

c. Klicken Sie auf die Schaltfläche „Vorlage starten“.

d. Klicken Sie auf die Schaltfläche „Software starten“.

Schritt 3. Konfigurieren Sie Ihr neues Konto in Elastic.

1. Erstellen Sie Ihr Elastic-Konto

2. Bestätigen Sie Ihre E-Mail-Adresse

3. Geben Sie Ihren Namen und Ihre Firmeninformationen ein.

4. Füllen Sie eine kurze Elastic-Umfrage aus.

5. Wählen Sie die Region aus, in der Sie Elastic Cloud hosten möchten. Standardmäßig wird Ihre tatsächliche AWS-Region ausgewählt.

6. Warten Sie, bis Elastic bereitgestellt ist.

7. Ihre Bereitstellung ist mit Ihrem AWS Marketplace-Abonnement verbunden.

Kündigen Sie Ihr Abonnement

Um Ihr Abonnement zu kündigen

1. Öffnen Sie die AWS-Konsole.

Suchen Sie in der Suchleiste nach AWS Marketplace. Klicken Sie auf AWS Marketplace.

2. Klicken Sie auf das Elastic Cloud-Abonnement.

3. Klicken Sie auf die Schaltfläche „Aktionen“ und anschließend auf „Abonnement kündigen“.

4. Bestätigen Sie die Kündigung, indem Sie dann auf „Ja“und anschließend auf die Schaltfläche „Abonnement kündigen“ klicken.

5. Eine Bestätigungsmeldung erscheint oben auf der Seite.

Wie geht es weiter?

Starten Sie Ihre Elastic Cloud-Reise mit einer 7-tägigen kostenlosen Testversion, die eine einzelne Bereitstellung und drei Projekte umfasst. Elastic Cloud (Elasticsearch Service). Melden Sie sich einfach in Ihrem AWS-Konto an und klicken Sie auf „Kaufoptionen anzeigen“, um die Elastic Search AI Platform sofort auf Elastic Cloud (Elasticsearch Service) zu nutzen. Die Testversion bietet vollen Zugriff auf Such-, Sicherheits- und Überwachungslösungen ohne zusätzlichen Aufwand für die Infrastrukturverwaltung.

Verteilte Systeme wie Elasticsearch können sehr komplex sein, und es gibt viele Faktoren, die ihre Leistungsfähigkeit und Stabilität beeinflussen können. Shards gehören zu den grundlegendsten Konzepten in Elasticsearch, und das Verständnis ihrer Funktionsweise ermöglicht Ihnen die effektive Verwaltung eines Elasticsearch-Clusters.

Dieser Artikel erklärt, was primäre und Replikat-Shards sind, welche Auswirkungen sie auf einen Elasticsearch-Cluster haben und welche Tools es gibt, um sie an unterschiedliche Anforderungen anzupassen.

Scherben verstehen

Die Datenmenge in einem Elasticsearch-Index kann enorm anwachsen. Um die Verwaltung überschaubar zu halten, wird jedes Datenelement in einem Index gespeichert, und Indizes sind ein Index, der in eine Anzahl von Shards aufgeteilt ist. Jeder Elasticsearch-Shard ist ein Apache Lucene-Index, wobei jeder einzelne Lucene-Index eine Teilmenge der Dokumente im Elasticsearch-Index enthält. Durch die Aufteilung der Indizes auf diese Weise bleibt die Ressourcennutzung unter Kontrolle. Ein Apache Lucene-Index hat eine Begrenzung von 2.147.483.519 (2³¹ - 129) Dokumenten.

Manchmal müssen Indizes zum Zweck der Neuausrichtung zwischen Knoten verschoben werden. Da dieser Prozess sowohl zeit- als auch ressourcenintensiv sein kann, sollten die Indizes nicht zu groß werden, was dazu beiträgt, die Wiederherstellungszeit überschaubar zu halten. Da Indizes aus Lucene-Segmenten bestehen, die ständig zusammengeführt werden müssen, ist es außerdem wichtig, dass die Segmente nicht zu groß werden. Aus diesen Gründen teilt Elasticsearch die Indexdaten in kleinere, besser handhabbare Teile auf, sogenannte primäre Shards, die sich leichter auf mehrere Maschinen verteilen lassen. Replikat- Shards sind einfach eine exakte Kopie eines entsprechenden primären Shards. Ihre Funktion werden wir später in diesem Artikel erläutern.

Die richtige Anzahl an Shards ist wichtig für die Performance. Daher ist es ratsam, im Voraus zu planen. Wenn Abfragen parallel über verschiedene Shards ausgeführt werden, sind sie schneller als ein Index, der aus einem einzigen Shard besteht, allerdings nur dann, wenn sich jeder Shard auf einem anderen Knoten befindet und genügend Knoten im Cluster vorhanden sind. Gleichzeitig verbrauchen Shards jedoch Arbeitsspeicher und Festplattenspeicher, sowohl im Hinblick auf indizierte Daten als auch auf Cluster-Metadaten. Zu viele Shards (auch als Oversharding bezeichnet) können Abfragen, Indexierungsanforderungen und Verwaltungsvorgänge verlangsamen, daher ist die Aufrechterhaltung des richtigen Gleichgewichts von entscheidender Bedeutung.

Die Anzahl der primären Shards wird zum Zeitpunkt der Indexerstellung für die jeweilige Indexinstanz festgelegt. Falls Sie später eine andere Anzahl primärer Shards benötigen, können Sie die Resize-APIsverwenden –split (mehr primäre Shards), shrink (weniger primäre Shards) oder clone (die gleiche Anzahl primärer Shards mit neuen Einstellungen für Replikate). Diese Operationen kopieren Lucene-Segmente und vermeiden eine vollständige Neuindizierung aller Dokumente. Beim Erstellen eines Index können Sie die Anzahl der primären und Replikat-Shards als Indexeinstellungen festlegen:

(Wenn Sie die Anzahl der Shards oder Replikate nicht angeben, ist der Standardwert für beides 1 (Stand: Elasticsearch 7.0). Die ideale Anzahl an Shards sollte anhand der Datenmenge im Index bestimmt werden. Im Allgemeinen sollte ein optimaler Shard 10-50 GB an Daten enthalten, mit weniger als 200 Millionen Dokumenten pro Shard. Wenn Sie beispielsweise erwarten, dass sich täglich etwa 300 GB an Anwendungsprotokollen ansammeln, wären etwa 10 Shards in diesem Index angemessen, vorausgesetzt, Sie verfügen über eine ausreichende Anzahl von Knoten, um diese zu hosten.

Während ihrer Lebensdauer können Scherben verschiedene Zustände durchlaufen, darunter:

• Initialisierung: Ein Anfangszustand, bevor der Shard verwendet werden kann.

• Gestartet: Ein Zustand, in dem der Shard aktiv ist und Anfragen empfangen kann.

• Verschieben: Ein Zustand, der eintritt, wenn Shards gerade auf einen anderen Knoten verschoben werden. Dies kann unter bestimmten Bedingungen erforderlich sein, beispielsweise wenn auf dem Knoten, auf dem sie sich befinden, der Speicherplatz knapp wird.

• Nicht zugewiesen: Der Status eines Shards, der nicht zugewiesen werden konnte. Wenn dies geschieht, wird ein Grund angegeben, beispielsweise wenn sich der Knoten, auf dem der Shard gehostet wird, nicht mehr im Cluster befindet (NODE_LEFT) oder wenn die Wiederherstellung in einen geschlossenen Index erfolgt (EXISTING_INDEX_RESTORED).

Um alle Shards, deren Zustände und weitere Metadaten anzuzeigen, können Sie die folgende Anfrage verwenden:

Um Shards für einen bestimmten Index anzuzeigen, können Sie den Namen des Index an die URL anhängen, zum Beispiel sensor:

Dieser Befehl erzeugt eine Ausgabe, wie im folgenden Beispiel. Standardmäßig enthalten die angezeigten Spalten den Namen des Index, den Namen (d. h. Nummer) des Shards, ob es sich um einen primären Shard oder eine Replik handelt, sein Status, die Anzahl der Dokumente, die Größe auf der Festplatte sowie die IP-Adresse und die Knoten-ID des Knotens, auf dem sich der Shard befindet.

Repliken verstehen

Während jeder Shard nur eine einzige Kopie der Daten enthält, kann ein Index mehrere Kopien des Shards enthalten. Es gibt also zwei Arten von Shards, den primären Shard und eine Kopie oder Replik. Jede Replik eines primären Shards befindet sich immer auf einem anderen Knoten, was eine hohe Verfügbarkeit Ihrer Daten im Falle eines Knotenausfalls gewährleistet. Neben der Redundanz und ihrer Rolle bei der Vermeidung von Datenverlust und Ausfallzeiten können Replikate auch zur Steigerung der Suchleistung beitragen, indem sie die parallele Verarbeitung von Abfragen mit dem primären Shard und damit eine schnellere Verarbeitung ermöglichen.

Es gibt einige wichtige Unterschiede im Verhalten von primären und Replikat-Shards. Beide können zwar Anfragen verarbeiten, Indexierungsanfragen (d. h. Daten, die dem Index hinzugefügt werden, müssen zuerst die primären Shards durchlaufen, bevor sie auf die Replikat-Shards repliziert werden können. Wie bereits erwähnt, wird, wenn ein primärer Shard nicht mehr verfügbar ist – beispielsweise aufgrund einer Knotenunterbrechung oder eines Hardwareausfalls –, eine Replik zum Nachfolger befördert, um dessen Rolle zu übernehmen.

Replikate können zwar im Falle eines Knotenausfalls hilfreich sein, es ist jedoch wichtig, nicht zu viele davon zu haben, da sie beim Indizieren Speicherplatz, Festplattenspeicher und Rechenleistung verbrauchen. Ein weiterer Unterschied zwischen den primären Shards und Replikaten besteht darin, dass die Anzahl der primären Shards nach der Erstellung des Index nicht mehr geändert werden kann, die Anzahl der Replikate jedoch jederzeit dynamisch durch Aktualisieren der Indexeinstellungen angepasst werden kann.

Ein weiterer Faktor, der bei Replikaten zu berücksichtigen ist, ist die Anzahl der verfügbaren Knoten. Replikate werden immer auf anderen Knoten als dem primären Shard platziert, da zwei Kopien derselben Daten auf demselben Knoten keinen Schutz bieten würden, wenn der Knoten ausfallen sollte. Damit ein System n Replikate unterstützen kann, müssen daher mindestens n + 1 Knoten im Cluster vorhanden sein. Wenn beispielsweise ein Cluster aus zwei Knoten besteht und ein Index mit sechs Replikaten konfiguriert ist, wird nur ein Replikat zugewiesen. Ein System mit sieben Knoten hingegen ist durchaus in der Lage, einen primären Shard und sechs Replikate zu verwalten.

Optimierung von Shards und Replikaten

Auch nachdem ein Index mit dem richtigen Verhältnis von primären und Replikat-Shards erstellt wurde, müssen diese überwacht werden, da sich die Dynamik eines Index im Laufe der Zeit ändert. Beispielsweise sind bei der Analyse von Zeitreihendaten Indizes mit aktuellen Daten im Allgemeinen aktiver als ältere. Ohne eine Anpassung dieser Indizes würden sie alle die gleiche Menge an Ressourcen verbrauchen, trotz ihrer sehr unterschiedlichen Anforderungen.

Mithilfe der Rollover-Index-API lassen sich neuere und ältere Indizes trennen. Es kann so eingestellt werden, dass automatisch ein neuer Index erstellt wird, sobald ein bestimmter Schwellenwert erreicht ist – die Größe des Index auf der Festplatte, die Anzahl der Dokumente oder sein Alter. Diese API ist auch nützlich, um die Shard-Größen unter Kontrolle zu halten. Da die Anzahl der Shards nach der Indexerstellung nicht ohne Weiteres geändert werden kann, sammeln sich weiterhin Daten in den Shards an, wenn keine Rollover-Bedingungen erfüllt sind. Bei älteren Indizes, auf die nur selten zugegriffen werden muss, sind das Verkleinern und das erzwungene Zusammenführen eines Index zwei verschiedene Möglichkeiten, den Speicher- und Festplattenbedarf zu reduzieren. Ersteres reduziert die Anzahl der Shards in einem Index, während letzteres die Anzahl der Lucene-Segmente reduziert und Speicherplatz freigibt, der von gelöschten Dokumenten belegt wurde.

Primäre und Replikat-Shards als Grundlage von Elasticsearch

Elasticsearch hat sich einen hervorragenden Ruf als verteilte Speicher-, Such- und Analyseplattform für riesige Datenmengen erworben. Bei einem Betrieb in einem solchen Umfang werden jedoch unweigerlich Herausforderungen auftreten. Deshalb ist es für Elasticsearch so wichtig und grundlegend zu verstehen, wie primäre und Replikat-Shards funktionieren, da dies zur Optimierung der Zuverlässigkeit und Leistung der Plattform beitragen kann.

Zu wissen, wie sie funktionieren und wie man sie optimiert, ist entscheidend für die Erreichung eines robusteren und leistungsfähigeren Elasticsearch-Clusters. Wenn Sie regelmäßig mit langsamen Antwortzeiten auf Anfragen oder Ausfällen konfrontiert sind, könnte dieses Wissen der Schlüssel zur Überwindung dieser Hindernisse sein.

In der offiziellen Dokumentation von Elasticsearch erfahren Sie mehr über Cluster, Knoten und Shards, die Dimensionierung Ihrer Shards, die Shard-Zuweisung und die Wiederherstellung.

Dieses Thema ist auch als Einführungskurs auf dem YouTube-Kanal der Elastic Community verfügbar.

Zu guter Letzt: Wenn Sie sich keine Gedanken über Nodes, Shards oder Replikate machen möchten, können Sie Elastic Cloud Serverless ausprobieren. Dieses Elastic Cloud-Angebot wird vollständig von Elastic verwaltet und ist so automatisiert, dass es mit Ihrer Arbeitslast skaliert. Eine kostenlose Testversion kann Ihnen helfen, sich mit weiteren Vorteilen des serverlosen Ansatzes vertraut zu machen.

• bg_count (Hintergrundzählung): Anzahl der im übergeordneten Datensatz gefundenen Dokumente

• doc_count: Anzahl der im Ergebnisdatensatz gefundenen Dokumente

In einem Datensatz zu Handyverkäufen können wir beispielsweise nach relevanten Begriffen im Zusammenhang mit den iPhone 16-Verkäufen suchen, etwa so:

Die Antwort lautet dann:

Houston gehört weder zu den Top 10 Städten im gesamten Datensatz noch ist Houston die Top-Stadt für das iPhone 16. Die Auswertung der signifikanten Terme ergab jedoch, dass das iPhone 16 in dieser Stadt im Vergleich zu den übrigen Daten überproportional häufig gekauft wird . Lassen Sie uns die Zahlen genauer betrachten:

• Auf höchster Ebene:

  • Dokumentenanzahl: 122 – Die Abfrage ergab insgesamt 122 Treffer.

  • bg_count: 424 — Der Hintergrundsatz (alle Verkaufsbelege) enthält 424 Belege

• Im Houston-Eimer:

  • Dokumentanzahl: 12 — Houston erscheint in 12 der 122 Suchergebnisse

  • bg_count: 14 — Houston erscheint in 14 der insgesamt 424 Dokumente im Hintergrunddatensatz

Dies bedeutet, dass von insgesamt 424 Käufen nur 14 in Houston stattfanden; das sind 3,3 % aller Käufe. Betrachtet man jedoch nur die Verkaufszahlen des iPhone 16, so stellt man fest, dass 12 von 122 Verkäufen in Houston stattfanden, was 9,8 % entspricht – das Dreifache des Wertes im gesamten Datensatz; das ist bemerkenswert!

So sieht das in einer Visualisierung aus: Gesamtumsatz pro Stadtregion.

Wir sehen, dass es in Houston 14 Verkäufe gibt, womit Houston gemessen an den Verkäufen die 14. höchste Stadt im Datensatz ist.

Wenn wir nun einen Filter anwenden, der nur die Verkaufszahlen des iPhone 16 berücksichtigt, verzeichnen wir 12 Verkäufe in Houston. Damit ist Houston die zweitmeisten Städte mit den Verkaufszahlen für dieses spezielle Modell:

Die wichtigsten Begriffe der Aggregation verstehen

Laut Elastic-Dokumentation sind die wichtigsten Begriffe Aggregation:

„(Findet) Begriffe, deren Popularität sich im Vergleich zwischen einem Vordergrund- und einem Hintergrunddatensatz signifikant verändert hat.“

Das bedeutet, dass statistische Kennzahlen verwendet werden, um die Häufigkeit eines Begriffs in einer Teilmenge der Daten (der Vordergrundmenge) mit der Häufigkeit desselben Begriffs in der übergeordneten Datenmenge (der Hintergrundmenge) zu vergleichen. Auf diese Weise spiegelt die Bewertung die statistische Signifikanz wider und nicht, wie häufig ein Begriff in den Daten vorkommt.

Die Hauptunterschiede zwischen einer Aggregation signifikanter Terme und einer normalen Termaggregation sind:

• Signifikante Terme vergleichen eine Teilmenge der Daten, während eine Termaggregation nur mit dem aus der Abfrage resultierenden Datensatz arbeitet.

• Die Ergebnisse einer Termaggregation sind die häufigsten Terme im Datensatz, während die Ergebnisse einer signifikanten Termaggregation die häufigen Terme ignorieren, um herauszufinden, was den Datensatz einzigartig macht.

• Signifikante Terme können einen größeren Einfluss auf die Leistung haben, da sie Daten von der Festplatte und nicht aus dem Arbeitsspeicher abrufen müssen, wie es bei der Termaggregation der Fall ist.

Praktische Anwendung (Verbraucherverhaltensanalyse)

Datenaufbereitung für die Analyse

Für diese Analyse haben wir einen synthetischen Datensatz über Handyverkäufe erstellt, der Preis, technische Daten des Telefons, demografische Daten des Käufers und Kundenfeedback enthält. Wir haben außerdem Einbettungen aus dem Feedback der Nutzer generiert, um später eine semantische Abfrage durchführen zu können. Wir verwendeten das mehrsprachige e5 small model, das auf Elasticsearch standardmäßig verfügbar ist.

So verwenden Sie diesen Datensatz in Elasticsearch:

1. Laden Sie die CSV-Datei ( hier herunterladbar) mit der Kibana-Funktion „Datendateien hochladen“ hoch.

2. Richten Sie ein semantisches Feld namens „Einbettung“ ein, wie in diesem Blog beschrieben. multilingual-e5-small model

3. Schließen Sie den Import mit den Feldtyp-Standardwerten ab (Schlüsselwort für jedes Feld außer purchase_date und user_feedback). Um die hier präsentierten Abfragen ausführen zu können, müssen Sie unbedingt den Indexnamen phone_sales_analysis hinzufügen.

Der Schwerpunkt dieser Analyse liegt auf der Frage : „Was unterscheidet die Käufer des iPhone 16 von anderen Bevölkerungsgruppen?“ und darauf, eine Segmentierung der Käufer für Marketingzwecke zu erstellen. 

Dies ist ein Beispieldokument aus dem Datensatz:

demografische Muster verstehen

Hier werden wir eine Analyse der Gesamtbevölkerung durchführen und sie mit interessanten Erkenntnissen aus den signifikanten Begriffsaggregationen für iPhone 16-Nutzer vergleichen.

Normale Muster

Um normale Kaufmuster zu verstehen, können wir Daten aus allen Dokumenten und verschiedenen Bereichen aggregieren. Der Einfachheit halber konzentrieren wir uns auf die Berufe der Personen, die ein Telefon gekauft haben. Das können wir mit einer Anfrage an Elasticsearch erreichen.

Dies zeigt uns, dass die häufigsten Berufe im Datensatz (nach Anzahl der Datensätze) folgende sind:

Verhaltensmuster von iPhone 16-Nutzern

Um zu verstehen, was die Käufer eines iPhone 16 auszeichnet, führen wir eine Termaggregation auf demselben Feld mit einem Filter durch, um diese Personen in der Abfrage zu finden, etwa so:

Die häufigsten Berufe für iPhone 16-Nutzer sind also:

Wir können sehen, dass iPhone 16-Nutzer im Vergleich zu Nutzern anderer Telefonmodelle unterschiedliche Beschäftigungsmuster aufweisen. Nutzen wir Kibana, um die Ergebnisse einfach zu visualisieren:

In dieser Grafik können wir sehen, dass der Trend beim iPhone 16 vom Trend der Gesamtbevölkerung abweicht.

Wir können diese gesamte Analyse überspringen und direkt zu den Unterschieden zwischen iPhone 16-Nutzern und der Gesamtbevölkerung gelangen, indem wir eine Aggregation eines einzigen signifikanten Begriffs durchführen:

Kurz gesagt, erhalten wir folgende Antwort:

Werte der Berufe für das iPhone 16

doc_count

bg_count

Berufsverteilung (oberste Ebene)

122

424

Medizin- und Gesundheitsbereich

45

57

Die Reaktion lässt eindeutig darauf schließen, dass iPhone 16-Nutzer ein ungewöhnliches (sprich: signifikantes!) Problem haben. Anzahl der Beschäftigten im medizinischen und Gesundheitsbereich im Vergleich zur Gesamtbevölkerung. Mal sehen, was die Zahlen in der Antwort bedeuten:

• Auf höchster Ebene:

  • Dokumentenanzahl: 122 – Die Abfrage ergab insgesamt 122 Treffer.

  • bg_count: 424 — Der Hintergrundsatz (alle Verkaufsbelege) enthält 424 Belege

• Im Bereich Medizin & Gesundheitswesen:

  • Dokumentanzahl: 45 — „Medizin & Gesundheitswesen“ erscheint in 45 der 122 Suchergebnisse

  • bg_count: 57 — "Medizin & Gesundheitswesen" erscheint in 57 der insgesamt 424 Dokumente im Hintergrunddatensatz

Von 424 Käufern arbeiten 57 im medizinischen und Gesundheitsbereich – das entspricht 13,44 %. Betrachtet man jedoch die Käufer des iPhone 16, so arbeiten 45 von 122 im medizinischen und Gesundheitsbereich – das entspricht 36,88 %. Das bedeutet, dass die Wahrscheinlichkeit, jemanden aus dem medizinischen oder Gesundheitssektor unter den iPhone 16-Nutzern zu finden, doppelt so hoch ist!

Wir können diese Analyse auch auf andere Bereiche (Alter, Standort, Einkommensklasse usw.) anwenden, um mehr Informationen darüber zu erhalten, was die Nutzer des iPhone 16 auszeichnet. 

Kundensegmentierung

Mithilfe der Aggregation signifikanter Begriffe können wir Erkenntnisse über die Beziehungen zwischen Produkten, Kategorien und Kundensegmenten gewinnen. Hierfür erstellen wir eine übergeordnete Aggregation für die Kategorie, die wir genauer untersuchen möchten. Wir verwenden außerdem eine Unteraggregation von signifikanten Begriffen und normalen Begriffen, um interessante Erkenntnisse über diese Kategorie zu gewinnen und sie mit dem zu vergleichen, was die meisten Menschen in diesem Beruf verwenden.

Schauen wir uns beispielsweise an, was Menschen in verschiedenen Berufsfeldern bevorzugen:

1. Um die Analyse übersichtlicher zu gestalten, beschränken wir unsere Suche auf drei Arbeitsbereiche: ["Verwaltung & Support", "Technologie & Daten", "Medizin & Gesundheitswesen"]

2. Auf der Seite der Aggregationen beginnen wir mit einer Termaggregation nach Berufsbezeichnung.

3. Fügen Sie eine Unteraggregation hinzu: Begriffe nach Telefonmodell – um herauszufinden, welche Modelle Nutzer kaufen, die in den jeweiligen Bereichen arbeiten.

4. Fügen Sie eine zweite Unteraggregation hinzu: signifikante Begriffe nach Telefonmodellen – um herauszufinden, welche Modelle in den einzelnen Arbeitsbereichen besonders sind.

Lassen Sie uns die Aggregationsergebnisse im Detail betrachten:

Beruf: Verwaltung & Unterstützung

Termaggregation

Aggregation signifikanter Terme

Aus dieser Tabelle lässt sich schließen, dass es keine signifikanten Unterschiede zwischen dem Trend für diesen Beruf und dem Trend für die Gesamtbevölkerung gibt.

Beruf: Technologie & Daten

Termaggregation

Aggregation signifikanter Terme

Gesamtzahl der Dokumente: 424

Dokumente in diesem Beruf: 71

Telefonmodell

doc_count (dieses Modell in diesem Beruf)

bg_count (Dieses Modell ist in allen Dokumenten enthalten)

% in allen Dokumenten

% in diesem Beruf

Google Pixel 8

12

22

5,19 %

16,90 %

OnePlus 11

9

14

3,30 %

12,68 %

OnePlus 12 Pro

3

3

0,71 %

4,23 %

Google Pixel 8 Pro

9

21

4,95 %

12,68 %

Nichts Telefon 2

5

8

1,89 %

7,04 %

Samsung Galaxy Z Fold5

4

6

1,42 %

5,63 %

OnePlus 12

8

20

4,72 %

11,27 %

Beruf: Medizin & Gesundheitswesen

Termaggregation

Aggregation signifikanter Terme

Gesamtzahl der Dokumente: 424

Dokumente in diesem Beruf: 57

Telefonmodell

doc_count (dieses Modell in diesem Beruf)

bg_count (Dieses Modell ist in allen Dokumenten enthalten)

% in allen Dokumenten

% in diesem Beruf

iPhone 16

45

122

28,77 %

78,95 %

iPhone 15 Pro Max

3

13

3,07 %

5,26 %

iPhone 15

7

40

9,43 %

12,28 %

Mal sehen, welche Geschichte uns diese Daten erzählen:

• Medizinisches Fachpersonal und Angehörige von Gesundheitsberufen bevorzugen das iPhone 16 und neigen generell sehr dazu, Apple-Handys zu benutzen.

• Technologie- und Datenexperten bevorzugen High-End-Android-Smartphones, greifen aber nicht unbedingt auf die Marke Samsung zurück. Auch in dieser Kategorie ist ein deutlicher Trend zu iPhones zu beobachten.

• Bei Verwaltungs- und Supportmitarbeitern sind Samsung- und Google-Handys beliebt, es gibt jedoch keinen ausgeprägten und eindeutigen Trend.

Aggregation signifikanter Begriffe und Hybridsuche

Die Hybridsuche kombiniert Textsuche und semantische Ergebnisse, um ein verbessertes Sucherlebnis zu bieten. In diesem Kontext kann eine aussagekräftige Termaggregation Aufschluss über die Ergebnisse einer kontextbezogenen Suche geben, indem sie die Frage beantwortet: Was ist das Besondere an diesem Datensatz im Vergleich zu allen Dokumenten?Um diese Funktion zu veranschaulichen, sehen wir uns an, welche Modelle überrepräsentiert sind, wenn Nutzer von guter Leistung sprechen:

• Wir erstellen eine semantische Abfrage, bei der wir das beste Nutzerfeedback finden, das dem Eingabetext „gute Leistung“ im Feld „Einbettung“ am nächsten kommt.

• Wir werden außerdem eine Textsuche mit denselben Begriffen im Textfeld user_feedback durchführen.

• Wir werden außerdem eine Abfrage mit aussagekräftigen Begriffen hinzufügen, um Telefonmodelle zu finden, die in diesen Ergebnissen häufiger vorkommen als im gesamten Datensatz.

Betrachten wir ein Beispiel für die übereinstimmenden Dokumente:

Das ist die Antwort, die wir erhalten:

Dies bedeutet, dass ein iPhone 15 zwar 40 Mal in insgesamt 424 Dokumenten vorkommt (9,4 % der Dokumente), es aber 5 Mal in den 20 Dokumenten zu finden ist, die der semantischen Suche „gute Leistung“ entsprechen (25 % der Dokumente). Daraus lässt sich schließen: Die Wahrscheinlichkeit, ein iPhone 15 zu finden, ist 2,7-mal höher, wenn es um gute Leistung geht, als durch Zufall.

Fazit

Durch die Aggregation signifikanter Terme lassen sich einzigartige Details eines Datensatzes aufdecken, indem man ihn mit der Gesamtheit aller Dokumente vergleicht. Dadurch können unerwartete Zusammenhänge in unseren Daten aufgedeckt werden, die über die reine Anzahl der Vorkommen hinausgehen. Wir können in verschiedenen Anwendungsfällen aussagekräftige Begriffe einsetzen, die sehr interessante Funktionen ermöglichen, zum Beispiel:

• Bei der Betrugserkennung sollten Sie Muster erkennen – identifizieren Sie typische Transaktionen gestohlener Kreditkarten.

• Markenqualitätseinblicke aus Nutzerbewertungen – Marken mit einer unverhältnismäßig hohen Anzahl schlechter Bewertungen erkennen.

• Aufspüren falsch klassifizierter Dokumente – Aufspüren von Dokumenten, die zu einer Kategorie gehören (Termfilter), die in einer Beschreibung ungewöhnliche Wörter für die Kategorie verwenden (Aggregation signifikanter Begriffe).

Für Elasticsearch werden wir Elastic Cloud on Kubernetes (ECK) verwenden, den offiziellen Elasticsearch Kubernetes-Operator, der die Orchestrierung von Kubernetes-Deployments aller Elastic Stack-Komponenten vereinfacht.

Um mehr darüber zu erfahren, wie man Elasticsearch-Cluster auf verschiedenen Google-Cloud-Platform-Infrastrukturen bereitstellt, können Sie unsere Einstiegsartikel für Google Cloud Compute und Google Cloud Marketplace lesen.

Aufwand für die Bereitstellung von Elasticsearch

Was ist GKE Autopilot?

Google Kubernetes Engine (GKE) Autopilot bietet ein vollständig verwaltetes Kubernetes-Erlebnis, bei dem Google die Clusterkonfiguration, das Node-Management, die Security und das Skalieren übernimmt, während Entwickler sich auf die Bereitstellung von Anwendungen konzentrieren, sodass Teams mit integrierten Best Practices in wenigen Minuten vom Code zur Produktion gelangen können.

Wann sollte man ECK in Google Cloud nutzen?

Elastic Cloud on Kubernetes (ECK) eignet sich besonders für Unternehmen mit einer bestehenden Kubernetes-Infrastruktur, die Elasticsearch mit erweiterten Funktionen wie dedizierten Knotenrollen, hoher Verfügbarkeit und Automatisierung bereitstellen möchten.

Wie richtet man ECK in Google Cloud ein?

1. Melden Sie sich in der Google Cloud Console an.

2. Klicken Sie oben rechts auf die Cloud-Shell-Taste, um auf die Konsole zuzugreifen, und stellen Sie von dort aus den GKE-Cluster bereit. Alternativ können Sie auch gcloud CLI verwenden.

Denken Sie daran, die Projekt-ID während des Tutorials durch Ihre eigene zu ersetzen.

3. Aktivieren Sie die Google Kubernetes Engine API.

Klicken Sie auf Next (Weiter).

Nun sollte die Kubernetes Engine API als aktiviert angezeigt werden, wenn nach der Kubernetes Engine API gesucht wird.

4. In der Cloud Shell einen Autopilot-Cluster erstellen. Wir werden es „autopilot-cluster-1“ benennen und außerdem „autopilot-test“ durch die ID Ihres Projekts ersetzen.

5. Warten Sie, bis es bereit ist. Die Erstellung dauert etwa 10 Minuten.

Nach der korrekten Einrichtung des Clusters wird eine Bestätigungsmeldung angezeigt.

6. Konfigurieren Sie den Zugriff auf die „kubectl“-Befehlszeile.

Sie sollten sehen:

Für autopilot-cluster-1 wurde ein „kubeconfig“-Eintrag generiert.

7. Installieren Sie den Elastic Cloud on Kubernetes (ECK)-Operator.

8. Lassen Sie uns eine Elasticsearch-Instanz mit einem einzelnen Knoten und den Standardwerten erstellen.

Wenn Sie einige Rezepte für verschiedene Setups prüfen möchten, können Sie diesen Link besuchen.

Bitte beachten Sie, dass ECK, wenn Sie kein storageClass angeben, den standardmäßig festgelegten Wert verwendet, der für GKE standard-rwo ist und den Compute Engine Persistent Disk CSI Driver nutzt, und damit ein 1-GB-Volume erstellt.

Wir haben nmap deaktiviert, da die Standard-GKE-Maschine einen zu niedrigen Wert für vm.max_map_count hat. Für den Produktivbetrieb wird von einer Deaktivierung abgeraten; stattdessen sollte der Wert von vm.max_map_count erhöht werden. Mehr darüber, wie Sie das machen, können Sie hier lesen.

9. Lassen Sie uns außerdem einen Kibana-Cluster mit einem einzelnen Knoten bereitstellen. Für Kibana fügen wir einen LoadBalancer hinzu, der uns eine externe IP-Adresse bereitstellt, über die wir Kibana von unserem Gerät aus erreichen können.

Beachten Sie die Anmerkung:

cloud.google.com/l4-rbs: "enabled"

Das ist sehr wichtig, weil es Autopilot anweist, einen öffentlich zugänglichen LoadBalancer bereitzustellen. Falls nicht festgelegt, wird der LoadBalancer intern verwendet.

10. Prüfen Sie, ob Ihre Pods laufen

11. Sie können auch run kubectl get elasticsearch und kubectl get kibana für spezifischere Statistiken wie Elasticsearch-Version, Nodes und Health verwenden.

12. Greifen Sie auf Ihre Dienste zu.

Hier wird Ihnen die externe URL für Kibana unter EXTERNAL-IP angezeigt. Es kann einige Minuten dauern, bis der LoadBalancer bereitgestellt wird. Kopieren Sie den Wert von EXTERNAL-IP.

13. Ermitteln Sie das Elasticsearch-Passwort für den Nutzer „elastic“:

14. Greifen Sie über Ihren Browser auf Kibana zu:

• URL: https://<EXTERNAL_IP>:5601

• Benutzername:elastic

• Passwort: 28Pao50lr2GpyguX470L2uj5 (aus dem vorherigen Schritt)

15. Wenn Sie von Ihrem Browser aus zugreifen, wird der Willkommensbildschirm angezeigt.

Wenn Sie die Spezifikationen des Elasticsearch-Clusters ändern möchten, z. B. Knoten ändern oder die Größe anpassen, können Sie das yml-Manifest mit den neuen Einstellungen erneut anwenden:

In diesem Beispiel fügen wir einen weiteren Node hinzu und ändern RAM sowie CPU. Wie Sie sehen, zeigt kubectl get elasticsearch jetzt 2 Knoten:

Das Gleiche gilt für Kibana:

Wir können die CPU/RAM des Containers sowie die Speichernutzung von Node.js (max-old-space-size) anpassen.

Denken Sie daran, dass bestehende Volumenbehauptungen nicht verkleinert werden können. Nach der Installation des Updates wird der Betreiber die Änderungen mit minimaler Ausfallzeit vornehmen.

Denken Sie daran, den Cluster nach dem Testen zu löschen, um unnötige Kosten zu vermeiden.

Wie geht es weiter?

Wenn Sie mehr über Kubernetes und die Google Kubernetes Engine erfahren möchten, lesen Sie diese Artikel:

• Elastic Cloud auf Kubernetes | Elastic Docs

• Einführung von GKE Autopilot | Google Cloud Blog

• Autopilot-Überblick | Google Kubernetes Engine (GKE)

Wir werden Folgendes überprüfen:

• Best Practices für die Produktion

  • Fehlerbehandlung

  • Tests

• Serverlose Umgebungen

  • Den Client auf Elastic Serverless ausführen

  • Ausführen des Clients in einer Function-as-a-Service-Umgebung

Den Quellcode mit den Beispielen finden Sie hier.

Best Practices für die Produktion

Fehlerbehandlung in Elasticsearch

Ein nützliches Feature des Elasticsearch-Clients in Node.js ist, dass er Objekte für die möglichen Fehler in Elasticsearch bereitstellt, sodass man diese auf verschiedene Weise validieren und behandeln kann.

Um sie alle zu sehen, führen Sie folgenden Befehl aus: 

Kehren wir zum Suchbeispiel zurück und behandeln wir einige der möglichen Fehler:

ResponseError Dies tritt insbesondere dann auf, wenn die Antwort 4xx oder 5xx lautet, was bedeutet, dass die Anfrage fehlerhaft ist oder der Server nicht verfügbar ist.

Wir können diese Art von Fehler testen, indem wir fehlerhafte Abfragen generieren, beispielsweise den Versuch, eine Termabfrage für ein Textfeld durchzuführen:

Standardfehler:

Benutzerdefinierter Fehler:

Wir können auch jeden Fehlertyp auf eine bestimmte Weise erfassen und behandeln. Zum Beispiel können wir in einem TimeoutError eine Wiederholungslogik hinzufügen.

Tests

Tests sind entscheidend, um die Stabilität der App zu gewährleisten. Um den Code auf eine von Elasticsearch isolierte Weise zu testen, können wir die Bibliothek elasticsearch-js-mock beim Erstellen unseres Clusters verwenden.

Mithilfe dieser Bibliothek können wir einen Client instanziieren, der dem realen Client sehr ähnlich ist, aber auf unsere Konfiguration reagiert, indem wir lediglich die HTTP-Schicht des Clients durch eine simulierte Schicht ersetzen, während der Rest mit dem Original übereinstimmt.

Wir werden die Mock-Bibliothek und AVA für automatisierte Tests installieren.

npm install @elastic/elasticsearch-mock

npm install --save-dev ava

Wir werden die Datei package.json so konfigurieren, dass die Tests ausgeführt werden. Stellen Sie sicher, dass es so aussieht:

Erstellen wir nun eine test.js -Datei und installieren wir unseren Mock-Client:

Fügen Sie nun ein Mock-Objekt für die semantische Suche hinzu:

Wir können nun einen Test für unseren Code erstellen, um sicherzustellen, dass der Elasticsearch-Teil immer die gleichen Ergebnisse liefert:

Lasst uns die Tests durchführen.

npm run test

Erledigt! Ab sofort können wir unsere App testen und uns dabei zu 100 % auf den Code konzentrieren, ohne uns von externen Faktoren beeinflussen zu lassen.

Serverlose Umgebungen

Wie Sie den Client auf Elastic Serverless ausführen

Wir haben die Ausführung von Elasticsearch in der Cloud oder lokal behandelt; der Node.js-Client unterstützt jedoch auch Verbindungen zu Elastic Cloud Serverless.

Mit Elastic Cloud Serverless können Sie ein Projekt erstellen, bei dem Sie sich keine Gedanken um die Infrastruktur machen müssen, da Elastic dies intern übernimmt. Sie müssen sich nur um die Daten kümmern, die Sie indizieren möchten, und darum, wie lange Sie darauf zugreifen möchten.

Aus Nutzersicht entkoppelt Serverless Rechenleistung von Speicher und bietet automatische Skalierungsfunktionen sowohl für die Suche als auch für die Indizierung. Dadurch können Sie nur die Ressourcen anbauen, die Sie tatsächlich benötigen.

Der Client nimmt folgende Anpassungen vor, um eine Verbindung zu Serverless herzustellen:

• Deaktiviert das Sniffing und ignoriert alle Sniffing-bezogenen Optionen.

• Ignoriert alle in der Konfiguration übergebenen Knoten außer dem ersten und ignoriert jegliche Knotenfilter- und Auswahloptionen.

• Aktiviert Komprimierung und `TLSv1_2_method` (genau wie bei der Konfiguration für Elastic Cloud).

• Fügt allen Anfragen einen HTTP-Header `elastic-api-version` hinzu

• Verwendet standardmäßig `CloudConnectionPool` anstelle von `WeightedConnectionPool`.

• Deaktiviert die vom Anbieter bereitgestellten `content-type`- und `accept`-Header zugunsten der Standard-MIME-Typen.

Um Ihr serverloses Projekt zu verbinden, müssen Sie den Parameter serverMode: serverless verwenden.

Wie Sie den Client in einer Function-as-a-Service-Umgebung ausführen

In diesem Beispiel haben wir einen Node.js-Server verwendet, aber Sie können auch über eine Function-as-a-Service-Umgebung mit Funktionen wie AWS Lambda, GCP Run usw. eine Verbindung herstellen.

Ein weiteres Beispiel ist die Anbindung an Dienste wie Vercel, das ebenfalls serverlos ist. Sie können sich dieses vollständige Beispiel ansehen, wie das geht, aber der relevanteste Teil des Suchendpunkts sieht folgendermaßen aus:

Dieser Endpunkt befindet sich im Ordner /api und wird serverseitig ausgeführt, sodass der Client nur über den Parameter „text“ verfügt, der dem Suchbegriff entspricht.

Die Konsequenz aus der Verwendung von Function-as-a-Service ist, dass Funktionen, im Gegensatz zu einem Server, der rund um die Uhr läuft, nur die Maschine starten, auf der die Funktion ausgeführt wird, und dass die Maschine nach Beendigung der Funktion in den Ruhemodus wechselt, um weniger Ressourcen zu verbrauchen.

Diese Konfiguration kann praktisch sein, wenn die Anwendung nicht zu viele Anfragen erhält; andernfalls können die Kosten hoch sein. Sie müssen auch den Lebenszyklus der Funktionen und die Laufzeiten berücksichtigen (die in manchen Fällen nur Sekunden betragen können).

Fazit

In diesem Artikel haben wir gelernt, wie man mit Fehlern umgeht, was in Produktionsumgebungen von entscheidender Bedeutung ist. Wir haben auch das Testen unserer Anwendung unter Verwendung von Mocking für den Elasticsearch-Dienst behandelt. Dies ermöglicht zuverlässige Tests unabhängig vom Zustand des Clusters und erlaubt es uns, uns auf unseren Code zu konzentrieren.

Zum Schluss demonstrierten wir, wie man einen vollständig serverlosen Stack einrichtet, indem man sowohl Elastic Cloud Serverless als auch eine Vercel-Anwendung bereitstellt.

Hintergrundinformationen zu Wasserzeichen

In Ihrem Elasticsearch-Cluster gibt es verschiedene „Wasserzeichen“-Schwellenwerte, die Ihnen helfen, den verfügbaren Speicherplatz zu überwachen. Wenn der Speicherplatz auf einem Knoten fast aufgebraucht ist, wird als erstes der Schwellenwert „niedriger Speicherplatz“ überschritten. Der zweite Schwellenwert wird dann der „hohe Festplatten-Wasserzeichen-Schwellenwert“ sein. Schließlich wird das Stadium der „Scheibenflutung“ erreicht. Sobald dieser Schwellenwert überschritten ist, blockiert der Cluster das Schreiben in ALLE Indizes, die einen Shard (primär oder Replikat) auf dem Knoten haben, der den Schwellenwert überschritten hat. Lesevorgänge (Suchanfragen) bleiben weiterhin möglich.

Wie man Fälle von zu voller Festplatte (Überauslastung) verhindert und damit umgeht

Es gibt verschiedene Methoden, um mit Fällen umzugehen, in denen Ihre Elasticsearch-Festplatte zu voll ist:

1. Alte Daten löschen : Daten sollten in der Regel nicht unbegrenzt aufbewahrt werden. Eine Möglichkeit, einer zu vollen Festplatte vorzubeugen und das Problem zu lösen, besteht darin, sicherzustellen, dass Daten, sobald sie ein bestimmtes Alter erreichen, zuverlässig archiviert und gelöscht werden. Eine Möglichkeit hierfür ist die Verwendung von ILM.

2. Speicherkapazität hinzufügen: Wenn Sie die Daten nicht löschen können, sollten Sie möglicherweise weitere Datenknoten hinzufügen oder die Festplattengrößen erhöhen, um alle Daten zu erhalten, ohne die Leistung negativ zu beeinflussen. Wenn Sie die Speicherkapazität des Clusters erhöhen müssen, sollten Sie überlegen, ob Sie nur die Speicherkapazität allein oder auch RAM- und CPU-Ressourcen im entsprechenden Verhältnis hinzufügen müssen (siehe Abschnitt zum Verhältnis von Festplattengröße, RAM und CPU weiter unten).

So fügen Sie Ihrem Elasticsearch-Cluster Speicherkapazität hinzu

1. Erhöhen Sie die Anzahl der Datenknoten: Denken Sie daran, dass die neuen Knoten die gleiche Größe wie die vorhandenen Knoten und die gleiche Elasticsearch-Version haben sollten.

2. Vergrößerung der vorhandenen Knoten: In Cloud-basierten Umgebungen ist es in der Regel einfach, die Festplattengröße und den Arbeitsspeicher/die CPU auf vorhandenen Knoten zu erhöhen.

3. Erhöhen Sie nur die Festplattengröße: In Cloud-basierten Umgebungen ist es oft relativ einfach, die Festplattengröße zu erhöhen.

4. Schnappschuss Und Wiederherstellung: Wenn Sie es zulassen, dass alte Daten auf Anfrage in einem automatisierten Prozess aus Backups wiederhergestellt werden, können Sie alte Indizes als Snapshots speichern, diese löschen und die Daten auf Anfrage temporär aus den Snapshots wiederherstellen. 

5. Reduzierung der Replikate pro Shard: Eine weitere Möglichkeit zur Datenreduzierung besteht darin, die Anzahl der Replikate jedes Shards zu verringern. Für eine hohe Verfügbarkeit ist es wünschenswert, pro Shard eine Replik zu haben. Wenn die Daten jedoch älter werden, kann man unter Umständen auch ohne Replikate arbeiten. Das funktioniert in der Regel, wenn die Daten persistent sind oder Sie über eine Datensicherung verfügen, die Sie bei Bedarf wiederherstellen können.

6. Benachrichtigungen erstellen: Um zu verhindern, dass die Festplatte in Zukunft voll wird und um proaktiv handeln zu können, sollten Sie Benachrichtigungen auf Basis der Festplattennutzung erstellen, die Sie benachrichtigen, wenn die Festplatte sich zu füllen beginnt. 

Wie man Fälle von unzureichender Festplattenauslastung verhindert und behandelt

Wenn Ihre Festplattenkapazität nicht voll ausgelastet ist, gibt es verschiedene Möglichkeiten, das Speichervolumen in Ihrem Cluster zu reduzieren.

Wie man das Speichervolumen eines Elasticsearch-Clusters reduziert

Es gibt verschiedene Methoden, um das Speichervolumen eines Clusters zu reduzieren.

1. Die Anzahl der Datenknoten reduzieren

Wenn Sie den Datenspeicherbedarf reduzieren und gleichzeitig RAM- und CPU-Ressourcen im gleichen Verhältnis einsparen möchten, dann ist dies die einfachste Strategie. Die Stilllegung nicht benötigter Knotenpunkte dürfte die größten Kosteneinsparungen ermöglichen.

Vor der Außerbetriebnahme des Knotens sollten Sie Folgendes beachten:

• Stellen Sie sicher, dass der außer Betrieb zu nehmende Knoten nicht als MASTER-Knoten benötigt wird. Sie sollten immer mindestens drei Knoten mit der MASTER-Knotenrolle haben.

• Die Datenfragmente müssen von dem außer Betrieb zu nehmenden Knoten migriert werden.

2. Ersetzen Sie die vorhandenen Knoten durch kleinere Knoten.

Wenn Sie die Anzahl der Knoten nicht weiter reduzieren können (normalerweise wären 3 die Mindestkonfiguration), dann sollten Sie die vorhandenen Knoten verkleinern. Denken Sie daran, dass es ratsam ist, sicherzustellen, dass alle Datenknoten über den gleichen Arbeitsspeicher und die gleiche Festplattengröße verfügen, da der Shard-Ausgleich auf der Grundlage der Anzahl der Shards pro Knoten erfolgt.

Der Ablauf wäre wie folgt:

• Fügen Sie dem Cluster neue, kleinere Knoten hinzu.

• Die Shards von den außer Betrieb zu nehmenden Knoten migrieren

• Schalten Sie die alten Knoten ab.

3. Verringern Sie die Festplattengröße auf den Knoten.

Wenn Sie NUR die Festplattengröße auf den Knoten reduzieren möchten, ohne den gesamten RAM oder die CPU des Clusters zu verändern, dann können Sie die Festplattengröße für jeden Knoten reduzieren. Die Reduzierung der Festplattengröße auf einem Elasticsearch-Knoten ist kein trivialer Prozess.

Am einfachsten ginge das in der Regel so:

• Shards vom Knoten migrieren

• Stoppe den Knoten

• Hängen Sie ein neues Datenvolume mit geeigneter Größe an den Knoten an.

• Kopieren Sie alle Daten vom alten Datenträger auf den neuen Datenträger.

• Altes Volume A abtrennen

• Startknoten und Shards zurück zum Knoten migrieren

Dies setzt voraus, dass auf den anderen Knoten ausreichend Kapazität vorhanden ist, um die zusätzlichen Shards des Knotens während dieses Prozesses vorübergehend zu speichern. In vielen Fällen können die Kosten für die Verwaltung dieses Prozesses die potenziellen Einsparungen bei der Festplattennutzung übersteigen. Aus diesem Grund ist es unter Umständen einfacher, den Knoten komplett durch einen neuen Knoten mit der gewünschten Festplattengröße zu ersetzen (siehe oben „Ersetzen vorhandener Knoten durch kleinere Knoten“).

Wenn man für unnötige Ressourcen bezahlt, können die Kosten offensichtlich durch eine Optimierung der Ressourcennutzung reduziert werden.

Das Verhältnis zwischen Festplattengröße, RAM und CPU

Das ideale Verhältnis von Festplattenkapazität zu Arbeitsspeicher in Ihrem Cluster hängt von Ihrem jeweiligen Anwendungsfall ab. Aus diesem Grund sollten Sie bei der Überlegung von Änderungen Ihrer Speicherkapazität auch berücksichtigen, ob Ihre aktuellen Verhältnisse von Festplatte, Arbeitsspeicher und CPU angemessen ausbalanciert sind und ob Sie infolgedessen auch Arbeitsspeicher und CPU im gleichen Verhältnis hinzufügen oder reduzieren müssen.

Der Bedarf an RAM und CPU hängt vom Umfang der Indizierungsaktivität , der Anzahl und Art der Abfragen sowie der Menge der zu durchsuchenden und zu aggregierenden Daten ab. Dies steht oft im Verhältnis zur Menge der auf dem Cluster gespeicherten Daten und sollte daher auch mit der Festplattengröße in Zusammenhang stehen.

Das Verhältnis zwischen Festplattenkapazität und Arbeitsspeicher kann je nach Anwendungsfall variieren. Hier einige Beispiele:

Indexaktivität

Aufbewahrung

Suchaktivität

Festplattenkapazität

RAM

Unternehmenssuch-App

Mäßige Holzaufnahme

Lang

Licht

2 TB

32 GB

App-Überwachung

Intensive Holzverarbeitung

Kurz

Licht

1 TB

32 GB

E-Commerce

Light-Datenindexierung

Unbestimmt

Schwer

500 GB

32 GB

Denken Sie daran, dass Änderungen an der Konfiguration von Node-Maschinen mit Vorsicht vorgenommen werden müssen, da dies zu Ausfallzeiten der Nodes führen kann und Sie sicherstellen müssen, dass Shards nicht auf Ihre anderen, bereits überlasteten Nodes migriert werden.

In diesem ersten Teil werden wir Folgendes besprechen:

• Umfeld

  • Frontend, Backend oder serverlos?

  • Verbindung des Clients

• Dokumente indizieren

  • Elasticsearch-Client

  • Semantische Zuordnungen

  • Schüttguthelfer

• Datensuche

  • Lexikalische Abfrage

  • Semantische Anfrage

  • Hybridabfrage

Den Quellcode mit den Beispielen finden Sie hier.

Was ist der Elasticsearch Node.js-Client?

Der Elasticsearch Node.js-Client ist eine JavaScript-Bibliothek, die die HTTP-REST-Aufrufe der Elasticsearch-API in JavaScript umsetzt. Dadurch wird die Handhabung einfacher und es stehen Hilfsfunktionen zur Verfügung, die Aufgaben wie das Indizieren von Dokumenten in Stapeln vereinfachen.

Umfeld

Frontend, Backend oder serverlos?

Um unsere Such-App mit dem JavaScript-Client zu erstellen, benötigen wir mindestens zwei Komponenten: einen Elasticsearch-Cluster und eine JavaScript-Laufzeitumgebung zum Ausführen des Clients.

Der JavaScript-Client unterstützt alle Elasticsearch-Lösungen (Cloud, On-Premise und Serverless), und es gibt keine wesentlichen Unterschiede zwischen ihnen, da der Client alle Varianten intern handhabt, sodass Sie sich keine Gedanken darüber machen müssen, welche Sie verwenden sollen.

Die JavaScript-Laufzeitumgebung muss jedoch vom Server und nicht direkt vom Browser ausgeführt werden.

Dies liegt daran, dass beim Aufruf von Elasticsearch über den Browser sensible Informationen wie der Cluster-API-Schlüssel, der Host oder die Abfrage selbst abgerufen werden können. Elasticsearch empfiehlt, den Cluster niemals direkt dem Internet auszusetzen und stattdessen eine Zwischenschicht zu verwenden, die all diese Informationen abstrahiert, sodass der Benutzer nur die Parameter sehen kann. Hier können Sie mehr zu diesem Thema lesen.

Wir schlagen vor, folgendes Schema zu verwenden:

In diesem Fall sendet der Client lediglich die Suchbegriffe und einen Authentifizierungsschlüssel an Ihren Server, während Ihr Server die vollständige Kontrolle über die Abfrage und die Kommunikation mit Elasticsearch behält.

Verbindung des Clients

Erstellen Sie zunächst einen API-Schlüssel gemäß diesen Schritten.

Im Anschluss an das vorherige Beispiel erstellen wir einen einfachen Express-Server und stellen über einen Client von einem Node.JS-Server aus eine Verbindung zu diesem her.

Wir werden das Projekt mit NPM initialisieren und den Elasticsearch-Client sowie Express installieren. Letzteres ist eine Bibliothek zum Starten von Servern in Node.js. Mit Express können wir über HTTP mit unserem Backend interagieren.

Lasst uns das Projekt initialisieren:

npm init -y

Abhängigkeiten installieren:

npm install @elastic/elasticsearch express split2 dotenv

Ich erkläre es Ihnen genauer:

• @elastic/elasticsearch: Es handelt sich um den offiziellen Node.js-Client.

• Express: Damit können wir einen schlanken Node.js-Server starten, um Elasticsearch bereitzustellen.

• split2: Teilt Textzeilen in einen Datenstrom auf. Nützlich, um unsere ndjson-Dateien zeilenweise zu verarbeiten.

• dotenv: Ermöglicht die Verwaltung von Umgebungsvariablen mithilfe einer .env-Datei. Datei

Erstelle eine .env-Datei Fügen Sie in der Datei im Stammverzeichnis des Projekts die folgenden Zeilen hinzu:

Auf diese Weise können wir diese Variablen mithilfe des Pakets dotenv importieren.

Erstelle eine server.js -Datei:

Dieser Code richtet einen einfachen Express.js-Server ein, der auf Port 3000 lauscht und sich über einen API-Schlüssel zur Authentifizierung mit einem Elasticsearch-Cluster verbindet. Es beinhaltet einen /ping-Endpunkt, der bei einem GET-Aufruf mithilfe der .info() -Methode des Elasticsearch-Clients grundlegende Informationen vom Elasticsearch-Cluster abfragt. 

Bei erfolgreicher Abfrage werden die Clusterinformationen im JSON-Format zurückgegeben; andernfalls wird eine Fehlermeldung zurückgegeben. Der Server verwendet außerdem die Middleware body-parser, um JSON-Anfragetexte zu verarbeiten.

Führen Sie die Datei aus, um den Server zu starten:

node server.js

Die Antwort sollte folgendermaßen aussehen:

Und nun konsultieren wir den Endpunkt /ping , um den Status unseres Elasticsearch-Clusters zu überprüfen.

Dokumente indizieren

Sobald die Verbindung hergestellt ist, können wir Dokumente mithilfe von Zuordnungen wie semantic_text für die semantische Suche und text für Volltextabfragen indizieren. Mit diesen beiden Feldtypen können wir auch eine hybride Suche durchführen.

Wir erstellen eine neue load.js -Datei, um die Zuordnungen zu generieren und die Dokumente hochzuladen.

Elasticsearch-Client

Zuerst müssen wir den Client instanziieren und authentifizieren:

Semantische Zuordnungen

Wir erstellen einen Index mit Daten über Tierkliniken. Wir speichern die Informationen über den Besitzer, das Haustier und die Details des Besuchs.

Die Daten, in denen wir eine Volltextsuche durchführen möchten, wie zum Beispiel Namen und Beschreibungen, werden als Text gespeichert. Die Daten aus Kategorien, wie zum Beispiel die Tierart oder -rasse, werden als Schlüsselwörter gespeichert.

Zusätzlich kopieren wir die Werte aller Felder in ein semantisches Textfeld, um auch mit diesen Informationen eine semantische Suche durchführen zu können.

Schüttguthelfer

Ein weiterer Vorteil des Clients besteht darin, dass wir den Bulk-Helper verwenden können, um die Indizierung in Batches durchzuführen. Der Bulk-Helper ermöglicht es uns, Dinge wie Parallelverarbeitung, Wiederholungsversuche und die Behandlung jedes Dokuments, das die Funktion durchläuft und erfolgreich oder fehlschlägt, einfach zu handhaben.

Ein attraktives Merkmal dieses Helfers ist, dass man mit Datenströmen arbeiten kann. Mit dieser Funktion können Sie eine Datei zeilenweise senden, anstatt die gesamte Datei im Speicher zu speichern und sie dann auf einmal an Elasticsearch zu senden.

Um die Daten in Elasticsearch hochzuladen, erstellen Sie eine Datei namens data.ndjson im Stammverzeichnis des Projekts und fügen Sie die folgenden Informationen hinzu (alternativ können Sie die Datei mit dem Datensatz hier herunterladen):

Wir verwenden split2, um die Dateizeilen zu streamen, während der Bulk-Helper sie an Elasticsearch sendet.

Der obige Code liest eine .ndjson-Datei. Mit der Methode helpers.bulk werden alle JSON-Objekte zeilenweise und in einem Massenindex in einen angegebenen Elasticsearch-Index indiziert. Es streamt die Datei mit createReadStream und split2, richtet Indexierungsmetadaten für jedes Dokument ein und protokolliert alle Dokumente, deren Verarbeitung fehlschlägt. Nach Abschluss des Vorgangs wird die Anzahl der erfolgreich indizierten Elemente protokolliert.

Alternativ zur indexData -Funktion können Sie die Datei auch direkt über die Benutzeroberfläche von Kibana hochladen und dabei die Funktion „Datendateien hochladen“ verwenden.

Wir führen die Datei aus, um die Dokumente in unseren Elasticsearch-Cluster hochzuladen.

node load.js

Datensuche in Elasticsearch

Wir kehren zu unserer server.js -Datei zurück und erstellen verschiedene Endpunkte, um lexikalische, semantische oder hybride Suchen durchzuführen.

Kurz gesagt, schließen sich diese Sucharten nicht gegenseitig aus, sondern hängen von der Art der Frage ab, die Sie beantworten möchten.

Abfragetyp

Anwendungsfall

Beispielaufgabe

Lexikalische Abfrage

Die in der Frage vorkommenden Wörter oder Wortstämme tauchen wahrscheinlich in den Indexdokumenten auf. Tokenische Ähnlichkeit zwischen Frage und Dokumenten.

Ich suche ein blaues Sport-T-Shirt.

Semantische Anfrage

Die in der Frage enthaltenen Wörter werden in den Dokumenten wahrscheinlich nicht vorkommen. Konzeptionelle Ähnlichkeit zwischen Frage und Dokumenten.

Ich suche Kleidung für kaltes Wetter.

Hybrid Search

Die Frage enthält lexikalische und/oder semantische Komponenten. Token- und semantische Ähnlichkeit zwischen Frage und Dokumenten.

Ich suche ein Kleid in Größe S für eine Strandhochzeit.

Die lexikalischen Bestandteile der Frage sind wahrscheinlich Teil von Titeln und Beschreibungen oder Kategorienamen, während die semantischen Bestandteile Konzepte sind, die mit diesen Bereichen in Zusammenhang stehen. Blau wird wahrscheinlich ein Kategoriename oder Teil einer Beschreibung sein, Strandhochzeit hingegen eher nicht, kann aber semantisch mit Leinenkleidung in Verbindung gebracht werden.

Lexikalische Abfrage (/search/lexic?q=)<query_term>

Die lexikalische Suche, auch Volltextsuche genannt, bedeutet die Suche auf der Grundlage der Ähnlichkeit von Wörtern; das heißt, nach einer Analyse werden die Dokumente zurückgegeben, die die gesuchten Wörter enthalten.

Hier finden Sie unser praktisches Tutorial zur lexikalischen Suche.

Wir testen mit: Krallenschneiden

Antwort:

Semantische Abfrage (/search/semantic?q=)<query_term>

Die semantische Suche findet, anders als die lexikalische Suche, Ergebnisse, die der Bedeutung der Suchbegriffe ähneln, durch Vektorsuche.

Hier finden Sie unser praktisches Tutorial zur semantischen Suche.

Wir testen mit: Wer hat sich eine Pediküre machen lassen?

Antwort:

Hybrid-Suchanfrage (/search/hybrid?q=)<query_term>

Die Hybridsuche ermöglicht es uns, semantische und lexikalische Suche zu kombinieren und so das Beste aus beiden Welten zu erhalten: Sie erhalten die Präzision der Token-Suche zusammen mit der Bedeutungsnähe der semantischen Suche.

Wir testen mit der Frage: „ Wer hat sich eine Pediküre oder eine Zahnbehandlung gegönnt?“

Abwehr:

Fazit

Im ersten Teil unserer Serie haben wir erklärt, wie man die Umgebung einrichtet und einen Server mit verschiedenen Suchendpunkten erstellt, um die Elasticsearch-Dokumente gemäß den Best Practices für Client/Server abzufragen. Schauen Sie sich den zweiten Teil unserer Serie an, in dem Sie Best Practices für die Produktion kennenlernen und erfahren, wie Sie den Elasticsearch Node.js-Client in serverlosen Umgebungen ausführen.

Die Rolle von Replikaten in Elasticsearch

In Elasticsearch ist ein Index eine Sammlung von Dokumenten, die auf mehrere primäre Shards verteilt sind. Jeder primäre Shard ist ein in sich geschlossener Apache Lucene-Index, und die Dokumente innerhalb eines Index werden auf alle primären Shards verteilt. Um eine hohe Verfügbarkeit und Datenredundanz zu gewährleisten, ermöglicht Elasticsearch, dass jeder Shard eine oder mehrere Kopien, sogenannte Replikate, besitzt. Die Einstellung number_of_replicas steuert die Anzahl der Replikat-Shards (Kopien), die Elasticsearch für jeden primären Shard in einem Index erstellt. Standardmäßig erstellt Elasticsearch für jeden primären Shard eine Replik, dies kann jedoch je nach den Anforderungen Ihres Systems geändert werden.

Konfigurieren der Anzahl der Replikate

Die Einstellung number_of_replicas kann bei der Indexerstellung konfiguriert oder später aktualisiert werden. So können Sie dies bei der Indexerstellung festlegen:

In diesem Beispiel erstellt Elasticsearch zwei Replikate für jeden primären Shard im Index my_index .

Um die number_of_replicas -Einstellung für einen bestehenden Index zu aktualisieren, können Sie die _settings -API verwenden:

Dieser Befehl aktualisiert den Index my_index , sodass für jeden primären Shard drei Replikate vorhanden sind.

Auswirkungen der Einstellung number_of_replicas

Die Einstellung number_of_replicas hat einen erheblichen Einfluss auf die Leistungsfähigkeit und Stabilität Ihres Elasticsearch- Clusters. Hier einige wichtige Punkte, die Sie beachten sollten:

1. Datenredundanz und Verfügbarkeit: Durch die Erhöhung von number_of_replicas wird die Verfügbarkeit Ihrer Daten verbessert, indem mehr Kopien jedes Shards erstellt werden. Wenn ein Knoten ausfällt, kann Elasticsearch weiterhin Daten von den Replikat-Shards auf den verbleibenden Knoten bereitstellen.

2. Suchleistung: Replikat-Shards können Leseanfragen bedienen, daher kann eine größere Anzahl von Replikaten die Suchleistung verbessern, indem die Last auf mehr Shards verteilt wird.

3. Schreibperformance: Allerdings muss jeder Schreibvorgang auf jeder Kopie eines Shards durchgeführt werden. Daher kann ein höherer Wert number_of_replicas die Indexierungsleistung verlangsamen, da er die Anzahl der Operationen erhöht, die für jeden Schreibvorgang durchgeführt werden müssen.

4. Speicherbedarf: Mehr Replikate bedeuten mehr Speicherplatz. Sie sollten sicherstellen, dass Ihr Cluster über genügend Kapazität verfügt, um die zusätzlichen Replikate zu speichern.

5. Ausfallsicherheit bei Knoten: Der number_of_replicas sollte unter Berücksichtigung der Anzahl der Knoten in Ihrem Cluster festgelegt werden. Wenn number_of_replicas gleich oder größer als die Anzahl der Knoten ist, kann Ihr Cluster den Ausfall mehrerer Knoten ohne Datenverlust tolerieren.

Bewährte Vorgehensweisen zum Festlegen der Anzahl der Replikate

Die optimale Einstellung number_of_replicas hängt von den spezifischen Anforderungen Ihres Systems ab. Hier sind jedoch einige allgemeine Best Practices:

• Bei einem Cluster mit nur einem Knoten sollte number_of_replicas auf 0 gesetzt werden, da keine weiteren Knoten vorhanden sind, die Replikate aufnehmen könnten.

• Bei einem Multi-Node-Cluster sollte number_of_replicas mindestens auf 1 gesetzt werden, um Datenredundanz und hohe Verfügbarkeit zu gewährleisten.

• Wenn die Suchleistung Priorität hat, sollten Sie die Anzahl der Einträge number_of_replicas erhöhen. Man sollte jedoch den Zielkonflikt zwischen Schreibleistung und Speicherbedarf berücksichtigen.

• Stellen Sie stets sicher, dass Ihr Cluster über ausreichend Kapazität zur Speicherung der zusätzlichen Replikate verfügt.

Methode 1: Verwendung der Update-API

Die Update-API ermöglicht es Ihnen, ein Dokument zu aktualisieren, indem Sie ein Skript bereitstellen, das die Quelle des Dokuments ändert. Mit dieser API können Sie ein Feld aus einem Dokument löschen, indem Sie das Feld auf Null setzen. Hier ist eine Schritt-für-Schritt-Anleitung dazu:

1. Ermitteln Sie den Index, den Dokumenttyp (falls Sie Elasticsearch 6.x oder eine ältere Version verwenden) und die Dokument-ID des Dokuments, das Sie aktualisieren möchten.

2. Verwenden Sie die Update-API mit einem Skript, das das Feld auf null setzt oder, noch besser, es aus dem Quelldokument entfernt. Das folgende Beispiel zeigt, wie das Feld „field_to_delete“ aus einem Dokument mit der ID „1“ im Index „my_index“ gelöscht wird:

3. Führe die Anfrage aus. Im Erfolgsfall gibt Elasticsearch eine Antwort zurück, die anzeigt, dass das Dokument aktualisiert wurde.

Hinweis: Diese Methode entfernt das Feld nur aus dem angegebenen Dokument. Das Feld wird weiterhin in der Zuordnung und in anderen Dokumenten im Index vorhanden sein.

Methode 2: Reindexierung mit einer modifizierten Quelle

Wenn Sie ein Feld aus allen Dokumenten in einem Index löschen möchten, können Sie die Reindex-API verwenden, um einen neuen Index mit der modifizierten Quelle zu erstellen. So machen Sie das:

1. Erstellen Sie einen neuen Index mit den gleichen Einstellungen und Zuordnungen wie der ursprüngliche Index. Mit der Get Index API können Sie die Einstellungen und Zuordnungen des ursprünglichen Index abrufen.

2. Verwenden Sie die Reindex-API, um Dokumente vom ursprünglichen Index in den neuen Index zu kopieren und dabei das Feld aus der Quelle zu entfernen. Das folgende Beispiel zeigt, wie das Feld „field_to_delete“ aus allen Dokumenten im Index „my_index“ gelöscht wird:

3. Überprüfen Sie, ob der neue Index die korrekten Dokumente enthält, nachdem das Feld entfernt wurde.

4. Wenn alles in Ordnung ist, können Sie den ursprünglichen Index löschen und gegebenenfalls einen Alias für den neuen Index hinzufügen, der den Namen des ursprünglichen Index trägt.

Methode 3: Aktualisierung des Mappings und der Neuindexierung

Wenn Sie ein Feld aus der Zuordnung und alle Dokumente in einem Index löschen möchten, können Sie die Zuordnung aktualisieren und anschließend die Dokumente neu indizieren. So geht's:

1. Erstellen Sie einen neuen Index mit den gleichen Einstellungen wie der ursprüngliche Index.

2. Rufen Sie die Zuordnungen des ursprünglichen Index mithilfe der Get Mapping API ab.

3. Ändern Sie die Zuordnungen, indem Sie das Feld entfernen, das Sie löschen möchten.

4. Wenden Sie die geänderten Zuordnungen mithilfe der Put Mapping API auf den neuen Index an.

5. Verwenden Sie die Reindex-API, um Dokumente vom ursprünglichen Index in den neuen Index zu kopieren, wie in Methode 2 beschrieben.

6. Überprüfen Sie, ob der neue Index die korrekten Dokumente enthält, wobei das Feld entfernt wurde, und ob das Feld in der Zuordnung nicht vorhanden ist.

7. Wenn alles gut aussieht, können Sie den ursprünglichen Index löschen und gegebenenfalls einen Alias mit dem Namen des ursprünglichen Index zum neuen Index hinzufügen.

Fazit

In diesem Artikel haben wir drei Methoden zum Löschen eines Feldes aus einem Dokument in Elasticsearch besprochen: die Verwendung der Update-API, die Neuindizierung mit einer geänderten Quelle und die Aktualisierung des Mappings mit anschließender Neuindizierung. Jede Methode hat ihre eigenen Anwendungsfälle und Vor- und Nachteile. Wählen Sie daher diejenige, die am besten zu Ihren Anforderungen passt. Denken Sie immer daran, Ihre Änderungen zu testen und die Ergebnisse zu überprüfen, bevor Sie sie in Produktionsumgebungen anwenden.

In der Vergangenheit haben viele Leute den Feldtyp nestedals Mechanismus verwendet, um verschiedene Indizes miteinander zu verbinden. Allerdings war dies aufgrund teurer Abfragen und unvollständiger Unterstützung in Kibana, insbesondere bei Lens-Visualisierungen, eingeschränkt.

Dieser Artikel befasst sich eingehend mit dem Zusammenführen zweier Indizes in Elasticsearch und konzentriert sich dabei auf die folgenden Ansätze:

1. Verwenden der terms -Abfrage

2. Verwenden des enrich -Prozessors in Aufnahmepipelines

3. Logstash elasticsearch Filter-Plugin

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

Verwenden der Begriffsabfrage

Die Termabfrage ist eine der effektivsten Möglichkeiten, zwei Indizes in Elasticsearch zu verbinden. Mit dieser Abfrage können Sie Dokumente abrufen, die einen oder mehrere genaue Begriffe in einem bestimmten Feld enthalten. Hier besprechen wir, wie man es zum Verbinden zweier Indizes verwendet.

Zuerst müssen Sie die erforderlichen Daten aus dem ersten Index abrufen. Dies kann mithilfe einer einfachen GET-Anfrage und dem Abrufen der Werte aus dem Attribut _source erfolgen.

Sobald Sie die Daten aus dem ersten Index haben, können Sie diese zum Abfragen des zweiten Index verwenden. Dies geschieht mithilfe der terms -Abfrage, bei der Sie das Feld und die Werte angeben, die Sie abgleichen möchten.

Hier ist ein Beispiel:

In diesem Beispiel ist field_in_second_index das Feld im zweiten Index, das Sie mit den Werten aus dem ersten Index abgleichen möchten. value1_from_first_index und value2_from_first_index sind die Werte aus dem ersten Index, die im zweiten Index abgeglichen werden sollen.

Die Begriffsabfrage bietet außerdem Unterstützung bei der Ausführung der beiden oben genannten Schritte in einem Durchgang mithilfe einer Technik namens „Begriffssuche“. Elasticsearch kümmert sich um das transparente Abrufen der abzugleichenden Werte aus einem anderen Index. Wenn Sie beispielsweise einen Teamindex mit einer Spielerliste haben:

Es ist möglich, einen Personenindex für alle Personen abzufragen, die in Team1 spielen, wie unten gezeigt:

Im obigen Beispiel ruft Elasticsearch die Spielernamen transparent aus dem Dokument mit der ID team1 im Teamindex ab (d. h. „John“, „Bill“ und „Michael“) und suchen Sie alle Dokumente im Personenindex, die einen dieser Werte in ihrem Namensfeld enthalten.

Für alle, die es interessiert: Die entsprechende SQL-Abfrage wäre:

Verwenden des Anreicherungsprozessors

Der enrich -Prozessor ist ein weiteres leistungsstarkes Tool, mit dem zwei Indizes in Elasticsearch verbunden werden können. Dieser Prozessor bereichert die Daten eingehender Dokumente, indem er Daten aus einem vordefinierten Anreicherungsindex hinzufügt.

So können Sie den Anreicherungsprozessor verwenden, um zwei Indizes zu verknüpfen:

1. Zuerst müssen Sie eine Anreicherungsrichtlinie erstellen. Diese Richtlinie definiert, welcher Index für die Anreicherung verwendet werden soll, welches Feld abgeglichen werden soll und welche Felder für die Anreicherung eingehender Dokumente verwendet werden sollen.

Hier ist ein Beispiel:

2. Sobald die Richtlinie erstellt ist, müssen Sie sie ausführen, um den angereicherten Index aus Ihrer neu erstellten Richtlinie zu erstellen:

Dadurch wird ein neuer versteckter angereicherter Index erstellt, der während der Anreicherung verwendet wird. Abhängig von der Größe des Quellindex kann dieser Vorgang einige Zeit dauern. Stellen Sie sicher, dass die Anreicherungsrichtlinie vollständig erstellt ist, bevor Sie mit dem nächsten Schritt fortfahren.

3. Nachdem die Anreicherungsrichtlinie erstellt wurde, können Sie den Anreicherungsprozessor in einer Aufnahmepipeline verwenden, um die Daten eingehender Dokumente anzureichern:

In diesem Beispiel ist field_in_second_index das Feld im zweiten Index, das mit match_field aus dem ersten Index übereinstimmen muss. enriched_field ist das neue Feld im zweiten Index, das die angereicherten Daten aus enrich_fields im ersten Index enthalten wird.

Ein Nachteil dieses Ansatzes besteht darin, dass die Anreicherungsrichtlinie erneut ausgeführt werden muss, wenn sich die Daten in first_index ändern. Der angereicherte Index wird nicht automatisch mit dem Quellindex aktualisiert oder synchronisiert, aus dem er erstellt wurde. Wenn first_index jedoch relativ stabil ist, funktioniert dieser Ansatz gut.

Logstash Elasticsearch-Filter-Plugin

Wenn Sie Logstash verwenden, besteht eine weitere Option, die dem oben beschriebenen enrich -Prozessor ähnelt, darin, das elasticsearch -Filter-Plugin zu verwenden, um dem Ereignis basierend auf einer angegebenen Abfrage relevante Felder hinzuzufügen. Die Konfiguration für unsere Logstash-Pipeline würde sich in einer .conf -Datei befinden, beispielsweise my-pipeline.conf.

Stellen wir uns vor, unsere Pipeline zieht Protokolle aus Elasticsearch mithilfe des elasticsearch -Eingabe-Plugins und verwendet eine Abfrage, um die Auswahl einzugrenzen:

Wenn wir diese Nachrichten mit Informationen aus einem bestimmten Index anreichern möchten, können wir das Filter-Plugin elasticsearchim Abschnitt filter verwenden, um unsere Protokolle anzureichern:

Der obige Code findet die Dokumente ab Index index_name , wobei type der Start ist und das Operationsfeld mit dem angegebenen opid übereinstimmt, und kopiert dann den Wert des Felds @timestamp in ein neues Feld mit dem Namen started.

Die angereicherten Dokumente würden dann an die entsprechende Ausgabequelle gesendet, in diesem Fall an Elasticsearch unter Verwendung des elasticsearch -Ausgabe-Plugins:

Wenn Sie Logstash bereits verwenden, kann diese Option nützlich sein, um Ihre Anreicherungslogik an einem einzigen Ort zu konsolidieren und bei eingehenden neuen Ereignissen zu verarbeiten. Wenn dies jedoch nicht der Fall ist, wird Ihre Lösung komplexer und Sie müssen eine weitere Komponente ausführen und warten.

ES|QL ENRICH

Die Einführung von ES|QL, das in Version 8.14 allgemein verfügbar wurde, ist eine von Elasticsearch unterstützte Piped-Abfragesprache, die das Filtern, Transformieren und Analysieren von Daten ermöglicht. Mithilfe des Verarbeitungsbefehls ENRICH können wir mithilfe einer Anreicherungsrichtlinie Daten aus vorhandenen Indizes hinzufügen.

Wenn man dieselbe Richtlinie my_enrich_policy aus dem ursprünglichen Beispiel des Anreicherungsprozessors verwendet, würde das ES|QL-Beispiel folgendermaßen aussehen:

Es ist auch möglich, die Übereinstimmungs- und Anreicherungsfelder zu überschreiben, die in unserem Beispiel field_in_first_index bzw. field_to_enrich sind:

Die offensichtliche Einschränkung besteht darin, dass Sie zuerst eine Anreicherungsrichtlinie angeben müssen, ES|QL bietet jedoch die Flexibilität, die Felder nach Bedarf anzupassen.

ES|QL LOOKUP JOIN

Elasticsearch 8.18 führt eine neue Möglichkeit zum Verbinden von Indizes in Elasticsearch ein, nämlich den Befehl LOOKUP JOIN . Dieser Befehl funktioniert als LEFT OUTER JOIN im SQL-Stil und verwendet den neuen Lookup-Indexmodus auf der rechten Seite des Joins.

Wenn wir unser vorheriges Beispiel noch einmal betrachten, lautet die neue Abfrage wie folgt, wobei match_field sowohl in first_index als auch in second_index vorhanden sein muss:

Der Vorteil von LOOKUP JOIN gegenüber den anderen Ansätzen besteht darin, dass keine enrich -Richtlinie erforderlich ist und daher auch keine zusätzliche Verarbeitung im Zusammenhang mit der Einrichtung der Richtlinie erforderlich ist. Im Gegensatz zu den anderen in diesem Artikel besprochenen Ansätzen ist es nützlich, wenn mit sich häufig ändernden Anreicherungsdaten gearbeitet wird.

Fazit

Zusammenfassend lässt sich sagen, dass Elasticsearch zwar keine herkömmlichen Join-Operationen unterstützt, aber verschiedene Funktionen bietet, mit denen ähnliche Ergebnisse erzielt werden können. Insbesondere haben wir erläutert, wie Sie Join-Operationen mithilfe der folgenden Methoden durchführen können:

1. Die terms -Abfrage

2. Der enrich -Prozessor in Ingest-Pipelines

3. Logstash elasticsearch Filter-Plugin

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

Es ist wichtig zu beachten, dass diese Methoden ihre Grenzen haben und je nach den spezifischen Anforderungen und der Art der Daten mit Bedacht eingesetzt werden sollten.

Bewertungsmechanismen in Elasticsearch

Elasticsearch verwendet standardmäßig ein Bewertungsmodell namens Practical Scoring Function (BM25). Dieses Modell basiert auf der probabilistischen Information-Retrieval-Theorie und berücksichtigt Faktoren wie Termfrequenz, inverse Dokumentfrequenz und Feldlängennormalisierung. Lassen Sie uns diese Faktoren kurz besprechen:

1. Termfrequenz (TF): Dies gibt an, wie oft ein Begriff in einem Dokument vorkommt. Eine höhere Termfrequenz deutet auf eine stärkere Beziehung zwischen dem Begriff und dem Dokument hin.

2. Inverse Dokumenthäufigkeit (IDF): Dieser Faktor misst die Bedeutung eines Begriffs innerhalb der gesamten Dokumentensammlung. Ein Begriff, der in vielen Dokumenten vorkommt, gilt als weniger wichtig, während ein Begriff, der in weniger Dokumenten vorkommt, als wichtiger gilt.

3. Feldlängennormalisierung: Dieser Faktor berücksichtigt die Länge des Feldes, in dem der Term vorkommt. Kürzere Felder werden stärker gewichtet, da der Begriff in einem kürzeren Feld als bedeutsamer angesehen wird.

Verwendung der Explain-API

Die Explain API in Elasticsearch ist ein wertvolles Werkzeug zum Verständnis des Scoring-Prozesses. Es bietet eine detaillierte Erklärung, wie die Punktzahl für ein bestimmtes Dokument berechnet wurde. Um die Explain-API zu verwenden, müssen Sie eine GET-Anfrage an den folgenden Endpunkt senden:

Im Anfragetext müssen Sie die Abfrage angeben, für die Sie die Bewertung verstehen möchten. Hier ein Beispiel:

Die Antwort der Explain API enthält eine detaillierte Aufschlüsselung des Bewertungsprozesses, einschließlich der einzelnen Faktoren (TF, IDF und Feldlängennormalisierung) und deren Beitrag zur Endwertung. Hier ist eine Beispielantwort:

In diesem Beispiel zeigt die Antwort, dass der Wert von 1,2 das Produkt aus dem IDF-Wert (2,2) und dem tfNorm-Wert (0,5) ist. Die detaillierte Erklärung hilft, die Faktoren zu verstehen, die zur Bewertung beitragen, und kann für die Feinabstimmung der Suchrelevanz nützlich sein.

Fazit

Die Bewertung durch Elasticsearch ist ein entscheidender Aspekt bei der Bereitstellung relevanter Suchergebnisse. Indem Sie die Bewertungsmechanismen verstehen und die Explain API nutzen, können Sie Einblicke in die Faktoren gewinnen, die die Suchergebnisse beeinflussen, und Ihre Suchanfragen im Hinblick auf bessere Relevanz und Leistung optimieren.

Erweiterte Techniken zur Durchführung von Suchen in zwei Feldern

1. Mehrfachabfrage

Eine Mehrfachabfrage ermöglicht es Ihnen, in mehreren Feldern nach einer einzelnen Suchzeichenfolge zu suchen. Dies ist nützlich, wenn Sie Dokumente finden möchten, die die angegebene Suchanfrage in einem der beiden Felder enthalten. Hier ist ein Beispiel für eine Mehrfachabfrage, die nach dem Begriff „Beispiel“ in den Feldern „Titel“ oder „Beschreibung“ sucht:

2. Bool-Abfrage

Eine Bool-Abfrage ermöglicht es Ihnen, mehrere Abfragen mithilfe boolescher Logik zu kombinieren. Sie können die „should“-Klausel verwenden, um nach Dokumenten zu suchen, die der Suchanfrage in einem der beiden Felder entsprechen. Hier ist ein Beispiel für eine Boolesche Abfrage, die nach dem Begriff „Beispiel“ in den Feldern „Titel“ und „Beschreibung“ sucht:

3. Feld-Boosting zur Abfragezeit

Manchmal möchten Sie bei der Suche einem Feld mehr Gewicht beimessen als einem anderen. Dies lässt sich erreichen, indem man dem Feld zur Abfragezeit einen Boost-Faktor zuweist. Ein höherer Boost-Wert gewichtet das Feld stärker, wodurch es mit größerer Wahrscheinlichkeit das endgültige Suchergebnis beeinflusst. Hier ist ein Beispiel für eine Mehrfachabfrage mit einem Boost-Faktor für das Feld „Titel“:

In diesem Beispiel hat das Feld „Titel“ einen Boost-Faktor von 3, wodurch es bei der Bestimmung des Such-Scores dreimal wichtiger ist als das Feld „Beschreibung“.

4. Kombinieren von Abfragen mit unterschiedlichen Gewichtungsfaktoren

Sie können auch mehrere Abfragen mit unterschiedlichen Gewichtungsfaktoren mithilfe einer booleschen Abfrage kombinieren. Dies ermöglicht es Ihnen, die Wichtigkeit jedes Feldes in den Suchergebnissen feinabzustimmen. Hier ist ein Beispiel für eine Boolesche Abfrage mit unterschiedlichen Gewichtungsfaktoren für die Felder „Titel“ und „Beschreibung“:

In diesem Beispiel hat das Feld „Titel“ einen Boost-Faktor von 3, während das Feld „Beschreibung“ einen Boost-Faktor von 1 hat.

Fazit

Die Suche anhand zweier Felder in Elasticsearch kann mithilfe fortgeschrittener Techniken wie Multi-Match-Abfragen, Booleschen Abfragen und Query-Time Field Boosting erreicht werden. Durch die Kombination dieser Techniken können Sie genauere und relevantere Suchergebnisse für Ihre Nutzer erstellen. Experimentieren Sie mit verschiedenen Abfragekombinationen und Gewichtungsfaktoren, um die optimale Suchkonfiguration für Ihren spezifischen Anwendungsfall zu finden.

Alle vollständigen Abfragen und Ausgaben, die in diesem Artikel erwähnt werden, finden Sie in unserem Elasticsearch Labs-Code-Repository.

Warum sollten Sie Better Binary Quantization (BBQ) in Ihrem Anwendungsfall einsetzen?

Die mathematischen Hintergründe sind zwar faszinierend, aber unerlässlich, wenn Sie vollständig verstehen wollen, warum Ihre Vektorsuchen präzise bleiben. Letztendlich dreht sich alles um Komprimierung, da sich herausgestellt hat, dass man mit den aktuellen Vektorsuchalgorithmen durch die Lesegeschwindigkeit der Daten begrenzt ist. Wenn Sie also all diese Daten im Arbeitsspeicher unterbringen können, erzielen Sie im Vergleich zum Lesen vom Speicher eine erhebliche Geschwindigkeitssteigerung (der Arbeitsspeicher ist etwa 200-mal schneller als SSDs).

Es gibt ein paar Dinge zu beachten:

• Graphenbasierte Indizes wie HNSW (Hierarchical Navigable Small World) sind für die Vektorabfrage am schnellsten.

  • HNSW: Ein ungefährer Suchalgorithmus für den nächsten Nachbarn, der eine mehrschichtige Graphstruktur erstellt, um effiziente hochdimensionale Ähnlichkeitssuchen zu ermöglichen.

• Die Geschwindigkeit von HNSW wird grundsätzlich durch die Datenlesegeschwindigkeit aus dem Speicher oder im schlimmsten Fall aus dem Speicher begrenzt.

  • Idealerweise möchten Sie alle Ihre gespeicherten Vektoren in den Speicher laden können.

• Einbettungsmodelle erzeugen im Allgemeinen Vektoren mit Float32-Präzision, 4 Bytes pro Gleitkommazahl.

• Und schließlich kann es, je nachdem, wie viele Vektoren und/oder Dimensionen Sie haben, sehr schnell passieren, dass Ihnen nicht genügend Speicher zur Verfügung steht, um alle Ihre Vektoren zu speichern.

Wenn man dies als gegeben voraussetzt, erkennt man, dass schnell ein Problem entsteht, wenn man Millionen oder sogar Milliarden von Vektoren mit jeweils potenziell Hunderten oder sogar Tausenden von Dimensionen verarbeitet. Der Abschnitt „ Ungefähre Zahlen zu den Kompressionsverhältnissen“ enthält einige grobe Zahlen.

Was brauchen Sie für den Anfang?

Für den Anfang benötigen Sie Folgendes:

• Wenn Sie Elastic Cloud oder vor Ort verwenden, benötigen Sie eine höhere Version von Elasticsearch als 8.18. Während BBQ in 8.16 eingeführt wurde, verwenden Sie in diesem Artikel vector_rescore, das in 8.18 eingeführt wurde.

• Darüber hinaus müssen Sie sicherstellen, dass in Ihrem Cluster ein Knoten für maschinelles Lernen (ML) vorhanden ist. (Hinweis: Zum Laden des Modells ist ein ML-Knoten mit mindestens 4 GB erforderlich, für die vollständige Produktionsarbeitslast werden Sie jedoch wahrscheinlich viel größere Knoten benötigen.)

• Wenn Sie Serverless verwenden, müssen Sie eine Instanz auswählen, die für Vektoren optimiert ist.

• Darüber hinaus benötigen Sie Grundkenntnisse im Umgang mit Vektordatenbanken. Wenn Sie mit den Konzepten der Vektorsuche in Elastic noch nicht vertraut sind, sollten Sie sich zunächst die folgenden Ressourcen ansehen:

  • Navigieren in einer Elastic Vector-Datenbank

  • Die großen Ideen hinter der Retrieval Augmented Generation

Verbesserte Binärquantisierung (BBQ)-Implementierung

Um diesen Blog einfach zu halten, verwenden Sie integrierte Funktionen, wenn diese verfügbar sind. In diesem Fall verfügen Sie über das Vektor-Einbettungsmodell .multilingual-e5-small , das direkt in Elasticsearch auf einem Machine-Learning-Knoten ausgeführt wird. Beachten Sie, dass Sie das Modell text_embedding durch den Embedder Ihrer Wahl ersetzen können (OpenAI, Google AI Studio, Cohere und viele mehr). Wenn Ihr bevorzugtes Modell noch nicht integriert ist, können Sie auch Ihre eigenen dichten Vektoreinbettungen mitbringen.)

Zuerst müssen Sie einen Inferenzendpunkt erstellen, um Vektoren für einen bestimmten Textabschnitt zu generieren. Sie führen alle diese Befehle von der Kibana Dev Tools-Konsole aus. Dieser Befehl lädt .multilingual-e5-small herunter. Wenn es noch nicht vorhanden ist, wird Ihr Endpunkt eingerichtet. Dies kann eine Minute dauern. Sie können die erwartete Ausgabe in der Datei 01-create-an-inference-endpoint-output.json im Ordner „Outputs“ sehen.

Sobald dies zurückgegeben wurde, ist Ihr Modell eingerichtet und Sie können mit dem folgenden Befehl testen, ob das Modell wie erwartet funktioniert. Sie können die erwartete Ausgabe in der Datei 02-embed-text-output.json im Ordner „Outputs“ sehen.

Wenn bei Ihnen Probleme auftreten, weil Ihr trainiertes Modell keinem Knoten zugewiesen wird, müssen Sie Ihr Modell möglicherweise manuell starten.

Erstellen wir nun eine neue Zuordnung mit 2 Eigenschaften, einem Standardtextfeld (my_field) und einem dichten Vektorfeld (my_vector) mit 384 Dimensionen, um der Ausgabe des Einbettungsmodells zu entsprechen. Sie werden auch index_options.type to bbq_hnsw überschreiben. Sie können die erwartete Ausgabe in der Datei 03-create-byte-qauntized-index-output.json im Ordner „Outputs“ sehen.

Um sicherzustellen, dass Elasticsearch Ihre Vektoren generiert, können Sie eine Ingest-Pipeline verwenden. Diese Pipeline erfordert drei Dinge: den Endpunkt (model_id), die input_field , für die Sie Vektoren erstellen möchten, und die output_field , in der diese Vektoren gespeichert werden. Der erste Befehl unten erstellt eine Inferenz-Ingest-Pipeline, die den Inferenzdienst im Hintergrund verwendet, und der zweite testet, ob die Pipeline ordnungsgemäß funktioniert. Sie können die erwartete Ausgabe in der Datei 04-create-and-simulate-ingest-pipeline-output.json im Ordner „Outputs“ sehen. 

Sie können nun mit den ersten beiden Befehlen unten einige Dokumente hinzufügen und mit dem dritten Befehl testen, ob Ihre Suchvorgänge funktionieren. Sie können die erwartete Ausgabe in der Datei 05-bbq-index-output.json im Ordner „Outputs“ überprüfen. 

Wie in diesem Beitrag empfohlen, sind Neubewertung und Überabtastung ratsam, wenn Sie auf nicht triviale Datenmengen skalieren, da sie dazu beitragen, eine hohe Rückrufgenauigkeit aufrechtzuerhalten und gleichzeitig von den Komprimierungsvorteilen zu profitieren. Ab Elasticsearch Version 8.18 können Sie dies auf diese Weise mit rescore_vector tun. Die erwartete Ausgabe befindet sich in der Datei 06-bbq-search-8-18-output.json im Ordner „Outputs“.

Wie schneiden diese Werte im Vergleich zu denen ab, die Sie für Rohdaten erhalten würden? Wenn Sie alles oben Gesagte noch einmal machen, aber mit index_options.type: hnsw, werden Sie sehen, dass die Ergebnisse sehr vergleichbar sind. Sie können die erwartete Ausgabe in der Datei 07-raw-vector-output.json im Ordner „Outputs“ sehen.

Ungefähre Zahlen zu den Kompressionsverhältnissen

Bei der Arbeit mit der Vektorsuche können Speicher- und Arbeitsspeicheranforderungen schnell zu einer erheblichen Herausforderung werden. Die folgende Aufschlüsselung veranschaulicht, wie verschiedene Quantisierungstechniken den Speicherbedarf von Vektordaten drastisch reduzieren.

Vektoren (V)

Abmessungen (D)

roh (V x D x 4)

int8 (V x (D x 1 + 4))

int4 (V x (D x 0,5 + 4))

Grill (V x (D x 0,125 + 4))

10.000.000

384

14,31 GB

3,61 GB

1,83 GB

0,58 GB

50.000.000

384

71,53 GB

18,07 GB

9,13 GB

2,89 GB

100.000.000

384

143,05 GB

36,14 GB

18,25 GB

5,77 GB

Fazit

BBQ ist eine Optimierung, die Sie zur Komprimierung Ihrer Vektordaten anwenden können, ohne die Genauigkeit zu beeinträchtigen. Dabei werden Vektoren in Bits umgewandelt, sodass Sie die Daten effektiv durchsuchen und Ihre KI-Workflows skalieren können, um die Suche zu beschleunigen und die Datenspeicherung zu optimieren.

Weiterführendes Lernen

Wenn Sie mehr über BBQ erfahren möchten, sehen Sie sich unbedingt die folgenden Ressourcen an:

• Binäre Quantisierung (BBQ) in Lucene und Elasticsearch

• Bessere binäre Quantisierung (BBQ) vs. Produktquantisierung

• Optimierte skalare Quantisierung: Noch bessere binäre Quantisierung

• Bessere binäre Quantisierung (BBQ): Von Bytes bis BBQ, das Geheimnis einer besseren Vektorsuche von Ben Trent

Ab Version 7.11 passt Elasticsearch die JVM-Heap-Größe standardmäßig automatisch an die Rollen und den Gesamtspeicher eines Knotens an. Für die meisten Produktionsumgebungen wird die Verwendung der Standarddimensionierung empfohlen. Wenn Sie jedoch die Größe Ihres JVM-Heaps manuell festlegen möchten, sollten Sie in der Regel -Xms und -Xmx auf den gleichen Wert setzen, der 50 % Ihres gesamten verfügbaren RAMs betragen sollte, maximal jedoch (ungefähr) 31 GB.

Eine größere Heap-Größe stellt Ihrem Knoten mehr Speicher für Indizierungs- und Suchvorgänge zur Verfügung. Allerdings benötigt Ihr Knoten auch Speicher für das Caching, daher sorgt die Verwendung von 50 % für ein gesundes Gleichgewicht zwischen den beiden. Aus demselben Grund sollten Sie im Produktivbetrieb vermeiden, andere speicherintensive Prozesse auf demselben Knoten wie Elasticsearch auszuführen.

Typischerweise folgt die Haufennutzung einem Sägezahnmuster und schwankt zwischen etwa 30 und 70 % der maximal genutzten Haufengröße. Dies liegt daran, dass die JVM den Heap-Nutzungsprozentsatz stetig erhöht, bis der Garbage-Collection-Prozess wieder Speicher freigibt. Eine hohe Heap-Speicherbelegung tritt auf, wenn der Garbage-Collection-Prozess nicht hinterherkommt. Ein Indikator für eine hohe Heap-Speicherbelegung ist, wenn die Garbage Collection nicht in der Lage ist, die Heap-Speicherbelegung auf etwa 30 % zu reduzieren.

Im obigen Bild ist ein normales Sägezahnmuster des JVM-Heaps zu sehen.

Sie werden auch feststellen, dass es zwei Arten von Müllabfuhr gibt, die junge und die alte Müllabfuhr.

In einer gesunden JVM sollte die Speicherbereinigung idealerweise die folgenden Bedingungen erfüllen:

• Young GC wird schnell verarbeitet (innerhalb von 50 ms).

• Young GC wird nicht häufig ausgeführt (etwa alle 10 Sekunden).

• Der alte GC wird schnell verarbeitet (innerhalb von 1 Sekunde).

• Die alte Garbage Collection wird nicht häufig ausgeführt (einmal alle 10 Minuten oder seltener).

Wie lässt sich das Problem beheben, wenn die Heap-Speichernutzung zu hoch ist oder die JVM-Leistung nicht optimal ist?

Es kann verschiedene Gründe geben, warum die Heap-Speicherbelegung ansteigen kann:

Übersharding

Das Dokument zum Thema Oversharding finden Sie hier.

Große Aggregationsgrößen

Um große Aggregationsgrößen zu vermeiden, halten Sie die Anzahl der Aggregations-Buckets (Größe) in Ihren Abfragen so gering wie möglich.

Sie können die Protokollierung langsamer Abfragen (Slow Logs) verwenden und sie auf einem bestimmten Index mit den folgenden Mitteln implementieren.

Anfragen, deren Beantwortung lange dauert, sind wahrscheinlich ressourcenintensiv.

Übermäßige Größe des Massenindex

Wenn Sie große Anfragen senden, kann dies zu einem hohen Heap-Verbrauch führen. Versuchen Sie, die Größe der Massenindexierungsanfragen zu reduzieren.

Kartierungsprobleme

Insbesondere wenn Sie „fielddata: true“ verwenden, kann dies einen erheblichen Teil Ihres JVM-Heaps beanspruchen.

Die Haufengröße wurde falsch eingestellt.

Die Heap-Größe kann manuell definiert werden durch:

Festlegen der Umgebungsvariablen:

Bearbeiten der Datei jvm.options in Ihrem Elasticsearch-Konfigurationsverzeichnis:

Die Einstellung der Umgebungsvariablen hat Vorrang vor der Dateieinstellung.

Der Knoten muss neu gestartet werden, damit die Einstellung übernommen wird.

Das neue JVM-Verhältnis wurde falsch eingestellt

Im Allgemeinen ist es NICHT notwendig, dies festzulegen, da Elasticsearch diesen Wert standardmäßig setzt. Dieser Parameter definiert das Verhältnis des verfügbaren Speicherplatzes für Objekte der „neuen Generation“ und der „alten Generation“ in der JVM.

Wenn Sie feststellen, dass old GC sehr häufig vorkommt, können Sie versuchen, diesen Wert in der Datei jvm.options in Ihrem Elasticsearch-Konfigurationsverzeichnis explizit festzulegen.

Was sind die besten Vorgehensweisen für die Verwaltung der Heap-Speicherbelegung und der JVM-Garbage-Collection in einem großen Elasticsearch-Cluster?

Die besten Vorgehensweisen für die Verwaltung der Heap-Speicherbelegung und der JVM-Garbage-Collection in einem großen Elasticsearch-Cluster bestehen darin, sicherzustellen, dass die Heap-Größe auf maximal 50 % des verfügbaren RAMs eingestellt ist und dass die JVM-Garbage-Collection-Einstellungen für den jeweiligen Anwendungsfall optimiert sind. Es ist wichtig, die Heap-Größe und die Garbage-Collection-Metriken zu überwachen, um sicherzustellen, dass der Cluster optimal läuft. Insbesondere ist es wichtig, die JVM-Heap-Größe, die Garbage-Collection-Zeit und die Garbage-Collection-Pausen zu überwachen. Darüber hinaus ist es wichtig, die Anzahl der Müllabfuhrzyklen und die für die Müllabfuhr aufgewendete Zeit zu überwachen. Durch die Überwachung dieser Kennzahlen können potenzielle Probleme mit der Heap-Größe oder den Einstellungen für die Speicherbereinigung erkannt und gegebenenfalls Korrekturmaßnahmen ergriffen werden.

Die _split-API ist oft eine schnellere Methode als die _reindex-API. Die Indizierung muss vor beiden Operationen gestoppt werden , da sich sonst die Dokumentanzahlen in source_index und target_index unterscheiden.

Methode 1 – Verwendung der Split-API

Die Split-API wird verwendet, um einen neuen Index mit der gewünschten Anzahl primärer Shards zu erstellen, indem die Einstellungen kopiert und ein vorhandener Index zugeordnet werden. Die gewünschte Anzahl primärer Shards kann bei der Erstellung festgelegt werden. Vor der Implementierung der Split-API sollten folgende Einstellungen überprüft werden:

1. Der Quellindex muss schreibgeschützt sein. Dies bedeutet, dass der Indexierungsprozess gestoppt werden muss.

2. Die Anzahl der primären Shards im Zielindex muss ein Vielfaches der Anzahl der primären Shards im Quellindex sein. Wenn der Quellindex beispielsweise 5 primäre Shards hat, können die primären Shards des Zielindex auf 10, 15, 20 usw. festgelegt werden.

Hinweis: Wenn nur die Nummer des primären Shards geändert werden muss, ist die Split-API vorzuziehen, da sie wesentlich schneller ist als die Reindex-API.

Implementierung der Split-API

Erstellen Sie einen Testindex:

Der Quellindex muss schreibgeschützt sein, um aufgeteilt werden zu können:

Einstellungen und Zuordnungen werden automatisch aus dem Quellindex kopiert:

Den Fortschritt können Sie mit folgendem Link überprüfen:

Da Einstellungen und Zuordnungen aus den Quellindizes kopiert werden, ist der Zielindex schreibgeschützt. Aktivieren wir nun den Schreibvorgang für den Zielindex:

Prüfen Sie die Anzahl der Dokumente (docs.count) im Quell- und Zielindex, bevor Sie den ursprünglichen Index löschen:

Indexname und Aliasname dürfen nicht identisch sein. Sie müssen den Quellindex löschen und den Namen des Quellindex als Alias zum Zielindex hinzufügen:

Nachdem Sie den Alias test_split_source zum Index test_split_target hinzugefügt haben, sollten Sie ihn wie folgt testen:

Methode 2 – Verwendung der Reindex-API

Durch die Erstellung eines neuen Index mit der Reindex-API kann eine beliebige Anzahl primärer Shards angegeben werden. Nach der Erstellung eines neuen Index mit der gewünschten Anzahl primärer Shards können alle Daten im Quellindex in diesen neuen Index neu indiziert werden.

Zusätzlich zu den Split-API-Funktionen können die Daten mithilfe der ingest_pipeline im Reindex-AP manipuliert werden. Bei der Ingest-Pipeline werden nur die angegebenen Felder, die dem Filter entsprechen, mithilfe der Abfrage in den Zielindex indiziert. Der Dateninhalt kann mithilfe eines einfachen Skripts geändert werden, und mehrere Indizes können zu einem einzigen Index zusammengeführt werden.

Implementierung der Reindex-API

Erstellen Sie einen Test-Reindex:

Kopieren Sie die Einstellungen und Zuordnungen aus dem Quellindex:

Erstellen Sie einen Zielindex mit Einstellungen, Zuordnungen und der gewünschten Shard-Anzahl:

*Hinweis: Die Einstellung number_of_replicas: 0 und refresh_interval: -1 erhöht die Geschwindigkeit der Neuindizierung.

Starten Sie den Reindexierungsprozess. Durch die Einstellung requests_per_second=-1 und slices=auto wird die Reindexierungsgeschwindigkeit angepasst.

Die task_id wird Ihnen beim Ausführen der Reindex-API angezeigt. Kopiere das und überprüfe es mit der _tasks-API:

Aktualisieren Sie die Einstellungen, nachdem die Neuindizierung abgeschlossen ist:

Prüfen Sie vor dem Löschen des ursprünglichen Index die Anzahl der Dokumente (docs.count) im Quell- und Zielindex; sie sollte identisch sein.

Der Indexname und der Aliasname dürfen nicht identisch sein. Löschen Sie den Quellindex und fügen Sie den Namen des Quellindex als Alias zum Zielindex hinzu:

Nachdem Sie den Alias test_split_source zum Index test_split_target hinzugefügt haben, testen Sie ihn mit folgendem Befehl:

Zusammenfassung

Wenn Sie die Anzahl der primären Shards eines bestehenden Index erhöhen möchten, müssen Sie die Einstellungen und Zuordnungen für einen neuen Index neu erstellen. Hierfür gibt es zwei Hauptmethoden: die Reindex-API und die Split-API. Die aktive Indizierung muss vor Anwendung beider Methoden beendet werden.

Die Nachteile dieses Ansatzes bestehen darin, dass er eine gewisse Duplizierung der Hardware erfordert und bei dem Versuch, alle Daten reibungslos zu übertragen und zu synchronisieren, zu Schwierigkeiten führen kann.

Ein ähnliches Verfahren kann auch erforderlich sein, wenn Sie Anwendungen von einem Rechenzentrum in ein anderes migrieren müssen.

In diesem Artikel besprechen und beschreiben wir drei Möglichkeiten zur Datenübertragung zwischen Elasticsearch-Clustern.

Wie migriere ich Daten zwischen Elasticsearch-Clustern?

Es gibt drei Möglichkeiten, Daten zwischen Elasticsearch-Clustern zu übertragen:

1. Neuindizierung von einem Remote-Cluster

2. Übertragen von Daten mithilfe von Snapshots

3. Datenübertragung mit Logstash

Die Verwendung von Snapshots ist normalerweise die schnellste und zuverlässigste Methode zur Datenübertragung. Bedenken Sie jedoch, dass Sie einen Snapshot nur auf einem Cluster mit gleicher oder höherer Version wiederherstellen können und niemals mit einem Unterschied von mehr als einer Hauptversion. Das bedeutet, dass Sie einen 6.x-Snapshot auf einem 7.x-Cluster wiederherstellen können, aber nicht auf einem 8.x-Cluster.

Wenn Sie um mehr als eine Hauptversion erhöhen müssen, müssen Sie neu indizieren oder Logstash verwenden.

Sehen wir uns nun jede der drei Optionen zum Übertragen von Daten zwischen Elasticsearch-Clustern im Detail an.

1. Neuindizierung von Daten aus einem Remote-Cluster

Bevor Sie mit der Neuindizierung beginnen, denken Sie daran, dass Sie für alle Indizes im neuen Cluster entsprechende Zuordnungen einrichten müssen. Dazu müssen Sie die Indizes entweder direkt mit den entsprechenden Zuordnungen erstellen oder Indexvorlagen verwenden.

Neuindizierung von Remote – Konfiguration erforderlich

Um eine Neuindizierung aus der Ferne durchzuführen, sollten Sie die folgende Konfiguration zur Datei elasticseearch.yml für den Cluster hinzufügen, der die Daten empfängt. In Linux-Systemen befindet sich diese Datei normalerweise hier: /etc/elasticsearch/elasticsearch.yml. Die hinzuzufügende Konfiguration lautet wie folgt:

Wenn Sie SSL verwenden, sollten Sie jedem Knoten das CA-Zertifikat hinzufügen und Folgendes in den Befehl für jeden Knoten in elasticsearch.yml aufnehmen:

Alternativ können Sie allen Elasticsearch-Knoten die folgende Zeile hinzufügen, um die SSL-Verifizierung zu deaktivieren. Dieser Ansatz ist jedoch weniger empfehlenswert, da er nicht so sicher ist wie die vorherige Option:

Sie müssen diese Änderungen auf jedem Knoten vornehmen und einen rollierenden Neustart durchführen. Weitere Informationen hierzu finden Sie in unserem Handbuch.

Befehl zur Neuindizierung

Nachdem Sie den Remote-Host in der Datei elasticsearch.yml definiert und ggf. die SSL-Zertifikate hinzugefügt haben, können Sie mit dem folgenden Befehl mit der Neuindizierung der Daten beginnen:

Dabei können Timeout-Fehler auftreten. Daher kann es sinnvoll sein, großzügige Werte für Timeouts festzulegen, anstatt sich auf Standardwerte zu verlassen.

Sehen wir uns nun einige andere häufige Fehler an, die bei der Neuindizierung aus der Ferne auftreten können.

Häufige Fehler bei der Neuindizierung von Remote

1. Neuindizierung nicht auf der Whitelist

Wenn dieser Fehler auftritt, bedeutet dies, dass Sie die IP-Adresse des Remote-Hosts oder den DNS-Knotennamen in Elasticsearch nicht wie oben beschrieben definiert haben oder vergessen haben, die Elasticsearch-Dienste neu zu starten.

Um dies für den Elasticsearch-Cluster zu beheben, müssen Sie den Remote-Host zu allen Elasticsearch-Knoten hinzufügen und die Elasticsearch-Dienste neu starten.

2. SSL-Handshake-Ausnahme

Dieser Fehler bedeutet, dass Sie vergessen haben, reindex.ssl.certificate_authorities wie oben beschrieben zu elasticsearch.yml hinzuzufügen. So fügen Sie es hinzu:

2. Daten mit Snapshots übertragen

Denken Sie daran, dass Sie, wie oben erwähnt, einen Snapshot nur auf einem Cluster einer gleichen oder höheren Version wiederherstellen können und niemals mit einem Unterschied von mehr als einer Hauptversion

Wenn Sie um mehr als eine Hauptversion erhöhen müssen, müssen Sie neu indizieren oder Logstash verwenden.

Für die Datenübertragung per Snapshot sind folgende Schritte erforderlich:

Schritt 1. Hinzufügen des Repository-Plugins zum ersten Elasticsearch-Cluster – Um Daten über Snapshots zwischen Clustern zu übertragen, müssen Sie sicherstellen, dass sowohl vom neuen als auch vom alten Cluster auf das Repository zugegriffen werden kann. Cloud-Speicher-Repositories wie AWS, Google und Azure sind hierfür grundsätzlich ideal. Um Schnappschüsse zu machen, lesen Sie bitte unsere Anleitung und befolgen Sie die darin beschriebenen Schritte.

Schritt 2. Starten Sie den Elasticsearch-Dienst neu (Rolling Restart).

Schritt 3. Erstellen Sie ein Repository für den ersten Elasticsearch-Cluster.

Schritt 4: Fügen Sie das Repository-Plugin zum zweiten Elasticsearch-Cluster hinzu.

Schritt 5 – Repository als schreibgeschützt zum zweiten Elasticsearch-Cluster hinzufügen – Sie müssen ein Repository hinzufügen, indem Sie dieselben Schritte wiederholen, die Sie zum Erstellen des ersten Elasticsearch-Clusters ausgeführt haben.

Wichtiger Hinweis: Wenn Sie den zweiten Elasticsearch-Cluster mit demselben AWS S3-Repository verbinden, sollten Sie das Repository als schreibgeschütztes Repository definieren:

Dies ist wichtig, da Sie das Risiko einer Vermischung von Elasticsearch-Versionen im selben Snapshot-Repository vermeiden möchten.

Schritt 6 – Wiederherstellen der Daten im zweiten Elasticsearch-Cluster – Nachdem Sie die oben genannten Schritte ausgeführt haben, können Sie die Daten wiederherstellen und in den neuen Cluster übertragen. Befolgen Sie die in diesem Artikel beschriebenen Schritte, um Daten im neuen Cluster wiederherzustellen. 

3. Datenübertragung mit Logstash

Bevor Sie mit der Datenübertragung mit Logstash beginnen, denken Sie daran, dass Sie für alle Indizes im neuen Cluster entsprechende Zuordnungen einrichten müssen. Dazu müssen Sie die Indizes entweder direkt erstellen oder Indexvorlagen verwenden.

Um Daten zwischen zwei Elasticsearch-Clustern zu übertragen, können Sie einen temporären Logstash-Server einrichten und ihn zum Übertragen Ihrer Daten zwischen zwei Clustern verwenden. Für kleine Cluster sollte eine Instanz mit 2 GB RAM ausreichen. Für größere Cluster können Sie Vierkern-CPUs mit 8 GB RAM verwenden.

Eine Anleitung zur Installation von Logstash finden Sie hier.

Logstash-Konfiguration zum Übertragen von Daten von einem Cluster zu einem anderen

Eine grundlegende Konfiguration zum Kopieren eines einzelnen Indexes von Cluster A nach Cluster B ist:

Für eine sichere Elasticsearch können Sie die folgende Konfiguration verwenden:

Index-Metadaten

Die obigen Befehle schreiben in einen einzelnen benannten Index. Wenn Sie mehrere Indizes übertragen und die Indexnamen beibehalten möchten, müssen Sie der Logstash-Ausgabe die folgende Zeile hinzufügen:

Wenn Sie die ursprüngliche ID des Dokuments beibehalten möchten, müssen Sie außerdem Folgendes hinzufügen:

Bedenken Sie, dass die Datenübertragung durch das Festlegen der Dokument-ID erheblich langsamer wird. Behalten Sie die Original-ID daher nur bei, wenn es unbedingt erforderlich ist.

Synchronisierung von Updates

Alle oben beschriebenen Methoden dauern relativ lange und Sie stellen möglicherweise fest, dass Daten im ursprünglichen Cluster aktualisiert wurden, während Sie auf den Abschluss des Vorgangs gewartet haben.

Es gibt verschiedene Strategien, um die Synchronisierung aller Aktualisierungen zu ermöglichen, die während des Datenübertragungsprozesses aufgetreten sind. Sie sollten sich vor dem Starten dieses Prozesses einige Gedanken über diese Probleme machen. Insbesondere müssen Sie über Folgendes nachdenken:

• Über welche Methode können Sie Daten identifizieren, die seit Beginn des Datenübertragungsprozesses aktualisiert/hinzugefügt wurden (z. B. ein Feld „last_update_time“ in den Daten)?

• Mit welcher Methode können Sie die letzten Daten übertragen?

• Besteht die Gefahr, dass Datensätze dupliziert werden? Normalerweise ist dies der Fall, es sei denn, die von Ihnen verwendete Methode setzt die Dokument-ID während der Neuindizierung auf einen bekannten Wert.

Nachfolgend werden die verschiedenen Methoden zum Aktivieren der Synchronisierung von Updates beschrieben.

1. Einsatz von Warteschlangensystemen

Einige Aufnahme-/Aktualisierungssysteme verwenden Warteschlangen, die es Ihnen ermöglichen, in den letzten x Tagen empfangene Datenänderungen „wiederzugeben“. Dies kann eine Möglichkeit bieten, alle durchgeführten Änderungen zu synchronisieren.

2. Neuindizierung von Remote

Wiederholen Sie den Neuindizierungsprozess für alle Elemente, bei denen „last_update_time“ > x Tage her ist. Sie können dies tun, indem Sie der Neuindizierungsanforderung einen „Abfrage“-Parameter hinzufügen.

3. Logstash

In der Logstash-Eingabe können Sie eine Abfrage hinzufügen, um alle Elemente zu filtern, bei denen „last_update_time“ > x Tage her ist. Dieser Vorgang führt jedoch zu Duplikaten in Nicht-Zeitreihendaten, sofern Sie die Dokument-ID nicht festgelegt haben.

4. Schnappschüsse

Es ist nicht möglich, nur einen Teil eines Index wiederherzustellen. Sie müssten daher eine der anderen oben beschriebenen Datenübertragungsmethoden (oder ein Skript) verwenden, um alle Änderungen zu aktualisieren, die seit der Durchführung des Datenübertragungsprozesses stattgefunden haben.

Allerdings ist die Wiederherstellung von Snapshots ein viel schnellerer Prozess als die Neuindizierung/Logstash. Daher ist es möglicherweise möglich, Aktualisierungen für einen kurzen Zeitraum auszusetzen, während Snapshots übertragen werden, um das Problem insgesamt zu vermeiden.

Dieser Blogbeitrag untersucht, wie große Sprachmodelle (LLMs) verwendet werden können, um Synonyme automatisch zu identifizieren und zu generieren, sodass diese Begriffe programmatisch in die Synonym-API von Elasticsearch geladen werden können.

Wann verwendet man Synonyme?

Die Verwendung von Synonymen kann im Vergleich zur Vektorsuche eine schnellere und kostengünstigere Lösung sein. Die Implementierung ist einfacher, da sie keine tiefgreifenden Kenntnisse über Einbettungen oder einen komplexen Vektor-Ingestionsprozess erfordert.

Darüber hinaus ist der Ressourcenverbrauch geringer, da die Vektorsuche für die Einbettungsindizierung und den Abruf eine größere Speicherkapazität und einen größeren Arbeitsspeicher benötigt.

Ein weiterer wichtiger Aspekt ist die Regionalisierung der Suche. Mithilfe von Synonymen ist es möglich, Begriffe an die jeweilige Sprache und die lokalen Gepflogenheiten anzupassen. Dies ist in Situationen nützlich, in denen Einbettungen möglicherweise nicht mit regionalen Ausdrücken oder länderspezifischen Begriffen übereinstimmen. Beispielsweise können manche Wörter oder Akronyme je nach Region unterschiedliche Bedeutungen haben, werden aber von den lokalen Nutzern selbstverständlich als Synonyme behandelt. In Brasilien ist das recht üblich. „Abacaxi“ und „ananás“ bezeichnen die gleiche Frucht (Ananas), wobei der zweite Begriff in einigen Regionen des Nordostens gebräuchlicher ist. Ähnlich verhält es sich mit dem im Südosten bekannten „pão francês“, das im Nordosten als „pão careca“ bekannt ist.

Wie kann man LLMs verwenden, um Synonyme zu generieren?

Um Synonyme automatisch zu erhalten, können wir LLMs verwenden, die den Kontext eines Begriffs analysieren und passende Variationen vorschlagen. Dieser Ansatz ermöglicht die dynamische Erweiterung von Synonymen und gewährleistet so eine umfassendere und genauere Suche, ohne auf ein festes Wörterbuch angewiesen zu sein.

In dieser Demonstration verwenden wir ein LLM, um Synonyme für E-Commerce-Produkte zu generieren. Viele Suchanfragen liefern aufgrund von Variationen in den Suchbegriffen nur wenige oder gar keine Ergebnisse. Mit Synonymen können wir dieses Problem lösen. Eine Suche nach „Smartphone“ kann beispielsweise verschiedene Modelle von Mobiltelefonen umfassen, um sicherzustellen, dass die Nutzer die Produkte finden, die sie suchen.

Voraussetzungen

Bevor wir beginnen, müssen wir die Umgebung einrichten und die erforderlichen Abhängigkeiten definieren. Wir werden die von Elastic bereitgestellte Lösung nutzen, um Elasticsearch und Kibana lokal in Docker auszuführen. Der Code wird in Python, Version 3.9.6, mit folgenden Abhängigkeiten geschrieben:

Erstellung des Produktindex

Zunächst erstellen wir einen Index der Produkte ohne Synonymunterstützung. Dies ermöglicht es uns, Abfragen zu validieren und sie dann mit einem Index zu vergleichen, der Synonyme enthält.

Um den Index zu erstellen, laden wir einen Produktdatensatz per Massenimport mit folgendem Befehl in den Kibana DevTools:

Synonyme mit LLM generieren

In diesem Schritt verwenden wir ein LLM, um dynamisch Synonyme zu generieren. Um dies zu erreichen, werden wir die OpenAI-API integrieren und ein geeignetes Modell sowie eine entsprechende Eingabeaufforderung definieren. Der LLM erhält die Produktkategorie und den Produktnamen, wobei darauf geachtet wird, dass die Synonyme kontextuell relevant sind.

Aus dem erstellten Produktindex rufen wir alle Artikel der Kategorie „Elektronik“ ab und senden deren Namen an das LLM. Die erwartete Ausgabe sieht in etwa so aus:

Mit den generierten Synonymen können wir diese mithilfe der Synonyms API in Elasticsearch registrieren.

Synonyme mit der Synonyms-API verwalten

Die Synonyms-API bietet eine effiziente Möglichkeit, Synonymgruppen direkt im System zu verwalten. Jedes Synonymset besteht aus Synonymregeln, nach denen eine Gruppe von Wörtern bei Suchanfragen als gleichwertig behandelt wird.

Beispiel für die Erstellung eines Synonymsets

Dadurch entsteht eine Menge namens „meine-Synonyme-Menge“, in der „hello“ und „hi“ sowie „bye“ und „goodbye“ als gleichwertig behandelt werden.

Implementierung der Synonymerstellung für den Produktkatalog

Nachfolgend ist die Methode aufgeführt, die für den Aufbau eines Synonymsets und dessen Einfügen in Elasticsearch zuständig ist. Die Synonymregeln werden auf der Grundlage der vom LLM vorgeschlagenen Synonymzuordnung generiert. Jede Regel hat eine ID, die dem Produktnamen im Slug-Format entspricht, und die vom LLM berechnete Liste der Synonyme.

Nachfolgend die Anfragenutzlast zum Erstellen des Synonymsets:

Nachdem im Cluster ein Synonymset erstellt wurde, können wir zum nächsten Schritt übergehen, nämlich der Erstellung eines neuen Index mit Synonymunterstützung unter Verwendung des definierten Sets.

Der vollständige Python-Code mit den von LLM generierten Synonymen und der durch die Synonyms-API definierten Erstellung von Synonymsätzen ist unten aufgeführt:

Erstellen eines Index mit Synonymunterstützung

Es wird ein neuer Index erstellt, in dem alle Daten aus dem Index products neu indiziert werden. Dieser Index verwendet synonyms_filter, der den zuvor erstellten products-synonyms-set anwendet.

Nachfolgend die Indexzuordnung, die für die Verwendung von Synonymen konfiguriert ist:

Neuindizierung des Index products

Nun werden wir die Reindex-API verwenden, um die Daten vom Index products in den neuen Index products_02 zu migrieren, der auch Synonymunterstützung beinhaltet. Der folgende Code wurde in den Kibana DevTools ausgeführt:

Nach der Migration wird der Index products_02 gefüllt sein und kann Suchanfragen mithilfe des konfigurierten Synonymsets validieren.

Suche mit Synonymen validieren

Lassen Sie uns die Suchergebnisse der beiden Indizes vergleichen. Wir werden die gleiche Abfrage auf beiden Indizes ausführen und überprüfen, ob die Synonyme verwendet werden, um Ergebnisse abzurufen.

Suche im Index products (ohne Synonyme)

Wir werden Kibana verwenden, um Suchvorgänge durchzuführen und die Ergebnisse zu analysieren. Im Menü „Analytics > Discovery“ erstellen wir eine Datenansicht, um die Daten aus den von uns erstellten Indizes zu visualisieren.

Klicken Sie innerhalb von Discovery auf Datenansicht und definieren Sie einen Namen und ein Indexmuster. Für den Index "Produkte" verwenden wir das Muster "Produkte ". Anschließend wiederholen wir den Vorgang, um eine neue Datenansicht für den Index "products_02" zu erstellen, wobei wir das Muster "products_02 " verwenden.

Nachdem die Datenansichten konfiguriert sind, können wir zu Analytics > Discovery zurückkehren und die Validierungen starten.

Hier erhalten wir nach Auswahl der DataView-Produkte und einer Suche nach dem Begriff „Tablet“ keine Ergebnisse, obwohl wir wissen, dass es Produkte wie „Kindle Paperwhite“ und „Apple iPad Air“ gibt.

Suche im Index products_02 (unterstützt Synonyme)

Bei der Durchführung derselben Abfrage in der Datenansicht "products_synonyms", die Synonyme unterstützt, wurden die Produkte erfolgreich abgerufen. Dies beweist, dass die konfigurierte Synonymgruppe korrekt funktioniert und sicherstellt, dass verschiedene Variationen der Suchbegriffe die erwarteten Ergebnisse liefern.

Das gleiche Ergebnis lässt sich erzielen, indem man dieselbe Abfrage direkt in den Kibana DevTools ausführt. Suchen Sie einfach im Index products_02 mithilfe der Elasticsearch Search API:

Fazit

Die Implementierung von Synonymen in Elasticsearch verbesserte die Genauigkeit und Abdeckung der Produktkatalogsuche. Der entscheidende Unterschied bestand in der Verwendung eines LLM, das Synonyme automatisch und kontextbezogen generierte, wodurch die Notwendigkeit vordefinierter Listen entfiel. Das Modell analysierte Produktnamen und Kategorien und stellte dabei relevante Synonyme für den E-Commerce sicher.

Darüber hinaus vereinfachte die Synonyms-API die Wörterbuchverwaltung, sodass Synonymsätze dynamisch geändert werden können. Mit diesem Ansatz wurde die Suche flexibler und besser an unterschiedliche Suchanfragen der Nutzer anpassbar.

Dieser Prozess kann durch neue Daten und Modellanpassungen kontinuierlich verbessert werden, wodurch ein immer effizienteres Forschungserlebnis gewährleistet wird.

Referenzen

Elasticsearch lokal ausführen

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

Synonyms API

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

Heute geben wir die allgemeine Verfügbarkeit des neuen Indexmodus von Elasticsearch, logsdb, bekannt, der den Speicherbedarf von Protokolldaten im Vergleich zu aktuellen Versionen von Elasticsearch ohne logsdb um bis zu 65 % reduziert . Diese dramatische Verbesserung ermöglicht es Beobachtungs- und Sicherheitsteams, die Sichtbarkeit zu erweitern, ohne ihr Budget zu überschreiten, und gleichzeitig alle Daten für die Analyse sofort zugänglich zu halten.

Logsdb optimiert die Datenreihenfolge, eliminiert Duplikate durch die dynamische Rekonstruktion nicht gespeicherter Feldwerte mit synthetic _source und verbessert die Komprimierung mithilfe fortschrittlicher Algorithmen und Codecs. Dabei wird die spaltenorientierte Speicherung in Elasticsearch für eine effiziente Log-Speicherung und -abfrage genutzt.

Verbessern Sie die Analytik und senken Sie die Kosten, indem Sie die Speichereffizienz mit dem logsdb-Indexmodus steigern

Logs liefern entscheidende Signale zur Erkennung und Behebung von Beobachtbarkeits- und Sicherheitsproblemen — und ihr Nutzen nimmt zu, da Fortschritte in der KI die Analyse textbasierter Daten erleichtern. Daher sind effiziente Speicherung und leistungsstarker Zugriff wichtiger denn je.

Leider führt das wachsende Log-Volumen, das durch Infrastrukturen und Anwendungen erzeugt wird, zu steigenden Kosten und zwingt zu Kompromissen, die die Analyse behindern: die Erfassung einschränken, die Aufbewahrung reduzieren oder neue Daten in isolierte Archivstufen verschieben.

Logsdb geht diese Herausforderungen direkt an. Mit größerer Speichereffizienz können Sie mehr Daten erfassen und den Aufwand für komplizierte Datenfilterung vermeiden. Sie können Logs länger aufbewahren, um das Threat-Hunting, die Incident-Response und die Einhaltung von Compliance-Anforderungen zu unterstützen. Und da alle Daten stets durchsuchbar sind, können Sie schnelle Einblicke gewinnen, unabhängig davon, wie groß Ihr Datensatz wird.

Technische Innovation hinter dem logsdb-Indexmodus

Der logsdb-Indexmodus reduziert den Festplattenbedarf von Log-Daten erheblich durch intelligente Indexsortierung, synthetische _source und erweiterte Komprimierung. Durch die Implementierung kann der Speicherbedarf für Log-Daten um bis zu 65 % reduziert werden, im Vergleich zu neueren Versionen von Elasticsearch ohne logsdb. Obwohl logsdb derzeit bei der Indizierung mehr CPU verwendet, senkt die effiziente Speicherung die Gesamtkosten für die meisten Kunden. Für Kunden, die eine langfristige Speicherung benötigen, erwarten wir eine Reduzierung der Gesamtbetriebskosten (TCO) um bis zu 50 %.

Durch die intelligente Indexsortierung wird die Speichereffizienz um bis zu 30 % verbessert und die Abfragelatenz bei einigen Protokolldatensätzen verringert, indem ähnliche Daten nahe beieinander lokalisiert werden. Standardmäßig sortiert es Indizes nach Hostname und @Zeitstempel. Wenn Ihre Daten geeignetere Felder enthalten, können Sie diese stattdessen angeben.

Erweiterte Komprimierung reduziert den Speicherbedarf für textlastige Daten wie Protokolle durch Zstandard-Komprimierung (Zstd), Delta-Kodierung, Lauflängenkodierung und andere intelligente Codecs, die automatisch ausgewählt werden, erheblich. Doc-Werte, die in einem für Komprimierung und Leistung optimierten Spaltenformat gespeichert werden, ermöglichen eine effiziente Speicherung und Abfrage von Feldwerten zum Sortieren, Aggregieren und Skripten.

Mithilfe von Synthetic _source können Unternehmen ihren Speicherbedarf um weitere 20–40 % senken, indem sie das _source-Feld verwerfen und es bei Bedarf ganz oder teilweise rekonstruieren. Obwohl die Funktion manchmal mehr Rechenleistung für die Indizierung und Abfrage erfordert, zeigen Tests, dass sie messbare Nettoeffizienzverbesserungen liefert. Synthetic _source basiert auf fast zwei Jahren Produktionseinsatz mit Metriken und bietet zahlreiche Verbesserungen für Protokolle, einschließlich der Unterstützung für fast alle Feldtypen.

Die resultierenden Speicherplatzeinsparungen werden durch die Phasen des Index-Lebenszyklus weitergegeben. Eine Speicherreduzierung von 65 % in der Hot-Tier-Ebene führt zu einer entsprechenden Reduzierung in den Hot-, Cold- und Frozen-Tiers und verringert auch den Speicherbedarf für Snapshots im Bucket-Speicher.

Keine Kompromisse bei der Transparenz: Bewahren Sie alle Logs für die Beobachtbarkeit und Sicherheit auf

Logs sind die Basis für die Transparenz von Infrastruktur und Anwendungen und bieten das einfachste und wesentlichste Signal für das Monitoring und die Fehlerbehebung. Allerdings steigen die Kosten, wenn die Logging-Mengen zunehmen. Diese Herausforderung zwingt Kunden dazu, komplexe Filter- und Verwaltungsrichtlinien zu implementieren, Daten vorzeitig zu löschen und relevante Logs in Speichern abzulegen, die einen Tag oder länger benötigen, um vor der Analyse wiederhergestellt zu werden. Ohne einen vollständigen, leicht durchsuchbaren und zugänglichen Datensatz ist es erheblich schwieriger, Probleme zu identifizieren und zu beheben.

Der Logsdb-Indexmodus basiert auf bahnbrechenden Elasticsearch-Funktionen wie durchsuchbaren Snapshots und automatischem Import , um diese Schwachstellen für Betriebs- und Sicherheitsteams zu beheben:

Kosten senken: Logsdb reduziert den Speicherbedarf von Protokollen um bis zu 65 %, sodass Unternehmen ihre Speicherkosten senken und gleichzeitig mehr Daten speichern können. Dies führt zu Kosteneinsparungen auf allen Speicherebenen – von „Hot“ bis „Frozen“ – und einer höheren Produktivität für die Beobachtungs- und Sicherheitsteams, die diese Daten verwenden.

Bewahren Sie wertvolle Daten auf: Logsdb speichert alle Ihre Protokolldaten und verbessert die Betriebseffizienz, ohne auf zusätzliche Tools oder komplizierte Filter angewiesen zu sein. Mit Funktionen wie „synthetic_source“ bewahren Sie den Wert der Daten, ohne das gesamte Quelldokument zu speichern.

Erweitern Sie die Sichtbarkeit: Logsdb bietet effizienten Zugriff auf alle Daten auf einer Plattform, ohne separate Silos für Beobachtbarkeit, Sicherheit und historische Daten. Für Site Reliability Engineers (SREs) beschleunigt es die Problemlösung, indem es die Analyse von Protokollen neben Metriken, Traces und Geschäftsdaten ermöglicht. Ebenso beschleunigt es für Security Operations Center (SOC)-Teams die Untersuchung und Behebung, indem es blinde Flecken beseitigt.

Optimieren Sie den Datenzugriff: Mit Logsdb können SRE-Teams verwertbare Daten zur Fehlerbehebung, Trendanalyse und Analyse effizient speichern. Ebenso können SOC-Teams alle ihre Daten schnell und ohne exorbitante Kosten zu Untersuchungszwecken und zur Bedrohungssuche durchsuchen.

Logsdb ist bereit für Ihre Umgebung

Der Indexmodus „Logsdb“ von Elasticsearch ist für Kunden mit Elastic Cloud Hosted und Self-Managed ab Version 8.17 allgemein verfügbar und für Protokolle in Elastic Cloud Serverless standardmäßig aktiviert.

Grundlegende logsdb-Funktionen (einschließlich intelligenter Indexsortierung und erweiterter Komprimierung) sind für Unternehmen mit Standard-, Gold- und Platinum-Lizenzen verfügbar. Vollständige logsdb-Funktionen, die die Speicheranforderungen weiter reduzieren (einschließlich synthetic _source), stehen serverlosen Kunden und Unternehmen mit einer Enterprise-Lizenz zur Verfügung.

Elasticsearch logsdb in Aktion

Logsdb ermöglicht es Ihnen, alle Ihre Log-Daten zu behalten und die Betriebseffizienz zu verbessern, ohne das Erfassen einzuschränken oder Daten zu verwerfen oder zu isolieren. Mit Funktionen wie intelligenter Indexsortierung, erweiterter Komprimierung und synthetic _source können Sie die benötigten Daten innerhalb eines für Sie passenden Budgets speichern und analysieren.

Möchten Sie es selbst erleben? Testen Sie Elastic kostenlos.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.

Viele E-Commerce-Websites sind daran interessiert, das Sucherlebnis für Rezepte zu verbessern. Die semantische Suche ermöglicht es Kunden bei korrekter Anwendung, die benötigten Zutaten schnell anhand natürlicher Suchanfragen zu finden, wie zum Beispiel „etwas für den Valentinstag“ oder „Thanksgiving-Gerichte“.

In diesem Artikel zeigen wir, wie man Elasticsearch zur Implementierung einer semantischen Suche nutzt, die solche Anfragen unterstützt. Wir werden einen Index konfigurieren, um den Katalog der Zutaten und Produkte eines Supermarkts zu speichern, und demonstrieren, wie dieser Index zur Verbesserung der Rezeptsuche verwendet werden kann. Im Verlauf des Artikels erklären wir, wie diese Datenstruktur erstellt wird und wie Techniken der natürlichen Sprachverarbeitung angewendet werden, um relevante Ergebnisse zu liefern, die der Absicht des Kunden entsprechen.

Der gesamte in diesem Artikel vorgestellte Code wurde in Python entwickelt und ist auf GitHub verfügbar. Sie können auf das Repository zugreifen, um den Quellcode einzusehen, gegebenenfalls Anpassungen vorzunehmen und die Lösungen direkt in Ihrer Entwicklungsumgebung zu implementieren.

Beginn der Implementierung der semantischen Suche

Um mit der Implementierung der semantischen Suche zu beginnen, müssen wir zunächst das natürliche Sprachmodell definieren. Elastic bietet sein eigenes Modell ELSER an, unterstützt aber auch die Integration von NLP-Modellen verschiedener Anbieter, wie beispielsweise Hugging Face. Diese Flexibilität ermöglicht es Ihnen, die Option zu wählen, die Ihren Bedürfnissen am besten entspricht.

In diesem Artikel verwenden wir ELSER, das die Komplexität der Bereitstellung und Verwaltung von NLP-Modellen reduziert. Darüber hinaus bietet Elastic die Funktion semantic_text an, die den Prozess erheblich vereinfacht. Mit semantic_text wird der gesamte Einbettungsgenerierungsprozess unkompliziert und automatisiert. Sie müssen lediglich einen Inferenzpunkt definieren und das Feld angeben, das die Einbettungen in Ihrer Indexzuordnung aufnehmen soll. Während der Dokumentenindizierung werden Einbettungen generiert und automatisch dem angegebenen Feld zugeordnet.

Einrichtungsschritte

Nachfolgend sind die Schritte zum Erstellen eines Index mit semantischer Suchunterstützung aufgeführt. Wenn Sie diese Anweisungen befolgen, wird Ihr Index konfiguriert und ist bereit für semantische Suchen:

1. Erstelle den Inferenzpunkt.

2. Erstellen Sie den Index und setzen Sie das Beschreibungsfeld auf semantic_text, damit er die Einbettungen empfangen kann.

3. Die Daten werden im Lebensmittelkatalogindex indexiert , der einen Produktkatalog speichert. Dieser Katalog wurde aus einem hier verfügbaren Datensatz erstellt.

Anwendung der semantischen Suche in Supermärkten

Nachdem wir den Index nun mit Produktdaten aus Lebensmittelgeschäften gefüllt haben, testen und validieren wir Suchanfragen, um die Suchergebnisse mithilfe der semantischen Suche zu verbessern. Unser Ziel ist es, ein intelligenteres Sucherlebnis zu bieten, das den Kontext und die Absicht des Nutzers versteht und relevantere und genauere Ergebnisse liefert.

Durch semantische Suche gelöste Herausforderungen

Anhand des Produktkatalogs wollen wir untersuchen, wie die semantische Suche das Sucherlebnis in Supermärkten verändern kann, indem sie Vokabel- und Kontextprobleme angeht, mit denen die traditionelle lexikalische Suche oft zu kämpfen hat.

1. Interpretation kulinarischer Absichten

Problem 01: Ein Kunde sucht möglicherweise nach „Meeresfrüchte zum Grillen“, aber ein lexikalisches Suchsystem versteht die Absicht hinter der Suchanfrage möglicherweise nicht vollständig. Es kann vorkommen, dass nicht alle zum Grillen geeigneten Meeresfrüchteprodukte erkannt werden und nur diejenigen zurückgegeben werden, die den genauen Begriff „Meeresfrüchte“ oder „Grill“ im Produktnamen enthalten.

Zunächst führen wir eine lexikalische Suche durch und analysieren die Ergebnisse. Anschließend werden wir das Gleiche mit einer semantischen Suche durchführen und die Ergebnisse für denselben Suchbegriff vergleichen.

lexikalische Abfrage

Ergebnisse:

Suchtyp

Name

Punktzahl

Lexikalisch

Nordwestfisch Alaskan Bairdi Schneekrabbe

10,453125

Lexikalisch

Herr Yoshidas, Sauce Original Gourmet

7,2289705

Lexikalisch

Premium-Meeresfrüchte-Probierpaket – 20 Stück

7.1924105

Lexikalisch

Amerikanischer Roter Schnapper - Ganz, mit Kopf, ausgenommen

6,998647

Lexikalisch

Hummerscheren und -arme, nachhaltig wild gefangen

6,438654

Die lexikalische Suche ergab einige Meeresfrüchte, die sich zum Grillen eignen, wie zum Beispiel Amerikanischer Roter Schnapper und Nordwestfisch Alaskan Bairdi Schneekrabbe. Die lexikalische Suche lieferte jedoch weniger relevante Produkte an die Spitze der Liste, wie zum Beispiel die Mr. Yoshida Sauce, die keine Meeresfrüchte-, sondern eine Fleischsauce ist. Dies lässt darauf schließen, dass der lexikalische Algorithmus Schwierigkeiten hatte, den Kontext von „zum Grillen“ vollständig zu verstehen.

Lösung für semantische Suche

Wir verwenden eine Abfrage, die den Begriff „Meeresfrüchte“ mit Zubereitungskontexten wie „Grillen“ kombiniert, um eine umfassende Liste von Optionen zurückzugeben, wie zum Beispiel Fischfilets, Garnelen und Jakobsmuscheln, die sich ideal zum Grillen eignen – selbst wenn die Wörter „Grill“ oder „Meeresfrüchte“ nicht direkt im Produktnamen vorkommen. Dadurch wird sichergestellt, dass die Suchergebnisse besser mit den Absichten des Kunden übereinstimmen.

semantische Suche:

Suchtyp

Name

Punktzahl

Semantisch

Ganzer, ausgenommener Wolfsbarsch mit Kopf

16.175909

Semantisch

Alaska-Schwarzkabeljau (Sablefisch)

15,855331

Semantisch

Amerikanischer Roter Schnapper - Ganz, mit Kopf

15,454779

Semantisch

Nordwestfisch Alaskan Bairdi Schneekrabbe

15,855331

Semantisch

Amerikanischer Roter Schnapper - Ganz, mit Kopf

15,3892355

Die semantische Suche lieferte nicht nur Produkte, die direkt mit dem Begriff „Meeresfrüchte“ in Verbindung standen, sondern verstand auch den Kontext von „Grillen“ und brachte ganze Fische und Filets zum Vorschein, die zum Grillen geeignet sind. Entscheidend ist hierbei die Präzision der Ergebnisse, die auch ganze Fischsorten wie Branzino und Alaska Black Cod umfassten, die beide häufig zum Grillen verwendet werden.

Problem 02 : Viele Kunden suchen nach schnellen und einfachen Abendessenlösungen nach einem langen Arbeitstag und verwenden dabei Begriffe wie „einfache Abendessen für die Woche“. Die traditionelle lexikalische Suche erfasst das Konzept der Schnellgerichte möglicherweise nicht vollständig, da sie sich oft nur auf Produkte konzentriert, die das Wort „einfach“ in ihrem Namen enthalten.

Wie schon in der vorherigen Aufgabe beginnen wir mit einer lexikalischen Suche. Anschließend werden wir eine Lösung mittels semantischer Suche anwenden.

lexikalische Abfrage

Ergebnisse:

Suchtyp

Name

Punktzahl

Lexikalisch

Avery Easy Peel Adressetiketten, 4200 Stück

8,017723

Lexikalisch

Omeals Selbsterhitzende Not-/Portable Mahlzeiten 32

6,592727

Lexikalisch

Poke-Brot mit Gelbflossenthunfischwürfeln

5,836883

Lexikalisch

Hefty Super Weight 12 oz Schaumstoff

5,8116536

Lexikalisch

Vanity Fair Alltagsservietten, 2-lagig, 110 Stück

5,752989

Die lexikalische Suche lieferte deutlich weniger relevante Ergebnisse, darunter Artikel, die in keinem Zusammenhang mit Mahlzeiten stehen, wie zum Beispiel Avery Easy Peel Adressetiketten und Vanity Fair Everyday Servietten. Diese Produkte erfüllen nicht das Bedürfnis des Nutzers nach schnellen Mahlzeiten. Während die lexikalische Suche ein nützliches Produkt (Omeals Selbstheizende Notfallmahlzeiten) lieferte, enthielten andere Ergebnisse, wie Servietten und Etiketten, in ihren Beschreibungen lediglich die Wörter „einfach“ oder „Wochentag“, ohne wirklich auf die Absicht des Nutzers nach einer schnellen Mahlzeitenlösung einzugehen.

Lösung für semantische Suche

Wir haben eine Abfrage implementiert, die die Absicht hinter schnellen und einfachen Mahlzeiten versteht. Es assoziiert Produkte, die schnell zubereitet werden können, wie vorgekochtes Fleisch, Tiefkühlnudeln oder Fertiggerichte, auch wenn sie das Wort „einfach“ nicht explizit im Namen tragen. Dieser Ansatz stellt sicher, dass die Kunden die am besten geeigneten Optionen für ein schnelles Abendessen unter der Woche finden und somit dem Bedürfnis nach Bequemlichkeit gerecht werden.

semantische Suche

Ergebnisse:

Suchtyp

Name

Punktzahl

Semantisch

Omeals Selbsterhitzende Not-/Portable Mahlzeiten 32

14.610006

Semantisch

Nissin, Cup Noodles, Garnelen, 71 g

13,751424

Semantisch

Namaste Glutenfreie Waffel- und Pfannkuchenmischung

13,73376

Semantisch

Idaho-Kartoffeln, Golden Grill Hashbrown-Kartoffeln

12,549422

Semantisch

Nissin Cup Noodles, Hühnchen, 24er-Packung

12.034527

Die semantische Suche ergab Produkte, die eindeutig mit schnellen und praktischen Mahlzeiten in Verbindung stehen, wie zum Beispiel Instantnudeln (Cup Noodles), vorgekochte Kartoffeln und Pfannkuchenmischungen, die typische Optionen für ein einfaches Abendessen unter der Woche sind. Dies beweist, dass die semantische Suche das Konzept hinter dem Ausdruck „einfache Gerichte für die Woche“ erfassen kann und die Absicht des Nutzers erkennt, schnelle und bequeme Mahlzeiten zu finden. Interessanterweise können auch Produkte aus anderen Kategorien, wie zum Beispiel „Limonade“, einbezogen werden, wenn dies im Kontext relevant ist (z. B. Getränke zu Mahlzeiten).

2. Regionale Begriffe und Vokabelvariationen

Problem: Ein Kunde sucht möglicherweise nach „Soda“, während ein anderer Kunde für dasselbe Produkt „Pop“ verwendet. Die traditionelle lexikalische Suche erkennt nicht, dass sich beide Begriffe auf denselben Gegenstand beziehen.

lexikalische Abfrage

Ergebnisse:

Suchtyp

Name

Punktzahl

Lexikalisch

Prime Hydration+ Sticks Elektrolyt-Getränkemischung

14,492869

Lexikalisch

Capri Sun, 100 % Saft, Probierpackung

12.340851

Lexikalisch

Joyburst Energy Drink, Frose Rose, 12

11,839179

Lexikalisch

Kellogg's Pop-Tarts, Zuckerguss-Zimt

9,97788

Lexikalisch

Kind Mini-Riegel, Probierpackung, 0,7

9,336912

Die lexikalische Suche konzentriert sich auf exakte Wortübereinstimmungen. Während Produkte wie Prime Hydration und Capri Sun zurückgegeben wurden, führte die direkte Übereinstimmung mit dem Begriff „Pop“ auch zu irrelevanten Ergebnissen, wie zum Beispiel Kellogg's Pop-Tarts, das ein Snack und kein Getränk ist. Dies verdeutlicht, wie die lexikalische Suche weniger effektiv sein kann, wenn ein Begriff mehrere Bedeutungen hat oder mehrdeutig sein kann.

Lösung für semantische Suche

Bei semantischen Anfragen können wir das Problem der Vokabelvariationen überwinden, das bei der lexikalischen Suche nicht gelöst werden kann. Durch die Erweiterung der Suchbegriffe können wir Ergebnisse erzielen, die auf dem Kontext basieren und relevantere und umfassendere Antworten liefern.

Abfrage:

Ergebnisse:

Suchtyp

Name

Punktzahl

Semantisch

Olipop 12 oz Präbiotika-Limonade (verschiedene Sorten)

14,776867

Semantisch

Bai Antioxidant Cocofusion, Probierpackung, 18

14,663253

Semantisch

Monster Energy Drink, Zero Ultra, 24

14,486348

Semantisch

Joyburst Energy Variety, 355 ml

14.007214

Semantisch

Joyburst Energy Drink, Frose Rose, 12

13,641038

Die semantische Suche liefert Produkte, die direkt dem Konzept von „Pop“ als Synonym für „Soda“ entsprechen (wie z. B. Olipop Prebiotics Soda), auch wenn der genaue Begriff „Pop“ nicht im Produktnamen enthalten ist. Die Suche erkannte die Absicht des Nutzers – ein erfrischendes Getränk mit wenig Zucker – und konnte relevante Produkte zurückgeben, darunter Optionen wie präbiotische Limonaden (Olipop) und zuckerfreie Energy-Drinks (Monster Energy Drink).

Fazit

Die Implementierung der semantischen Suche im Kontext von Lebensmittelgeschäften hat sich als äußerst effektiv erwiesen, um komplexe Anfragen wie „Meeresfrüchte zum Grillen“ und „einfache Gerichte für die Woche“ zu verstehen. Dieser Ansatz ermöglichte es uns, die Absicht der Nutzer genauer zu interpretieren und ihnen hochrelevante Produkte zurückzugeben.

Durch den Einsatz von Elasticsearch und die Vereinfachung des Prozesses mit ELSER konnten wir die semantische Suche schnell und effizient implementieren, die Suchergebnisse deutlich verbessern und ein agileres und zielgerichteteres Einkaufserlebnis ermöglichen. Dadurch wurde nicht nur der Suchprozess optimiert, sondern auch die Relevanz der den Kunden angebotenen Ergebnisse erhöht.

Referenzen

Modell ELSER:

https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference-api.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-elser.html

Semantischer Text:

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-text.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

Datensatz:

https://www.kaggle.com/datasets/bhavikjikadara/grocery-store-dataset?select=GroceryDataset.csv

Semantische Suche:

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search-semantic-text.html