Elasticsearch Shard-Sizing-Leitfaden: Leistung und Skalierbarkeit im Gleichgewicht

Elasticsearch ist eine leistungsstarke, verteilte Such- und Analyse-Engine, die hervorragend für die Verarbeitung großer Datenmengen geeignet ist. Die optimale Leistung und Stabilität hängen jedoch maßgeblich davon ab, wie Sie Ihre Datenverteilung strukturieren – insbesondere die Shard-Größe. Shards sind die grundlegenden Bausteine von Elasticsearch-Indizes; sie bestimmen, wie Daten partitioniert, repliziert und auf die Cluster-Knoten verteilt werden. Eine falsche Shard-Größe kann zu schwerwiegenden Leistungsengpässen, erhöhtem Betriebsaufwand oder im Gegenteil zu ungenutzten Ressourcen führen.

Dieser Elasticsearch Shard-Sizing-Leitfaden bietet Ihnen eine praktische Methode, um eine anfängliche Shard-Anzahl zu wählen und diese mit realen Workload-Metriken zu validieren. Ziel ist nicht eine perfekte Zahl, sondern eine Shard-Anordnung, die wiederherstellbar, durchsuchbar und kosteneffizient bleibt, während Ihre Daten wachsen.

Grundlegendes zu Elasticsearch-Shards

Bevor wir uns mit der Dimensionierung befassen, ist es wichtig zu verstehen, was ein Shard ist und wie er in der Cluster-Architektur funktioniert. Ein Index in Elasticsearch besteht aus einem oder mehreren Primär-Shards. Jeder Primär-Shard ist ein unabhängiger, Lucene-basierter Index, der Daten hosten kann.

Primäre vs. Replikat-Shards

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

Die Auswirkungen der Shard-Anzahl

Die Gesamtzahl der Shards (Primär + Replikat) wirkt sich direkt auf den Cluster-Overhead aus. Jeder Shard benötigt Speicher (Heap-Speicher) und CPU-Ressourcen, um seinen Status und seine Metadaten zu verfolgen. Zu viele kleine Shards überlasten den Master-Knoten und erhöhen den Cluster-Verwaltungsaufwand, 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, der Indexierungsrate und den Abfragemustern ab. Die Elasticsearch-Dokumentation und die Best Practices der Community bieten jedoch mehrere wichtige Richtlinien.

1. Größenschwellenwert: Die optimale Shard-Größe

Der wichtigste Faktor ist die Größe der Daten, die in einem einzelnen Shard enthalten sind.

Häufiger Zielbereich: Viele Produktionscluster streben primäre Shards im Bereich 10 GB bis 50 GB an.
Vorsicht bei großen Shards: Größere Shards können für einige reine Anhänge- oder Workloads mit geringen Abfragen funktionieren, erhöhen jedoch die Wiederherstellungszeit und verteuern die Verlagerung. Testen Sie, bevor Sie sich auf Shards nahe oder über 100 GB verlassen.

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

2. Schwellenwert für die Dokumentanzahl

Während die Größe von größter Bedeutung ist, ist auch die Dokumentanzahl relevant, insbesondere bei sehr kleinen Dokumenten.

Es gibt keine universelle sichere Dokumentanzahl pro Shard. Ein Shard mit Millionen winziger Log-Dokumente kann sich gut verhalten, während ein Shard mit weniger großen, stark analysierten Dokumenten teuer sein kann. Verfolgen Sie sowohl die Shard-Speichergröße als auch das Workload-Verhalten, anstatt sich nur auf die Dokumentanzahl zu verlassen.

3. Cluster-Overhead und Shard-Anzahl

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

Ältere Richtlinien verwendeten oft Shard-pro-GB-Heap-Regeln. Behandeln Sie diese als grobe Warnsignale, nicht als feste Grenzen. Modernes Elasticsearch hat einen geringeren Pro-Shard-Heap-Overhead als ältere Versionen, aber zu viele Shards erhöhen immer noch die Cluster-State-Arbeit, Datei-Handles, Segment-Overhead und die Wiederherstellungskomplexität.

Praktische Methodik zur Shard-Dimensionierung

