1. Verwendung der _mapping API zum Abrufen von Feldinformationen

2. Verwendung der _search API zum Anzeigen von Feldwerten

3. Filtern von Feldern mithilfe des Parametersfields

4. Verschachtelte Felder anzeigen

1. Verwendung der _mapping-API zum Abrufen von Feldinformationen

Die _mapping API ermöglicht es Ihnen, die Mapping-Definition für einen oder mehrere Indizes abzurufen. Dies umfasst Informationen über die Felder, ihre Datentypen und weitere Eigenschaften. Um die Zuordnung für einen bestimmten Index abzurufen, verwenden Sie die folgende Anfrage:

Wenn Sie beispielsweise einen Index mit dem Namen my_index haben, können Sie dessen Zuordnung mit der folgenden Anfrage abrufen:

Die Antwort enthält die Mapping-Definition für den Index, die Informationen über die Felder und deren Eigenschaften enthält.

Es ist auch möglich, die Zuordnung eines bestimmten Feldes abzurufen. Dies kann nützlich sein, wenn Ihre Kartierung recht umfangreich ist und Sie sich nur auf ein bestimmtes Feld konzentrieren möchten. Um die Zuordnung eines bestimmten Feldes abzurufen, verwenden Sie die folgende Anfrage:

Sie können die Zuordnungen mehrerer Felder auch abrufen, indem Sie deren Namen durch Kommas trennen, wie in der folgenden Anfrage:

2. Verwenden der _search-API zum Anzeigen von Feldwerten

Um die Werte von Feldern in einem Elasticsearch-Index anzuzeigen, können Sie die _search API verwenden. Standardmäßig gibt die _search API das Feld _source zurück, welches das ursprüngliche JSON-Dokument enthält, das indiziert wurde. Um nur bestimmte Felder anzuzeigen, können Sie den Parameter _source in der Suchanfrage verwenden.

Hier ist ein Beispiel für eine Suchanfrage, die die Werte der Felder title und author für Dokumente im Index my_index zurückgibt:

In diesem Beispiel gibt der Parameter _source die zurückzugebenden Felder an.

3. Filtern von Feldern mithilfe des Parameters „fields“

Sie können auch den Parameter fields verwenden, um die in der Suchantwort zurückgegebenen Felder zu filtern. Dies kann nützlich sein, wenn Sie nur bestimmte Felder benötigen und die Größe der Antwort reduzieren möchten. Der Parameter fields akzeptiert ein Array von Feldnamen oder Platzhaltermustern.

Um beispielsweise nur die Felder title und author für Dokumente im Index my_index zurückzugeben, können Sie die folgende Suchanfrage verwenden:

Beachten Sie, dass der Parameter _source auf false gesetzt ist, um das Quelldokument nicht zurückzugeben.

Um alle Felder mit dem Datentyp text zurückzugeben, können Sie ein Wildcard-Muster wie dieses verwenden:

4. Anzeigen verschachtelter Felder

Wenn Ihr Index verschachtelte Felder enthält, können Sie die Punktnotation verwenden, um den Pfad des verschachtelten Feldes im Parameter fields anzugeben. Wenn Sie beispielsweise ein verschachteltes Feld mit dem Namen address.city haben, können Sie es wie folgt in die Suchergebnisseinlösung einbinden:

In diesem Beispiel enthält die Suchergebnisseinsendung die Werte der Felder title, author und address.city .

Fazit

Zusammenfassend lässt sich sagen, dass die Anzeige von Feldern in einem Elasticsearch-Index durch die Verwendung der _mapping -API zum Abrufen von Feldinformationen und der _search -API zum Anzeigen von Feldwerten erreicht werden kann. Sie können die in der Suchantwort zurückgegebenen Felder entweder mit den Parametern _source oder fields filtern und verschachtelte Felder mit der Punktnotation anzeigen. Mithilfe dieser Techniken können Sie die Struktur Ihrer Daten verstehen, bestimmte Felder identifizieren und Probleme beheben.

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.

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.

In diesem Artikel werden wir die Gründe für den Ausschluss von Feldern aus der Indizierung, die Konfiguration von Elasticsearch zum Ausschluss bestimmter Felder und einige bewährte Vorgehensweisen dabei erläutern.

