Optimale Shard-Größe: Ausgleich zwischen Cluster-Leistung und Verwaltung

Optimale Shard-Größe: Balance zwischen Cluster-Performance und Management

Elasticsearch, eine leistungsstarke verteilte Such- und Analyse-Engine, ist stark auf ihre Fähigkeit angewiesen, Daten effizient über Knoten hinweg zu verwalten und zu verteilen. Eine zentrale Komponente dieser Verteilung ist das Konzept der Shards. Shards sind kleinere, handhabbare Teile Ihres Indexes, und wie Sie deren Größe und Verteilung gestalten, hat einen tiefgreifenden Einfluss auf die Performance, Skalierbarkeit und Verwaltbarkeit Ihres Clusters. Dieser Artikel beleuchtet die kritischen Überlegungen zur Bestimmung der optimalen Shard-Größe in Elasticsearch und hilft Ihnen, das richtige Gleichgewicht zwischen roher Performance und operativem Aufwand zu finden.

Das Verständnis der Shard-Größe ist entscheidend für jede Elasticsearch-Bereitstellung. Zu viele kleine Shards können zu erhöhtem Overhead führen, was die Knotenressourcen und die Abfragelatenz beeinträchtigt. Umgekehrt können zu wenige große Shards die Skalierbarkeit behindern, Hot Spots erzeugen und Wiederherstellungsvorgänge langwierig machen. Dieser Leitfaden vermittelt Ihnen das Wissen und praktische Strategien, um fundierte Entscheidungen über Ihre Shard-Zuweisung zu treffen, was zu einem effizienteren und robusteren Elasticsearch-Cluster führt.

Die Grundlagen von Elasticsearch Shards

Bevor wir uns den Sizing-Strategien widmen, ist es wichtig, die grundlegenden Konzepte zu verstehen:

Index: Eine Sammlung von Dokumenten. In Elasticsearch wird ein Index in mehrere Shards unterteilt.
Shard: Eine Verteilungseinheit. Jeder Shard ist ein eigenständiger Lucene-Index. Ein Index kann mehrere Shards enthalten, die auf verschiedene Knoten im Cluster verteilt sind.
Primary Shard: Wenn ein Index erstellt wird, wird ihm eine feste Anzahl von primären Shards zugewiesen. Diese Shards sind die Orte, an denen Ihre Daten indiziert werden. Einmal erstellt, kann die Anzahl der primären Shards nicht geändert werden. Sie können jedoch weitere Replica Shards hinzufügen.
Replica Shard: Kopien Ihrer primären Shards. Sie bieten Redundanz und erhöhen den Lese-Durchsatz. Fällt ein primärer Shard aus, kann ein Replikat zum primären Shard befördert werden. Die Anzahl der Replica Shards kann jederzeit geändert werden.

Wie Shards die Performance beeinflussen

Indizierungs-Performance: Jeder Shard benötigt Ressourcen für die Indizierung. Mehr Shards bedeuten mehr Overhead für die koordinierenden Knoten, die Anfragen verwalten. Wenn Shards jedoch zu groß werden, kann die Indizierung in einen einzelnen Shard zu einem Engpass werden.
Abfrage-Performance: Suchanfragen werden an alle relevanten primären Shards verteilt. Eine höhere Anzahl von Shards kann die Anzahl der zu verarbeitenden Anfragen erhöhen, was potenziell die Latenz erhöht. Umgekehrt können sehr große Shards zu längeren Suchzeiten führen, da Lucene mehr Daten innerhalb dieses Shards verarbeiten muss.
Cluster-Management: Eine große Anzahl von Shards erhöht die Last auf dem Master-Knoten, der für das Cluster-Statusmanagement verantwortlich ist. Dies wirkt sich auch auf den Overhead von Operationen wie Shard-Relocation, Snapshotting und Recovery aus.
Ressourcennutzung: Jeder Shard verbraucht Speicher und Festplatten-I/O. Zu viele Shards können die Knotenressourcen erschöpfen, was zu einer verschlechterten Performance oder Knoteninstabilität führt.

Wichtige Überlegungen zur Shard-Größe

Die „ideale“ Shard-Größe ist keine feste Zahl; sie hängt von Ihrer spezifischen Arbeitslast, den Datenmerkmalen und der Hardware ab. Mehrere Faktoren sollten jedoch Ihre Entscheidungen leiten:

1. Datenvolumen und Wachstumsrate

Aktuelle Datengröße: Wie viele Daten haben Sie derzeit in Ihrem Index?
Wachstumsrate: Wie schnell wachsen Ihre Daten? Dies hilft, zukünftige Shard-Größen vorherzusagen.
Datenaufbewahrungsrichtlinie: Werden Sie alte Daten löschen? Dies beeinflusst die effektive Größe der aktiven Daten.

2. Indizierungslast

Indizierungsrate: Wie viele Dokumente pro Sekunde indizieren Sie?
Dokumentengröße: Wie groß sind einzelne Dokumente im Durchschnitt?
Indizierungs-Durchsatz: Können Ihre Knoten die Indizierungslast mit der aktuellen Shard-Konfiguration bewältigen?

