Shard-Sizing: die richtige Anzahl fuer den eigenen Index finden

1. Warum Shard-Sizing kein Konfigurationsdetail ist

Ein Shard ist die kleinste Einheit, die Elasticsearch physisch verteilen und parallel verarbeiten kann, technisch ein eigener Lucene-Index. Die Anzahl der Primary Shards wird beim Anlegen eines Index festgelegt und laesst sich danach nicht mehr direkt aendern, ohne den Index neu aufzubauen. Genau deshalb ist Shard-Sizing eine der wenigen Elasticsearch-Entscheidungen, die man nicht einfach per Konfigurationsaenderung korrigieren kann, wenn sie sich als falsch herausstellt.

Viele Teams uebernehmen den Elasticsearch-Standardwert von einem Primary Shard pro Index oder setzen aus Vorsicht eine hohe Zahl wie zehn oder zwanzig Shards, ohne die tatsaechliche Datenmenge zu kennen. Beide Extreme fuehren zu Problemen: zu wenige Shards verhindern Parallelisierung bei grossen Datenmengen, zu viele Shards erzeugen Verwaltungsaufwand, der sich direkt im Cluster-State und im Heap-Verbrauch der Master-Nodes niederschlaegt. Gutes Shard-Sizing balanciert beides gegen die tatsaechliche Datenmenge und das Wachstum des Index.

Die Faustregel fuer Shard-Sizing lautet nicht "mehr Shards gleich mehr Performance", sondern orientiert sich an einer Zielgroesse pro Shard und der Anzahl verfuegbarer Data-Nodes. Ein Shard, der nie ueber wenige hundert Megabyte hinauswaechst, verschwendet Overhead. Ein Shard, der zweihundert Gigabyte erreicht, wird zum Flaschenhals bei Recovery und Rebalancing.

2. Die Oversharding-Falle: viele kleine Shards

Oversharding entsteht meist schleichend: ein taeglicher Index fuer Logdaten wird mit fuenf Primary Shards angelegt, weil das in einer alten Dokumentation stand, tatsaechlich fallen aber nur zwei Gigabyte Daten pro Tag an. Nach einem Jahr existieren dreihundertfuenfundsechzig Indizes mit je fuenf Shards, macht ueber achtzehnhundert Shards fuer eine Datenmenge, die mit hundert gut bedienten Shards auskaeme. Jeder dieser Shards kostet Cluster-State-Metadaten, offene Dateihandles und einen eigenen Lucene-Segment-Merge-Zyklus.

Die Konsequenzen von Oversharding zeigen sich zuerst auf den Master-Nodes: der Cluster-State waechst mit jeder Shard-Zuteilung, seine Publikation an alle Nodes wird langsamer, und bei einem Node-Neustart dauert die Shard-Zuteilung deutlich laenger. Auf Suchseite verschlechtert sich die Latenz, weil jede Suchanfrage an alle relevanten Shards geschickt und deren Ergebnisse zusammengefuehrt werden muessen, selbst wenn ein einzelner Shard nur wenige Dokumente enthaelt. Bei zu aggressivem Shard-Sizing nach oben zahlt man diesen Koordinationsaufwand fuer praktisch keinen Parallelisierungsgewinn.

3. Die Zielgroesse pro Shard: zwischen 10 und 50 GB

Als praktische Richtgroesse fuer Shard-Sizing hat sich ein Zielbereich von zehn bis fuenfzig Gigabyte pro Shard etabliert, fuer die meisten allgemeinen Anwendungsfaelle mit Text- und Log-Daten. Innerhalb dieses Bereichs bleibt ein Shard klein genug, um sich in vertretbarer Zeit neu zuzuteilen oder wiederherzustellen, und gross genug, um den Overhead pro Shard gegenueber dem eigentlichen Datenvolumen klein zu halten. Fuer zeitbasierte Log-Indizes mit ILM ist dieselbe Regel der Ausgangspunkt fuer das Rollover-Kriterium.

Die genaue Zahl innerhalb dieses Bereichs haengt vom Anwendungsfall ab: Volltextsuche mit vielen Aggregationen profitiert eher von kleineren Shards um zwanzig Gigabyte, weil Aggregationsarbeit gut parallelisiert, waehrend reine Log-Speicherung mit seltenen, einfachen Abfragen auch mit fuenfzig Gigabyte pro Shard gut funktioniert. Wichtig ist, diesen Wert nicht einmalig zu setzen und zu vergessen, sondern regelmaessig gegen das tatsaechliche Datenwachstum zu pruefen, besonders bei Indizes, die kontinuierlich wachsen statt zeitbasiert zu rotieren.

4. Primary- und Replica-Shards richtig einordnen

Primary Shards sind die Menge, ueber die sich das Shard-Sizing definiert, sie enthalten die Originaldaten und werden beim Indexanlegen fixiert. Replica Shards sind vollstaendige Kopien der Primary Shards auf anderen Nodes, sie dienen der Ausfallsicherheit und erhoehen zusaetzlich den Lesethroughput, weil Suchanfragen auch gegen Replicas beantwortet werden koennen. Die Anzahl der Replicas kann jederzeit ohne Reindex geaendert werden, im Gegensatz zur Primary-Shard-Anzahl.