Verwenden Sie die folgenden Schritte, um die angemessene Anzahl primärer Shards für einen neuen Index basierend auf der erwarteten Gesamtdatengröße zu berechnen.

Schritt 1: Schätzen Sie die gesamte Indexgröße

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

Beispiel: Wir gehen davon aus, dass wir 2 TB Daten für unseren Index logs-2024 speichern werden.

Schritt 2: Definieren Sie die Ziel-Shard-Größe

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

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

Schritt 3: Berechnen Sie die erforderlichen primären Shards

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{Gesamtindexgröße}}{\text{Ziel-Shard-Größe}} \right)$$

Beispielrechnung (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: Bestimmen Sie die Replikatanzahl

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

Ausfallsicherheit: Setzen Sie number_of_replicas auf mindestens 1 (für hohe Verfügbarkeit).
Suchleistung: Wenn das Suchaufkommen hoch ist, verwenden Sie 2 oder mehr Replikate.
Beispiel: Wir wählen 1 Replikat für die Standard-Fehlertoleranz.

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

Schritt 5: Auf Knoten verteilen

Stellen Sie sicher, dass Ihr Cluster über genügend Knoten, Heap, Festplatten- und E/A-Kapazität verfügt, um diese Shards effektiv zu hosten. Bei Replikaten muss Elasticsearch in der Lage sein, jedes Replikat auf einem anderen Knoten als seinem Primär-Shard zu platzieren.

Verwaltung des Index-Lebenszyklus und der Größenänderung

Elasticsearch erlaubt es nicht, index.number_of_shards direkt an einem vorhandenen Index zu ändern. Sie können Split-, Shrink- oder Reindex-Workflows verwenden, aber jeder hat Anforderungen und betriebliche Kosten.

Die Rolle des Index Lifecycle Management (ILM)

Für Zeitreihendaten (Logs, Metriken) ist die beste Praxis, Index Lifecycle Management (ILM) und die Rollover-Funktion zu nutzen.

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

Hot-Phase: Daten werden in den aktuellen 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 primärer Shards) und schaltet den Alias so um, dass er auf den neuen Index zeigt. Der alte Index wechselt in eine andere Phase (Warm/Cold).

Dieser Ansatz ermöglicht es Ihnen, konsistent dimensionierte, optimal leistungsfähige Shards über Ihren Datenlebenszyklus hinweg beizubehalten.

Wann eine Neupartitionierung erforderlich ist (Fortgeschritten)

Wenn ein vorhandener Index aufgrund unvorhergesehener Datenmuster weit über die 50-GB-Empfehlung 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 aus dem alten, schlecht dimensionierten Index in den neuen zu kopieren.
Aktualisieren Sie Aliase, sodass sie auf den neuen Index verweisen.
Löschen Sie den alten Index.

Warnung zum Reindexing: Reindexing ist ein ressourcenintensiver Vorgang. Es sollte in verkehrsarmen Zeiten 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
Individuelle Shard-Größe	Halten Sie primäre Shards zwischen 10 GB und 50 GB (max. 100 GB).
Dokumentanzahl	Beobachten Sie die Dokumentanzahl als sekundäres Signal, validieren Sie jedoch mit Abfrage- und Indexierungsmetriken.
Cluster-Overhead	Halten Sie die Shard-Anzahl niedrig genug, sodass Heap-Druck, Cluster-State-Updates und Wiederherstellung gesund bleiben.
Indexverwaltung	Verwenden Sie Index Lifecycle Management (ILM) und Rollover für Zeitreihendaten, um eine kontinuierlich optimale Dimensionierung sicherzustellen.
Größenänderung	Versuchen Sie nicht, die Anzahl der primären Shards an Live-Indizes zu ändern; verwenden Sie die Reindex-API, um Daten zu einem korrekt dimensionierten neuen Index zu migrieren.

Beginnen Sie mit einer Ziel-Shard-Größe, berechnen Sie die primären Shards aus dem erwarteten Datenvolumen und validieren Sie dann mit Lasttests und Produktionsmetriken. Für Zeitreihendaten ist der ILM-Rollover in der Regel der sauberste Weg, um die Shard-Größen ohne ständige manuelle Eingriffe vorhersagbar zu halten.