3. Abfragemuster

Abfragekomplexität: Sind Ihre Abfragen einfache Stichwortsuchen oder komplexe Aggregationen?
Abfragefrequenz: Wie oft werden Abfragen für Ihre Daten ausgeführt?
Abfrage-Latenzanforderungen: Was sind Ihre akzeptablen Antwortzeiten?

4. Cluster-Topologie und Ressourcen

Anzahl der Knoten: Wie viele Knoten hat Ihr Cluster?
Knoten-Hardware: CPU, RAM und Festplatte (SSD wird für Elasticsearch dringend empfohlen).
Shard-Limit pro Knoten: Elasticsearch hat ein Standardlimit für die maximale Anzahl von Shards, die ein Knoten aufnehmen kann, um Performance-Probleme zu vermeiden. Dies wird durch cluster.routing.allocation.total_shards_per_node (Standardwert ist 1000) gesteuert. Es ist ratsam, die tatsächliche Shard-Anzahl deutlich unter diesem Limit zu halten.

Best Practices für die Shard-Zuweisung

1. Streben Sie eine Ziel-Shard-Größe an

Obwohl es keine magische Zahl gibt, liegt eine häufig empfohlene Ziel-Shard-Größe zwischen 10 GB und 50 GB. Dieser Bereich stellt oft ein gutes Gleichgewicht dar.

Zu klein (< 10 GB): Kann zu übermäßigem Overhead führen. Jeder Shard hat einen Speicher-Footprint und trägt zur Last des Master-Knotens bei. Das Verwalten von Tausenden winzigen Shards wird zu einer erheblichen operativen Belastung.
Zu groß (> 50 GB): Kann Performance-Probleme verursachen. Das Zusammenführen von Segmenten, Wiederherstellung und Rebalancing-Operationen dauern länger. Wenn ein großer Shard ausfällt, kann die Wiederherstellung eine beträchtliche Zeit in Anspruch nehmen.

2. Zeitbasierte Indizes berücksichtigen

Für Zeitreihendaten (Logs, Metriken, Ereignisse) ist die Verwendung von zeitbasierten Indizes eine gängige und hochwirksame Praxis. Dabei werden neue Indizes für bestimmte Zeiträume erstellt (z. B. täglich, wöchentlich, monatlich).

Beispiel: Anstelle eines riesigen Indexes könnten Sie logs-2023.10.26, logs-2023.10.27 usw. haben.
Vorteile: Einfachere Datenverwaltung (Löschen alter Indizes über Index Lifecycle Management - ILM), bessere Performance, da Abfragen oft auf aktuelle Daten abzielen, und kontrollierte Shard-Größen.

3. Index Lifecycle Management (ILM) implementieren

ILM-Richtlinien ermöglichen es Ihnen, das Index-Management basierend auf Alter, Größe oder Dokumentenanzahl zu automatisieren. Sie können Phasen für einen Index (Hot, Warm, Cold, Delete) definieren und Aktionen für jede Phase festlegen, einschließlich des Änderns der Anzahl der Replicas, des Schrumpfens von Indizes oder deren Löschung.

Hot-Phase: Index wird aktiv beschrieben und abgefragt. Maximale Performance.
Warm-Phase: Index wird nicht mehr beschrieben, aber immer noch abgefragt. Kann auf weniger performante Hardware verschoben werden, potenziell mit weniger Replicas oder geschrumpft.
Cold-Phase: Selten abgefragt. Daten können auf günstigere Speichermedien verschoben werden, mit noch weniger Replicas oder eingefroren.
Delete-Phase: Daten werden nicht mehr benötigt und gelöscht.

4. Over-Sharding vermeiden

Over-Sharding tritt auf, wenn Sie viel zu viele Shards für Ihre Cluster-Größe und Ihr Datenvolumen haben. Dies ist eine häufige Falle, die zu schlechter Performance und Management-Problemen führt.

Symptome: Hohe CPU-Auslastung auf Master-Knoten, langsame Cluster-Status-Updates, lange Wiederherstellungszeiten und allgemeine Trägheit.
Minderung: Planen Sie Ihre primäre Shard-Anzahl von Anfang an. Für zeitbasierte Indizes beginnen Sie mit einer angemessenen Anzahl von primären Shards pro Index (z. B. 1 oder 3). Sie können später jederzeit Replicas hinzufügen.

5. Nicht über-indizieren

Vermeiden Sie es auch, unnötig viele Indizes zu erstellen. Jeder Index fügt Overhead hinzu. Für nicht-zeitreihenbasierte Daten, bei denen Sie keinen natürlichen Partitionierungsmechanismus haben, überlegen Sie, ob ein einzelner Index mit einer geeigneten Shard-Anzahl ausreichend ist.

6. Die `number_of_shards`-Einstellung berücksichtigen

Beim Erstellen eines Indexes definiert der Parameter number_of_shards die Anzahl der primären Shards. Diese Einstellung ist nach der Indexerstellung unveränderlich.

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // Beispiel: 3 primäre Shards
      "number_of_replicas": 1   // Beispiel: 1 Replica Shard
    }
  }
}