Ein haeufiges Missverstaendnis: Replicas zaehlen fuer die Kapazitaetsplanung genauso wie Primaries, ein Index mit fuenf Primary Shards und einem Replica belegt zehn Shard-Slots im Cluster. Beim Shard-Sizing sollte deshalb immer die Gesamtzahl inklusive Replicas betrachtet werden, nicht nur die Primary-Anzahl, da sie genauso Speicherplatz, Heap und Dateihandles auf den Data-Nodes beansprucht.

PUT /orders-2026.07
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "order_id": { "type": "keyword" },
      "customer_email": { "type": "keyword" },
      "created_at": { "type": "date" },
      "total_amount": { "type": "scaled_float", "scaling_factor": 100 }
    }
  }
}

// 3 primary shards + 1 replica each = 6 shard slots total across the cluster

5. Shard-Anzahl vorab berechnen

Fuer neue Indizes laesst sich die passende Primary-Shard-Anzahl vorab schaetzen, wenn das erwartete Datenvolumen bekannt ist: erwartete Gesamtgroesse des Index geteilt durch die Zielgroesse pro Shard, aufgerundet auf eine praktikable Zahl. Ein Index, der voraussichtlich zweihundert Gigabyte erreicht, mit einer Zielgroesse von vierzig Gigabyte pro Shard, braucht rechnerisch fuenf Primary Shards. Diese Rechnung ist eine Naeherung, kein exakter Wert, weil Datenwachstum selten linear verlaeuft.

Fuer Indizes mit unsicherer Wachstumsprognose ist es beim Shard-Sizing meist sicherer, mit einer etwas kleineren Shard-Anzahl zu starten und bei Bedarf per Split-API zu vergroessern, als von Anfang an ueberdimensioniert zu planen. Der Grund: leere oder kaum gefuellte Shards verursachen denselben Verwaltungsoverhead wie volle Shards, ein zu grosszuegig geschaetzter Index bindet also von Tag eins an unnoetige Ressourcen im Cluster.

GET _cat/shards/orders-2026.07?v&h=index,shard,prirep,state,docs,store

// Store column shows actual size on disk per shard, compare against target
index            shard prirep state   docs      store
orders-2026.07   0     p      STARTED  4823012   38.2gb
orders-2026.07   0     r      STARTED  4823012   38.2gb
orders-2026.07   1     p      STARTED  4801556   37.9gb
orders-2026.07   1     r      STARTED  4801556   37.9gb
orders-2026.07   2     p      STARTED  4790112   37.6gb
orders-2026.07   2     r      STARTED  4790112   37.6gb

6. Undersharding: wenn Shards zu gross werden

Das Gegenteil von Oversharding ist ebenso problematisch: ein einzelner Primary Shard, der auf zweihundert oder mehr Gigabyte anwaechst, wird zum Flaschenhals. Recovery nach einem Node-Ausfall dauert proportional zur Shard-Groesse, weil der komplette Shard von einem anderen Node kopiert werden muss, bevor er wieder verfuegbar ist. Waehrend dieser Recovery-Phase steht weniger Redundanz zur Verfuegung, was das Risiko eines Datenverlusts bei einem zweiten Ausfall erhoeht.

Auch die Schreiblast leidet unter zu grossen Shards: Segment-Merges auf einem sehr grossen Shard binden mehr I/O und CPU auf einmal, was zu spuerbaren Latenzspitzen bei der Indexierung fuehrt. Richtiges Shard-Sizing bedeutet deshalb nicht nur, Oversharding zu vermeiden, sondern ebenso zu verhindern, dass ein Index durch organisches Wachstum ueber die empfohlene Obergrenze hinauswaechst, ohne dass jemand eingreift.

7. Resharding ohne Downtime per Reindex-API

Da die Primary-Shard-Anzahl nach dem Anlegen fixiert ist, fuehrt der klassische Weg zur Korrektur eines falschen Shard-Sizings ueber die Reindex-API: ein neuer Index mit korrigierter Shard-Anzahl wird angelegt, alle Dokumente werden per _reindex vom alten in den neuen Index kopiert, und ein Alias wird anschliessend umgehaengt. Solange Schreibzugriffe ueber einen Alias statt direkt auf den Indexnamen erfolgen, laeuft dieser Wechsel ohne Downtime fuer lesende und schreibende Clients.

Bei laufendem Schreibbetrieb waehrend des Reindex ist ein zweistufiges Vorgehen noetig: zuerst der initiale Reindex des historischen Bestands, danach ein zweiter, inkrementeller Reindex-Lauf mit einem Zeitfilter auf neu geschriebene Dokumente, bevor der Alias final umgeschaltet wird. Dieses Muster ist Standard bei jedem groesseren Shard-Sizing-Umbau produktiver Indizes.

