Indexvorlagen in Elasticsearch: Wie man zusammensetzbare Vorlagen verwendet

Mit Elasticsearch können Sie Daten schnell und flexibel indexieren. Testen Sie es kostenlos in der Cloud oder führen Sie es lokal aus, um zu erfahren, wie einfach die Indizierung sein kann.

Ein Elasticsearch-Index kann über Mapping, Einstellungen und Aliase konfiguriert werden: 

• 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 Vorlagen

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.

Komponentenvorlagen erstellen

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.

Vorlage für Einstellungen

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.

Vorlagenprioritä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.