Tipp: Für kleinere Indizes oder solche mit sehr geringer Indizierungs-/Abfragelast kann ein einzelner primärer Shard ausreichen. Für größere, aktivere Indizes können 3 oder 5 primäre Shards eine bessere Verteilung und Ausfallsicherheit bieten, insbesondere wenn Sie planen, den Index später aufzuteilen (obwohl das Aufteilen komplex ist).

7. Rebalancing und Relocation

Elasticsearch balanciert Shards automatisch neu, um eine gleichmäßige Verteilung über die Knoten hinweg zu gewährleisten. Wenn Shards jedoch zu groß sind, können diese Operationen ressourcenintensiv und langsam sein. Kleinere, zahlreichere Shards können manchmal schneller neu balanciert werden, aber dies wird durch den Overhead der Verwaltung weiterer Shards konterkariert.

8. Tuning der Abfrage-Performance

Wenn Ihre Abfrage-Performance leidet, bewerten Sie Ihre Shard-Strategie. Berücksichtigen Sie:

Anzahl der Shards: Zu viele Shards können den Koordinations-Overhead erhöhen.
Shard-Größe: Sehr große Shards können das Zusammenführen von Segmenten und das Suchen innerhalb des Shards verlangsamen.
Index-Design: Verwenden Sie geeignete Mappings und Analyzer?

Berechnung Ihrer optimalen Shard-Anzahl

Es gibt keine einzelne Formel, aber hier ist ein gängiger Ansatz:

Schätzen Sie Ihr gesamtes Datenvolumen pro Index über dessen Lebenszyklus.
Bestimmen Sie Ihre Ziel-Shard-Größe (z. B. 30 GB).
Berechnen Sie die benötigte Anzahl primärer Shards: Gesamtdatenvolumen / Ziel-Shard-Größe.
Runden Sie auf die nächste ganze Zahl auf. Dies ergibt Ihre number_of_shards für den Index.
- Beispiel: Wenn Sie 90 GB Daten erwarten und 30 GB Shards anstreben, benötigen Sie 90 GB / 30 GB = 3 primäre Shards.
Berücksichtigen Sie Ausfallsicherheit und Verteilung: Für kritische Indizes sollten Sie 3 oder 5 primäre Shards in Betracht ziehen, um eine bessere Verteilung und Wiederherstellungsoptionen zu ermöglichen, auch wenn Ihr anfängliches Datenvolumen dies nicht unbedingt erfordert. Der Kompromiss ist ein erhöhter Overhead.
Beginnen Sie konservativ: Es ist im Allgemeinen einfacher, Replicas hinzuzufügen, als die Anzahl der primären Shards zu ändern (was normalerweise ein Reindexing oder komplexe Workarounds erfordert). Wenn Sie unsicher sind, beginnen Sie mit weniger primären Shards und überwachen Sie die Performance.

Beispiel-Szenario: Log-Analyse

Nehmen wir an, Sie indizieren Anwendungs-Logs:

Datenvolumen: Sie erwarten 1 TB Logs pro Monat.
Datenaufbewahrung: Sie bewahren Logs für 30 Tage auf.
Ziel-Shard-Größe: Sie streben 20 GB an.
Tägliche Indizes: Sie erstellen tägliche Indizes (logstash-JJJJ.MM.TT). Jeder tägliche Index wird ungefähr 1 TB / 30 Tage ≈ 33 GB Daten enthalten.
Primäre Shards pro Index: Angesichts des 20 GB Ziels und des täglichen Volumens von 33 GB könnten Sie 2 primäre Shards pro Index wählen (33 GB / 20 GB ≈ 1,65, aufgerundet auf 2). Dies stellt sicher, dass einzelne Shards innerhalb Ihrer Zielgröße bleiben.
Replicas: Sie entscheiden sich für 1 Replikat für hohe Verfügbarkeit.
Gesamtzahl der Shards: Über den 30-tägigen Aufbewahrungszeitraum hinweg haben Sie 30 Indizes, jeder mit 2 primären und 2 Replica Shards, was insgesamt 60 primäre und 60 Replica Shards bedeutet, die jederzeit aktiv sind.

Dieser Ansatz hält einzelne Shards überschaubar und ermöglicht ein effizientes Löschen von Daten, indem einfach alte Indizes gelöscht werden.

Fazit

Die optimale Shard-Größe in Elasticsearch ist ein kontinuierliches Balanceakt. Durch das Verständnis des Zusammenspiels von Shard-Anzahl, Shard-Größe, Indizierungslast, Abfragemustern und Cluster-Ressourcen können Sie fundierte Entscheidungen treffen. Priorisieren Sie zeitbasierte Indizes für Zeitreihendaten, nutzen Sie ILM für die automatisierte Verwaltung und behalten Sie stets den operativen Overhead der Shard-Verwaltung im Auge. Eine Zielgröße von 10 GB bis 50 GB für Shards, während Over-Sharding vermieden wird, ist ein solider Ausgangspunkt. Regelmäßiges Monitoring und Performance-Tuning stellen sicher, dass Ihr Elasticsearch-Cluster effizient, skalierbar und widerstandsfähig bleibt, während Ihre Daten wachsen.