Elasticsearch Shard Sizing Guide: Leistung und Skalierbarkeit ausbalancieren

Elasticsearch ist eine leistungsstarke, verteilte Such- und Analyse-Engine, die sich hervorragend für die Verarbeitung riesiger Datenmengen eignet. Die Optimierung von Leistung und Stabilität hängt jedoch maßgeblich davon ab, wie Sie Ihre Datenverteilung strukturieren – insbesondere die Shard-Größe. Shards sind die fundamentalen Bausteine von Elasticsearch-Indizes; sie bestimmen, wie Daten im Cluster partitioniert, repliziert und verteilt werden. Unsachgemäße Shard-Größen können zu erheblichen Leistungsengpässen, erhöhtem Betriebsaufwand oder umgekehrt zu ungenutzten Ressourcen führen.

Diese Anleitung bietet einen praktischen Rahmen zur Bestimmung der optimalen Shard-Größe in Ihrem Elasticsearch-Cluster. Wir werden die kritischen Kompromisse zwischen Abfrageleistung, Indexierungsdurchsatz, Cluster-Ausfallsicherheit und Ressourcenverbrauch untersuchen, um Ihnen zu helfen, die perfekte Balance für Ihre spezifische Arbeitslast zu finden.

Elasticsearch-Shards verstehen

Bevor wir uns mit der Größenbestimmung befassen, ist es wichtig zu verstehen, was ein Shard ist und wie er innerhalb der Cluster-Architektur funktioniert. Ein Index in Elasticsearch besteht aus einem oder mehreren primären Shards. Jeder primäre Shard ist ein unabhängiger, auf Lucene basierender Index, der Daten hosten kann.

Primäre vs. Replica-Shards

Primäre Shards: Diese enthalten die eigentlichen Daten. Sie sind für Indexierungs- und Suchvorgänge zuständig. Wenn Sie die Anzahl der primären Shards für einen Index festlegen, entscheiden Sie, wie die Daten horizontal über den Cluster verteilt werden.
Replica-Shards: Dies sind Kopien der primären Shards. Sie bieten Redundanz (Fehlertoleranz) und erhöhen den Suchdurchsatz, da Abfragen sowohl von primären als auch von Replica-Kopien bedient werden können.

Die Auswirkungen der Shard-Anzahl

Die Gesamtzahl der Shards (Primär + Replica) wirkt sich direkt auf den Overhead des Clusters aus. Jeder Shard benötigt Speicher (Heap-Speicher) und CPU-Ressourcen zur Verfolgung seines Status und seiner Metadaten. Zu viele kleine Shards überlasten den Master-Knoten und erhöhen den Verwaltungsaufwand des Clusters, was zu Leistungseinbußen führt, selbst wenn einzelne Shards klein sind.

Wichtige Einschränkungen und Größenempfehlungen

Es gibt keine einzelne "magische Zahl" für die Shard-Größe. Die optimale Größe hängt stark von Ihrem Datenvolumen, Ihrer Indexierungsrate und Ihren Abfragemustern ab. Die Elasticsearch-Dokumentation und die Community-Best Practices bieten jedoch mehrere wichtige Richtlinien.

1. Größen-Schwellenwert: Die optimale Shard-Größe

Der kritischste Faktor ist die Größe der Daten, die ein einzelner Shard enthält.

Empfohlene maximale Größe: Der allgemeine Konsens und die Best Practices empfehlen, einzelne primäre Shards zwischen 10 GB und 50 GB zu halten.
Absolute Maximalgröße: Obwohl technisch möglich, wird die Überschreitung von 100 GB pro Shard dringend abgeraten, da dies Wiederherstellungsvorgänge, Indexierungsleistung und Cluster-Stabilität stark belastet.

Warum die Begrenzung? Wenn ein Knoten ausfällt, muss Elasticsearch die auf diesem Knoten gespeicherten Shards neu zuweisen (verlegen oder neu replizieren). Große Shards erhöhen die für die Wiederherstellung erforderliche Zeit erheblich und verlängern das Fenster reduzierter Ausfallsicherheit. Darüber hinaus arbeitet Lucene besser, wenn es mittelgroße Segmente verwaltet.