Gründe für den Ausschluss von Feldern aus der Indizierung

1. Leistung: Die Indizierung aller Felder in einem Dokument kann zu längeren Indizierungszeiten und einer langsameren Suchleistung führen. Durch den Ausschluss von Feldern, die für die Suche oder Aggregation nicht erforderlich sind, können Sie die Gesamtleistung Ihres Elasticsearch-Clusters verbessern.

2. Speicherplatz: Das Indizieren von Feldern benötigt Speicherplatz. Durch das Ausschließen von Feldern, die für die Suche oder Aggregation nicht benötigt werden, können die Speicheranforderungen Ihres Elasticsearch-Clusters reduziert werden.

3. Indexgröße: Die Größe eines Elasticsearch-Index steht in direktem Zusammenhang mit der Anzahl der indizierten Felder. Durch den Ausschluss unnötiger Felder können Sie die Größe Ihres Index minimieren, was zu einer schnelleren Such- und Indexierungsleistung führen kann.

Elasticsearch so konfigurieren, dass Felder ausgeschlossen werden

Um ein Feld von der Indizierung in Elasticsearch auszuschließen, können Sie die „index“-Eigenschaft in der Feldzuordnung verwenden. Wenn die Eigenschaft „index“ auf „false“ gesetzt wird, wird Elasticsearch das Feld nicht indizieren, und es ist weder durchsuchbar noch für Aggregationen verfügbar.

Hier ist ein Beispiel dafür, wie man ein Feld mithilfe des Elasticsearch-Mappings von der Indizierung ausschließt:

In diesem Beispiel erstellen wir einen neuen Index namens „my_index“ mit einem einzigen Feld namens „field_to_exclude“. Indem wir die Eigenschaft „index“ auf „false“ setzen, weisen wir Elasticsearch an, dieses Feld nicht zu indizieren. Das Feld wird jedoch im Quelldokument weiterhin verfügbar sein.

Bewährte Verfahren zum Ausschließen von Feldern von der Indizierung

1. Analysieren Sie Ihre Daten: Bevor Sie Felder von der Indizierung ausschließen, ist es unerlässlich, Ihre Daten zu analysieren und zu verstehen, welche Felder für die Suche und Aggregation notwendig sind. Dies wird Ihnen helfen, fundierte Entscheidungen darüber zu treffen, welche Felder ausgeschlossen werden sollen.

2. Testen Sie Ihre Änderungen: Wenn Sie Felder von der Indizierung ausschließen, ist es unerlässlich, Ihre Änderungen zu testen, um sicherzustellen, dass Ihre Such- und Aggregationsfunktionen weiterhin wie erwartet funktionieren. Dies kann Ihnen helfen, unerwartete Probleme oder Leistungsstörungen zu vermeiden.

3. Leistungsüberwachung: Nachdem Sie Felder von der Indizierung ausgeschlossen haben, sollten Sie die Leistung Ihres Elasticsearch-Clusters überwachen, um sicherzustellen, dass Ihre Änderungen den gewünschten Effekt erzielt haben. Dies kann Ihnen dabei helfen, eventuell erforderliche zusätzliche Optimierungen zu identifizieren.

4. Quellfilterung nutzen: Wenn Sie ein Feld in Elasticsearch speichern müssen, es aber nicht durchsuchbar oder für Aggregationen verfügbar sein soll, sollten Sie die Quellfilterung in Betracht ziehen. Dies ermöglicht es Ihnen, das Feld im Feld _source zu speichern, es aber vom Index auszuschließen.

Fazit

Das Ausschließen von Feldern von der Indizierung in Elasticsearch kann die Leistung verbessern, die Speicherkosten senken und die Gesamtgröße Ihres Index minimieren. Durch eine sorgfältige Analyse Ihrer Daten und das Verständnis, welche Felder für die Suche und Aggregation notwendig sind, können Sie fundierte Entscheidungen darüber treffen, welche Felder ausgeschlossen werden sollten. Testen Sie Ihre Änderungen stets und überwachen Sie die Leistung Ihres Elasticsearch-Clusters, um sicherzustellen, dass Ihre Optimierungen den gewünschten Effekt erzielen.

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.

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.

