Elasticsearch-Shards und -Replikate: Ein praktischer Leitfaden

Neu bei Elasticsearch? Nehmen Sie an unserem Webinar „Erste Schritte mit Elasticsearch“ teil. Sie können jetzt auch eine kostenlose Cloud-Testversion starten oder Elastic auf Ihrem Rechner testen.

Elasticsearch erweitert die Leistungsfähigkeit von Lucene, indem es ein verteiltes System darauf aufbaut, wodurch die Probleme der Skalierbarkeit und Fehlertoleranz gelöst werden. Es stellt außerdem eine JSON-basierte REST-API bereit, wodurch die Interoperabilität mit anderen Systemen sehr einfach ist.

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.