2. Dokumentenanzahl-Schwellenwert

Obwohl die Größe von größter Bedeutung ist, ist auch die Dokumentenanzahl relevant, insbesondere bei sehr kleinen Dokumenten.

Empfohlener Dokumentenbereich: Streben Sie Shards mit zwischen 100.000 und 5 Millionen Dokumenten an.

Wenn Ihre Dokumente extrem klein sind (z. B. einige hundert Bytes), erreichen Sie möglicherweise das Größenlimit (50 GB), bevor Sie die Empfehlung zur Dokumentenanzahl erreichen. Umgekehrt, wenn Dokumente sehr groß sind (z. B. Multi-Megabyte-JSON-Blobs), erreichen Sie möglicherweise schnell das Limit für die Dokumentenanzahl, während Sie das Größenlimit unterschreiten.

3. Cluster-Overhead und Shard-Anzahl

Begrenzen Sie die Gesamtzahl der Shards pro Knoten, um den Ressourcenverbrauch effektiv zu verwalten.

Shards pro GB Heap: Eine gängige Richtlinie besagt, dass die Gesamtzahl der Shards (primär + Repliken) so gehalten werden sollte, dass der Cluster etwa 20 Shards pro 1 GB Heap-Speicher verwendet, der den Datenknoten zugewiesen ist.

Beispielberechnung: Wenn Ihre Datenknoten 30 GB Heap zugewiesen haben:

$$30 \text{ GB} \times 20 \text{ Shards/GB} = 600 \text{ Gesamt-Shards}$$

Wenn Sie 100 primäre Shards für einen Index benötigen, stellen Sie sicher, dass der Cluster über genügend Knoten verfügt, um den gesamten Overhead gemäß diesem Verhältnis überschaubar zu halten.

Praktische Methodik zur Shard-Größenbestimmung

Verwenden Sie die folgenden Schritte, um die geeignete Anzahl von primären Shards für einen neuen Index basierend auf der erwarteten Gesamtgröße der Daten zu berechnen.

Schritt 1: Gesamte Indexgröße schätzen

Bestimmen Sie die Gesamtmenge der Daten, die dieser Index voraussichtlich während seiner Betriebszeit (z. B. 6 Monate oder 1 Jahr) speichern wird.

Beispiel: Wir erwarten, 2 TB Daten für unseren logs-2024-Index zu speichern.

Schritt 2: Ziel-Shard-Größe definieren

Wählen Sie eine sichere Zielgröße basierend auf den Richtlinien (z. B. 40 GB).

Beispiel: Ziel-Shard-Größe = 40 GB.

Schritt 3: Benötigte primäre Shards berechnen

Teilen Sie die geschätzte Gesamtgröße durch die Ziel-Shard-Größe. Runden Sie immer auf die nächste ganze Zahl auf.

$$\text{Primäre Shards} = \text{Ceiling} \left( \frac{\text{Gesamte Indexgröße}}{\text{Ziel-Shard-Größe}} \right)$$

Beispielberechnung (2 TB = 2048 GB):
$$\text{Primäre Shards} = \text{Ceiling} \left( \frac{2048 \text{ GB}}{40 \text{ GB}} \right) = \text{Ceiling}(51,2) = 52$$

In diesem Szenario sollten Sie den Index mit 52 primären Shards erstellen.

Schritt 4: Replika-Anzahl bestimmen

Entscheiden Sie sich für die Anzahl der Replikate basierend auf Ihren Anforderungen an Ausfallsicherheit und Suchvolumen.

Ausfallsicherheit: Setzen Sie number_of_replicas auf mindestens 1 (für Hochverfügbarkeit).
Suchleistung: Wenn der Suchverkehr hoch ist, verwenden Sie 2 oder mehr Replikate.
Beispiel: Wir wählen 1 Replikat für standardmäßige Fehlertoleranz.