• Mapping-Definitionen legen das Datenschema fest.

• In den Einstellungen werden die Shard-Größe und die Aktualisierungsraten festgelegt. 

• Aliase werden verwendet, um dem Index alternative Namen zu geben.

Wenn wir ein Dokument zum ersten Mal indexieren oder einen leeren Index mithilfe der Create Index API erstellen, wird der Index mit Standardeinstellungen, ohne Datenschema und ohne Aliase erstellt. Diese Standardeinstellungen funktionieren in Entwicklungs- und Testumgebungen recht gut, aber für Produktionsumgebungen müssen wir unsere Indizes möglicherweise anpassen.

Die Verwendung der Standardzuordnungen und -einstellungen in der Produktionsumgebung kann zu einer schlechten Indexierungs- und Suchleistung führen. Das manuelle Erstellen von Indizes ist ein mühsamer und zeitaufwändiger Prozess. Die Neuerstellung solcher Indizes in jeder Umgebung ist besonders unpraktisch, wenn wir ein aufwendiges Mapping-Schema sowie benutzerdefinierte Einstellungen und Aliase haben.

Glücklicherweise stellt Elasticsearch uns ein Werkzeug zur Verfügung, mit dem wir beim Erstellen von Indizes automatisch eine vordefinierte Konfiguration in Form von Indexvorlagen anwenden können .

Indexvorlagen

Indexvorlagen ermöglichen es uns, Indizes mit benutzerdefinierter Konfiguration zu erstellen. Ein Index kann die Konfiguration aus diesen Vorlagen abrufen, beispielsweise eine festgelegte Anzahl von Shards und Replikaten oder Feldzuordnungen, während seiner Instanziierung. Es wird eine Vorlage mit einem Namensmuster und einigen Konfigurationseinstellungen definiert. Wenn der Name des Index mit dem Namensmuster der Vorlage übereinstimmt, wird der neue Index mit der in der Vorlage definierten Konfiguration erstellt.

Elasticsearch hat in Version 7.8 seine Template-Funktionalität mit zusammensetzbaren Templates verbessert. Diese neuere Version bietet wesentlich mehr wiederverwendbare Indexvorlagen, wie in diesem Artikel gezeigt wird.

Arten von Indexvorlagen

Indexvorlagen lassen sich in zwei Kategorien einteilen:

• Indexvorlagen (oder zusammensetzbare Indexvorlagen): Die zusammensetzbaren Indexvorlagen können entweder allein existieren oder aus keiner oder mehreren Komponentenvorlagen zusammengesetzt sein (siehe die zweite Kategorie).

• Komponentenvorlagen: Die Komponentenvorlage ist eine wiederverwendbare Vorlage, die die erforderliche Konfiguration definiert. Üblicherweise wird erwartet, dass die Komponentenvorlage mit einer Indexvorlage verknüpft ist. Jede der Komponentenvorlagen kann mit einer oder mehreren Indexvorlagen verknüpft werden. 

Wie Sie im Bild unten sehen können, teilen sich die Indexvorlagen A und B Komponentenvorlagen (in diesem Fall nur eine – Vorlage 3). Eine Indexvorlage kann aus keiner oder mehreren Komponentenvorlagen bestehen, und jede der Komponentenvorlagen kann keiner oder mehreren Indexvorlagen zugeordnet sein. Beide Arten von Vorlagen können eigenständig existieren, jedoch sind Komponentenvorlagen nur dann nützlich, wenn sie an eine Indexvorlage angehängt werden.

Die Grundidee besteht darin, einen Katalog von Komponentenvorlagen zu entwickeln, die eine Organisation für verschiedene Zwecke nutzen kann (z. B. die verschiedenen Komponentenvorlagen für einzelne Umgebungen festlegen) und diese über die zusammensetzbaren Indexvorlagen verschiedenen Indizes zuzuordnen.

Wie man zusammensetzbare (Index-)Vorlagen erstellt