// Step 1: create the new index with corrected shard count
PUT /orders-2026.07-v2
{
  "settings": { "number_of_shards": 5, "number_of_replicas": 1 }
}

// Step 2: copy all existing documents into the new index
POST /_reindex?wait_for_completion=false
{
  "source": { "index": "orders-2026.07" },
  "dest": { "index": "orders-2026.07-v2" }
}

// Step 3: atomically swap the alias, zero downtime for clients
POST /_aliases
{
  "actions": [
    { "remove": { "index": "orders-2026.07", "alias": "orders-current" } },
    { "add": { "index": "orders-2026.07-v2", "alias": "orders-current" } }
  ]
}

8. Split- und Shrink-API als Alternative

Fuer den Sonderfall Undersharding bietet Elasticsearch die Split-API: sie teilt einen bestehenden Index in mehr Shards auf, ohne dass Dokumente manuell umkopiert werden muessen, vorausgesetzt die Ziel-Shard-Anzahl ist ein Vielfaches der urspruenglichen Anzahl. Fuer Oversharding existiert die Shrink-API in die andere Richtung, sie reduziert die Shard-Anzahl eines schreibgeschuetzten Index. Beide Operationen sind schneller als eine vollstaendige Reindex-Operation, weil sie auf Lucene-Segment-Ebene arbeiten statt Dokument fuer Dokument neu zu schreiben.

Die Einschraenkung beider APIs: der Quellindex muss vorher auf read-only gesetzt werden, was fuer aktiv beschriebene Produktionsindizes meist nur bei zeitbasierten, bereits abgeschlossenen Indizes praktikabel ist. Fuer aktuell beschriebene Indizes bleibt die Reindex-API mit Alias-Umschaltung deshalb der uebliche Weg, waehrend Split und Shrink sich besonders gut in ILM-Richtlinien fuer abgeschlossene, aeltere Indizes integrieren lassen.

// Mark the source index read-only before splitting or shrinking
PUT /orders-2026.06/_settings
{
  "settings": { "index.blocks.write": true }
}

// Split into more shards, target must be a multiple of the source count
POST /orders-2026.06/_split/orders-2026.06-split
{
  "settings": { "index.number_of_shards": 6 }
}

// Shrink into fewer shards for an oversharded, closed index
POST /orders-2026.06/_shrink/orders-2026.06-shrunk
{
  "settings": { "index.number_of_shards": 1 }
}

9. Shard-Groesse laufend ueberwachen

Statisches Shard-Sizing beim Anlegen eines Index reicht nicht, wenn sich das Wachstum aendert. Die _cat/shards API mit dem Store-Feld zeigt fuer jeden Shard die aktuelle Groesse auf Disk und macht sichtbar, welche Shards sich der Obergrenze naehern oder deutlich unter dem Zielwert bleiben. Ein regelmaessiger, automatisierter Check dieser Werte, etwa woechentlich per Skript, deckt Fehlentwicklungen auf, bevor sie zum akuten Problem werden.

Fuer zeitbasierte Indizes mit ILM ist die Rollover-Bedingung max_primary_shard_size das direkte Werkzeug, um Shard-Sizing automatisch durchzusetzen: ein neuer Index wird erzeugt, sobald ein Primary Shard die konfigurierte Groesse erreicht, unabhaengig davon, wie viel Zeit dafuer vergangen ist. Das entkoppelt die Shard-Groesse von unvorhersehbaren Schwankungen im taeglichen Datenvolumen und haelt jeden einzelnen Shard zuverlaessig im Zielbereich.

PUT _ilm/policy/orders-rollover-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "40gb",
            "max_age": "30d"
          }
        }
      }
    }
  }
}

// Rollover fires on whichever condition is met first, size or age

10. Zusammenfassung

Gutes Shard-Sizing bewegt sich in einem Zielbereich von zehn bis fuenfzig Gigabyte pro Shard und wird gegen das erwartete Datenvolumen vorab grob berechnet, nicht nach Bauchgefuehl oder alten Dokumentationswerten gesetzt. Oversharding belastet Cluster-State und Master-Nodes, Undersharding verlangsamt Recovery und erzeugt Schreiblatenz-Spitzen. Da die Primary-Shard-Anzahl nach dem Anlegen fixiert ist, fuehrt der Weg zur Korrektur ueber Reindex mit Alias-Umschaltung oder ueber Split- und Shrink-APIs fuer schreibgeschuetzte Indizes.

Der nachhaltigste Ansatz ist, Shard-Sizing nicht als einmalige Entscheidung, sondern als laufend ueberwachten Parameter zu behandeln: mit max_primary_shard_size in ILM-Richtlinien fuer zeitbasierte Indizes und regelmaessigen Groessenchecks fuer alle anderen. So bleibt jeder Index innerhalb des Zielbereichs, ohne dass manuell eingegriffen werden muss, sobald das Datenvolumen waechst.

11. FAQ: Shard-Sizing in Elasticsearch