Endgültige Index-Einstellungen: 52 primäre Shards und 1 Replikat (insgesamt 104 Shards).

Schritt 5: Über Knoten verteilen

Stellen Sie sicher, dass Ihr Cluster über genügend Knoten (und ausreichend Heap-Speicher) verfügt, um diese Shards effektiv zu hosten und die Regel von 20 Shards/GB Heap einzuhalten.

Verwaltung des Indexlebenszyklus und Größenänderung

Elasticsearch unterstützt nicht die Größenänderung der Anzahl primärer Shards auf einem vorhandenen, nicht leeren Index. Dies ist eine kritische Einschränkung, die Sie bei der anfänglichen Gestaltung beachten sollten.

Die Rolle von Index Lifecycle Management (ILM)

Für Zeitreihendaten (Protokolle, Metriken) ist die beste Vorgehensweise die Nutzung von Index Lifecycle Management (ILM) und der Rollover-Funktion.

Anstatt einen einzigen riesigen, schwer zu verwaltenden Index zu erstellen, erstellen Sie einen Rollover-Alias, der auf eine Vorlage verweist.

Hot Phase: Daten werden in den aktuell aktiven Index geschrieben. ILM überwacht diesen Index basierend auf Größe oder Alter (z. B. Rollover, wenn er 40 GB erreicht).
Rollover: Wenn der Schwellenwert erreicht ist, erstellt Elasticsearch automatisch einen neuen Index basierend auf der Vorlage (mit der berechneten Anzahl von primären Shards) und ändert den Alias so, dass er auf den neuen Index verweist. Der alte Index wechselt in eine andere Phase (Warm/Cold).

Dieser Ansatz ermöglicht es Ihnen, über den gesamten Datenlebenszyklus hinweg konsistent große, optimal leistende Shards beizubehalten.

Wann Re-Sharding notwendig ist (Fortgeschritten)

Wenn ein vorhandener Index aufgrund unvorhergesehener Datenmuster weit über die empfohlene Größe von 50 GB hinauswächst, müssen Sie die Reindex API verwenden, um die Shard-Verteilung zu korrigieren:

Erstellen Sie einen neuen Index mit der korrigierten (optimalen) Shard-Konfiguration.
Verwenden Sie die Reindex API, um alle Daten vom alten, falsch dimensionierten Index in den neuen zu kopieren.
Aktualisieren Sie die Aliase, damit sie auf den neuen Index verweisen.
Löschen Sie den alten Index.

Warnung zum Reindexing: Reindexing ist ein ressourcenintensiver Vorgang. Er sollte außerhalb von Spitzenzeiten mit hohem Datenverkehr geplant werden und erfordert ausreichende Cluster-Ressourcen, um die gleichzeitige Last von Indexierung und Kopieren zu bewältigen.

Zusammenfassung der Best Practices

Bereich	Best Practice / Richtlinie
Einzelne Shard-Größe	Primäre Shards zwischen 10 GB und 50 GB halten (max. 100 GB).
Dokumentenanzahl	100.000 bis 5 Mio. Dokumente pro Shard anstreben (sekundär zur Größe).
Cluster-Overhead	Gesamtzahl der Shards (primär + Replika) auf etwa 20 Shards pro 1 GB Heap auf Datenknoten begrenzen.
Indexverwaltung	Index Lifecycle Management (ILM) und Rollover für Zeitreihendaten verwenden, um eine kontinuierlich optimale Größenanpassung zu gewährleisten.
Größenänderung	Versuchen Sie nicht, die Anzahl der primären Shards bei Live-Indizes zu ändern; verwenden Sie die Reindex API, um Daten in einen neu dimensionierten Index zu migrieren.

Durch die Einhaltung dieser Größenrichtlinien und die Nutzung von ILM für die kontinuierliche Verwaltung können Sie sicherstellen, dass Ihr Elasticsearch-Cluster leistungsfähig, skalierbar und widerstandsfähig gegen Betriebsfehler bleibt.