Elasticsearch bietet einen _index_template-Endpunkt zur Verwaltung von Indexvorlagen. Der Benutzer gibt in dieser Vorlage alle erforderlichen Zuordnungen, Einstellungen und Aliase sowie ein Indexnamensmuster an. Betrachten wir ein Beispiel für die Erstellung einer Vorlage für eine Microservice-Anwendung namens customer-order-service , die für die Logik zur Auftragsgenerierung zuständig ist. 

Nehmen wir an, unsere Anforderung ist es, eine Vorlage für Kundenbestellungen zu erstellen, die durch ein Muster mit Platzhaltern dargestellt wird: *orders. Diese Vorlage muss bestimmte Zuordnungen und Einstellungen enthalten, wie zum Beispiel das Feld order_date sowie Shard- und Replikatnummern.

Jeder Index, der bei seiner Erstellung mit dieser Vorlage übereinstimmt, erbt die in dieser Vorlage definierten Konfigurationen. Ein Index namens black_friday_orders beispielsweise hat das Feld order_date, die Anzahl der Shards ist auf 5 und die Anzahl der Replikate auf 2 festgelegt. Darüber hinaus erben alle aus dieser Vorlage erstellten Indizes auch einen einzigen Aliasnamen ! Erstellen wir nun diese orders_template mit einem Indexmuster, das als *orders definiert ist, und einem Mapping-Schema, das aus einem einzigen Feld der_date mit dem vordefinierten Datumsformat dd-MM-yyyy besteht. Der folgende Code zeigt, wie diese Indexvorlage erstellt wird.

Wenn Sie diese Abfrage in den Kibana DevTools ausführen, wird die Vorlage mit dem Indexmuster *orders zusammen mit dem vordefinierten Mapping, den Einstellungen und einem Alias erstellt. index_patterns ist ein Array von Übereinstimmungsmustern; jeder Index, der diesem Muster entspricht, leitet die Vorlagenkonfiguration ab. Sie können folgenden Befehl ausführen, um die gespeicherte Vorlage abzurufen, die unsere Aktionen wiederholen sollte:

Außerdem wird beim Erstellen des Vorlagenattributs, das in der Vorlage definiert ist, eine Priorität, eine positive Zahl, festgelegt: Jede Vorlage wird mit einer Priorität definiert, sodass etwaige Konflikte zwischen Änderungen aus verschiedenen Vorlagen durch Verwendung dieses Wertes aufgelöst werden, wobei dem Wert mit der höheren Priorität Vorrang eingeräumt wird. Wir werden uns weiter unten eingehender mit der Priorisierung von Vorlagen befassen.

Erstellen eines Index mit der Vorlage

Jetzt haben wir eine Vorlage – einen Bauplan für die Erstellung von Indizes – der nächste Schritt ist die Erstellung eines Indexes. Wenn der Name des Index mit dem angegebenen Muster übereinstimmt, werden die Vorlagenkonfigurationen automatisch angewendet. Um dies zu beweisen, erstellen wir, wie der folgende Code zeigt, einen brandneuen Index mit dem Namen: blackfriday_orders:

Da der Name des Index (blackfriday_orders) mit dem im Template definierten Namensmuster übereinstimmt (d. h. *orders), sollte der Index alle aus der Vorlage abgeleiteten Konfigurationen erhalten. Lassen Sie uns diesen neu erstellten Index abrufen und überprüfen, ob dies tatsächlich zutrifft, indem wir den folgenden Code ausführen:

Dies sollte folgendes Ergebnis liefern:

Wie die Antwort zeigt, wurde die Konfiguration von blackfriday_orders aus der Vorlage übernommen. Wir können verschiedene Kombinationen der Indizes ausprobieren, die die Vorlagenkonfiguration erfolgreich übernehmen:

Die folgenden Indizes werden die Konfiguration jedoch nicht übernehmen, da ihr Name nicht dem Muster entspricht:

Wichtig zu beachten ist, dass alle von einer Vorlage abgeleiteten Indizes in diesem Fall denselben Alias haben – all_orders. Ein solcher Alias hat den Vorteil, dass wir einfach über diesen einen Alias anstatt über mehrere Indizes abfragen können.

Während wir eine Vorlage für *orders erstellen, wird erwartet, dass jeder übereinstimmende Index die Konfiguration der Vorlage übernimmt. In der Regel erstellen Teams, bewusst oder unbewusst, aus verschiedenen Gründen einige zusätzliche Vorlagen. Das bedeutet, dass der Indexname unter Umständen mit zwei verschiedenen Vorlagenmustern übereinstimmen kann! Elasticsearch muss entscheiden, welche der Konfigurationen aus diesen Vorlagen angewendet werden soll. Glücklicherweise lässt sich dieses Dilemma durch die Verwendung der Vorlagenpriorität lösen.

Erstellung von Komponentenvorlagen

Wir haben im vorangegangenen Teil dieses Artikels etwas über Indexvorlagen gelernt. Es gibt ein paar Nachteile bei der Erstellung der Vorlagen mit integrierter Konfiguration – einer dieser Nachteile ist, dass die Konfiguration nicht für andere Vorlagen exportiert werden kann. Wenn wir eine ähnliche Konfiguration wünschen, beispielsweise für kundenbezogene Vorlagen (*customers), müssen wir möglicherweise die gesamte Vorlage neu erstellen. Das bedeutet, dass wir in einer typischen Organisation Dutzende davon erstellen (und je nach Umgebung können noch einige weitere hinzukommen).

Da wir stets auf Wiederverwendbarkeit Wert legen, hat Elasticsearch die Templates unter Berücksichtigung der Wiederverwendbarkeit neu gestaltet. Die Komponentenvorlagen erfüllen diese Anforderung. Wenn Sie aus dem DevOps-Bereich kommen, besteht für Sie höchstwahrscheinlich die Anforderung, Indizes mit einer vordefinierten Konfiguration für jede Umgebung zu erstellen. Anstatt jede dieser Konfigurationen mühsam manuell anzuwenden, können Sie für jede Umgebung eine Komponentenvorlage erstellen.

Eine Komponentenvorlage ist nichts anderes als ein wiederverwendbarer Konfigurationsblock, mit dem wir weitere Indexvorlagen erstellen können. Beachten Sie, dass die Komponentenvorlagen nur dann einen Nutzen haben, wenn sie mit Indexvorlagen kombiniert werden. Sie werden über einen _component_template-Endpunkt bereitgestellt. Mal sehen, wie das alles zusammenpasst.

Einstellungen in einer Indexvorlage

Lassen Sie uns die Einstellungen, die wir zuvor in unserer Indexvorlage definiert haben, extrahieren und daraus eine Komponentenvorlage erstellen. Es wird erwartet, dass die settings_component_template fünf primäre Shards mit jeweils zwei Replikaten pro primärem Shard besitzt. Der erste Schritt besteht, wie die untenstehende Codeauflistung zeigt, darin, eine Komponentenvorlage mit dieser Konfiguration zu deklarieren und auszuführen.

Wie der obige Code zeigt, verwenden wir den Endpunkt _component_template, um eine Komponentenvorlage zu erstellen. Der Anfragetext enthält die Vorlageninformationen in einem Vorlagenobjekt. Die settings_component_template kann nun auch an anderer Stelle in den Indexvorlagen verwendet werden. Ein wesentlicher Unterschied besteht darin, dass diese Vorlage kein Indexmuster definiert; es handelt sich lediglich um einen Codeblock, der einige Eigenschaften für uns konfiguriert.

Mapping-Vorlage

Erstellen wir auf die gleiche Weise eine weitere Vorlage. Dieses Mal extrahieren wir das Mapping-Schema, das wir zuvor in den eigenständigen Indexvorlagen definiert hatten. Der folgende Code zeigt das Skript:

Aliasvorlage

Im gleichen Sinne können wir auch eine Komponentenvorlage mit den Aliasen haben – zwei Aliase (all_orders und sales_orders):

Vorlage für einen zusammensetzbaren Index

Nachdem wir nun diese drei Komponentenvorlagen haben, besteht der nächste Schritt darin, sie einzusetzen. Wir können dies erreichen, indem wir eine Indexvorlage, beispielsweise für christmas_orders, diese verwenden lassen:

Das `composed_of`-Tag ist eine Sammlung aller Komponentenvorlagen, aus denen diese Vorlage besteht. In diesem Fall wählen wir die Komponentenvorlagen für Einstellungen, Zuordnungen und Aliase aus. Wir erhöhen außerdem die Priorität, sodass diese Vorlage alle anderen übertrifft. Sobald die Vorlage fertig ist, erben alle Indizes, die dem Muster *orders entsprechen, die Konfiguration von diesen drei Komponentenvorlagen.

Wenn wir nun eine neue Vorlage, beispielsweise für Kunden, mit nur einer der bestehenden Vorlagen (settings_component_template) und einer neu erstellten Aliasvorlage (aliases_component_template – siehe unten) erstellen möchten, können wir dies wie folgt tun:

Die Indexvorlage sieht folgendermaßen aus:

Ist Ihnen aufgefallen, dass die settings_component_template in zwei verschiedenen Templates (wieder)verwendet wurde? Das ist die Stärke von Komponentenvorlagen.

Indexvorlagenpriorität

Es besteht die Möglichkeit, dass Entwickler mehrere Indexvorlagen erstellen, ohne den vorhandenen Bestand zu berücksichtigen. Es ist wichtig, jeder dieser Vorlagen eine Priorität zuzuweisen, damit diejenige mit der höheren Priorität verwendet wird. Beispielsweise überschreibt my_orders_template_1 im folgenden Codeausschnitt my_orders_template_2:

Wenn mehrere Vorlagen zu den zu erstellenden Indizes passen, wendet Elasticsearch alle Konfigurationen aus allen passenden Vorlagen an, überschreibt aber alle Konfigurationen mit höherer Priorität.

Priorität der Vorlagen

Abschließend stellt sich vielleicht die Frage nach der Priorität der Vorlagen – überschreibt die in der Komponentenvorlage definierte Konfiguration diejenige, die in der Hauptindexvorlage selbst definiert ist? Oder umgekehrt? Nun ja, es gibt einige Regeln:

• Ein Index, der mit expliziten Konfigurationen erstellt wurde, hat Vorrang vor allem anderen – das bedeutet, wenn Sie einen Index mit expliziten Konfigurationen erstellen, können Sie nicht davon ausgehen, dass diese von den Vorlagen überschrieben werden.

• Legacy-Vorlagen (Vorlagen, die vor Version 7.8 erstellt wurden) haben eine niedrigere Priorität als die zusammensetzbaren Vorlagen.

Zusammenfassung

• Ein Index enthält Mappings, Einstellungen und Aliase: Die Mappings definieren das Feldschema, die Einstellungen legen die Indexparameter wie die Anzahl der Shards und Replikate fest, und die Aliase geben dem Index alternative Namen.

• Mithilfe von Vorlagen können wir Indizes mit vordefinierten Konfigurationen erstellen. Wenn ein Index mit einem Namen benannt wird, der dem in einer bestimmten Vorlage definierten Indexmuster entspricht, wird dieser Index automatisch gemäß der Vorlage konfiguriert.

• Elasticsearch führte in Version 7.8 zusammensetzbare Indexvorlagen ein. Zusammensetzbare Indexvorlagen ermöglichen Modularität und Versionierung von Vorlagen.

• Die zusammensetzbaren Vorlagen bestehen aus keiner oder mehreren Komponentenvorlagen.

• Eine Indexvorlage kann auch über eine eigene Konfiguration verfügen.

• Eine Komponentenvorlage ist eine wiederverwendbare Vorlage mit vordefinierter Konfiguration, genau wie eine zusammensetzbare Indexvorlage.

• Allerdings wird von Komponentenvorlagen erwartet, dass sie Teil einer Indexvorlage sind; sie sind nutzlos, wenn sie nicht in eine Indexvorlage „zusammengesetzt“ werden.

• Komponentenvorlagen haben kein definiertes Indexmuster – was ein weiterer Grund dafür ist, dass sie „erwartet“ werden, Teil einer Indexvorlage zu sein.

• Jede der Vorlagen hat eine Priorität – eine positive Zahl. Je höher die Zahl, desto höher ist die Priorität für die Anwendung dieser Vorlage.

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.

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.