Tutorial 2.3: Elasticsearch – Was sind Shards? (Skalierung verstehen)

Nov. 12, 2025

0 221

Dauer: 15 Minuten
Schwierigkeit: Anfänger (Konzept)
Voraussetzungen: Tutorial 2.1 + 2.2 abgeschlossen

Was du am Ende dieses Tutorials verstanden hast

✅ Was ein Shard ist (bildlich und technisch)
✅ Warum Elasticsearch Shards braucht
✅ Wie Daten auf Shards verteilt werden
✅ Wie viele Shards du für verschiedene Szenarien brauchst
✅ Warum die Shard-Anzahl nicht änderbar ist

Hinweis: Dies ist ein reines Konzept-Tutorial. Wir erstellen noch keine Indizes – das kommt in Tutorial 2.5!

Das Problem ohne Shards

Szenario: Ein großer Online-Shop

Stell dir vor:

Du betreibst einen Online-Shop wie Amazon
Du hast 100 Millionen Produkte in deiner Datenbank
Jedes Produkt ist ca. 5 KB groß
Gesamt: 500 GB Daten!

Problem 1: Speicherplatz

┌─────────────────────────────────┐
│  Ein einzelner Server           │
│                                 │
│  Muss 500 GB speichern          │
│                                 │
│  Festplatte voll!               │
│  Sehr teurer Server nötig       │
└─────────────────────────────────┘

Lösung würde sein:

Einen noch größeren Server kaufen (Vertikal skalieren)
Sehr teuer!
Irgendwann nicht mehr möglich

Problem 2: Geschwindigkeit

Kundenanfrage: "Suche rotes Kleid"

┌─────────────────────────────────────────┐
│  Ein Server muss durchsuchen:           │
│                                         │
│  100.000.000 Produkte                   │
│                                         │
│  Dauer: 2 Minuten                       │
│                                         │
│  Kunde wartet... und geht!              │
└─────────────────────────────────────────┘

Kunde ist weg → Kein Verkauf!

Die Lösung: Sharding

Das Prinzip: „Teile und herrsche“

Shard kommt aus dem Englischen und bedeutet „Scherbe“ oder „Splitter“.

Stell dir vor, du zerbrichst einen großen Spiegel in mehrere Teile:


Jedes Stück = 1 Shard

Visualisierung: Sharding in Aktion

Ohne Sharding

┌───────────────────────────────────────────────┐
│           Index: "products"                   │
│                                               │
│   📦 100 Millionen Produkte (500 GB)          │
│                                               │
│   Liegt komplett auf einem Server             │
└───────────────────────────────────────────────┘
                      ↓
         ┌────────────────────────┐
         │     Server 1           │
         │     💾 500 GB          │
         │     🐌 Langsam         │
         └────────────────────────┘

Mit Sharding (5 Shards)

┌───────────────────────────────────────────────┐
│           Index: "products"                   │
│                                               │
│   📦 100 Millionen Produkte (500 GB)          │
│                                               │
│   Aufgeteilt in 5 Shards                      │
└───────────────────────────────────────────────┘
                      ↓
    ┌─────────┬─────────┬─────────┬─────────┬
    │         │         │         │         │        
    ↓         ↓         ↓         ↓         ↓
┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐
│Shard 0 ││Shard 1 ││Shard 2 ││Shard 3 ││Shard 4 │
│        ││        ││        ││        ││        │
│20 Mio  ││20 Mio  ││20 Mio  ││20 Mio  ││20 Mio  │
│Produkte││Produkte││Produkte││Produkte││Produkte│
│        ││        ││        ││        ││        │
│100 GB  ││100 GB  ││100 GB  ││100 GB  ││100 GB  │
└────────┘└────────┘└────────┘└────────┘└────────┘
    │         │         │         │         │
    ↓         ↓         ↓         ↓         ↓
┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐
│Server 1││Server 2││Server 3││Server 4││Server 5│
└────────┘└────────┘└────────┘└────────┘└────────┘

Vorteile auf einen Blick:

✅ 5 kleinere Server statt 1 großer (günstiger!)
✅ Jeder Server nur 100 GB (handhabbar)
✅ 5 Server suchen parallel (5x schneller!)

Wie werden Dokumente auf Shards verteilt?

Der Hash-Algorithmus

Elasticsearch nutzt einen Hash-Algorithmus um zu entscheiden, in welchen Shard ein Dokument kommt.

Dokument mit ID "prod-12345"
         ↓
    [Hash-Funktion]
         ↓
    Hash-Wert: 8374628374
         ↓
    [Modulo Anzahl Shards]
    8374628374 % 5 = 4
         ↓
    Dokument landet in Shard 4

Praktisches Beispiel

Du hast 5 Shards und fügst Produkte hinzu:

json

PUT /products/_doc/laptop-001    → Hash → landet in Shard 2
PUT /products/_doc/phone-042     → Hash → landet in Shard 0
PUT /products/_doc/chair-199     → Hash → landet in Shard 4
PUT /products/_doc/book-501      → Hash → landet in Shard 1
PUT /products/_doc/mouse-007     → Hash → landet in Shard 3

Wichtig:

Verteilung ist deterministisch (gleiche ID → immer gleicher Shard)
Verteilung ist gleichmäßig (ungefähr gleich viele Docs pro Shard)
Du hast keine Kontrolle darüber (automatisch!)

⚡ Vorteil 1: Horizontale Skalierung

Was bedeutet „horizontal skalieren“?

Vertikal skalieren (traditionell):

Alter Server         Neuer Server
┌─────────┐          ┌─────────┐
│ 4 GB RAM│   →      │16 GB RAM│
│ 2 Cores │          │ 8 Cores │
│ 100 GB  │          │ 500 GB  │
└─────────┘          └─────────┘
      ↑
  TEURER!

Horizontal skalieren (mit Sharding):

Ein Server          Fünf Server
┌─────────┐         ┌───┐┌───┐┌───┐┌───┐┌───┐
│ 4 GB RAM│   →     │ 4 ││ 4 ││ 4 ││ 4 ││ 4 │
│ 2 Cores │         │GB ││GB ││GB ││GB ││GB │
│ 500 GB  │         └───┘└───┘└───┘└───┘└───┘
└─────────┘              ↑
                    GÜNSTIGER!
                    (Commodity Hardware)

Beispiel: Wachsende Datenmengen

Monat 1:

10 GB Daten
┌──────────┐
│ 1 Shard  │  auf 1 Server
└──────────┘

Monat 6:

100 GB Daten
┌──────────┬──────────┬──────────┐
│ Shard 0  │ Shard 1  │ Shard 2  │
└──────────┴──────────┴──────────┘
  Server 1   Server 2   Server 3

Monat 12:

500 GB Daten
┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┐
│ S0 │ S1 │ S2 │ S3 │ S4 │ S5 │ S6 │ S7 │ S8 │ S9 │
└────┴────┴────┴────┴────┴────┴────┴────┴────┴────┘
 Srv1 Srv2 Srv3 Srv4 Srv5 Srv6 Srv7 Srv8 Srv9 Srv10

Einfach mehr Server hinzufügen!

Vorteil 2: Parallele Verarbeitung

Such-Performance

Kundenanfrage: "Suche rotes Kleid"

OHNE Sharding (1 Shard):
┌─────────────────────────────────┐
│ Server 1                        │
│                                 │
│ Durchsucht:                     │
│ 📦 100 Millionen Produkte       │
│                                 │
│ ⏱️  Dauer: 10 Sekunden          │
└─────────────────────────────────┘

MIT Sharding (5 Shards):
┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
│Server 1 │  │Server 2 │  │Server 3 │  │Server 4 │  │Server 5 │
│         │  │         │  │         │  │         │  │         │
│Sucht in:│  │Sucht in:│  │Sucht in:│  │Sucht in:│  │Sucht in:│
│20 Mio   │  │20 Mio   │  │20 Mio   │  │20 Mio   │  │20 Mio   │
│Produkte │  │Produkte │  │Produkte │  │Produkte │  │Produkte │
│         │  │         │  │         │  │         │  │         │
│⏱️ 2 Sek │  │⏱️ 2 Sek │  │⏱️ 2 Sek │  │⏱️ 2 Sek │  │⏱️ 2 Sek │
└─────────┘  └─────────┘  └─────────┘  └─────────┘  └─────────┘
      │            │            │            │            │
      └────────────┴────────────┴────────────┴────────────┘
                              ↓
                    Elasticsearch sammelt
                    und kombiniert Ergebnisse
                              ↓
                      ⏱️ Gesamt: 2 Sekunden
                          (5x schneller!)

Parallel = Schneller! ⚡

Indexierungs-Performance

Auch beim Hinzufügen von Dokumenten hilft Sharding:

Du möchtest 1 Million neue Produkte indexieren

OHNE Sharding:
┌─────────────────────────────────┐
│ Server 1                        │
│ Muss 1 Million Docs verarbeiten │
│ ⏱️  Dauer: 60 Minuten           │
└─────────────────────────────────┘

MIT Sharding (5 Shards):
┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
│Server 1 │  │Server 2 │  │Server 3 │  │Server 4 │  │Server 5 │
│200k     │  │200k     │  │200k     │  │200k     │  │200k     │
│Docs     │  │Docs     │  │Docs     │  │Docs     │  │Docs     │
│         │  │         │  │         │  │         │  │         │
│⏱️ 12 Min│  │⏱️ 12 Min│  │⏱️ 12 Min│  │⏱️ 12 Min│  │⏱️ 12 Min│
└─────────┘  └─────────┘  └─────────┘  └─────────┘  └─────────┘

Gesamt: 12 Minuten (5x schneller!)

Wie viele Shards brauche ich?

Die Faustregel

Index-Größe	Empfohlene Shards
< 10 GB	1 Shard
10-50 GB	2-3 Shards
50-200 GB	5 Shards
> 200 GB	10+ Shards

Shard-Größe als Richtlinie

Best Practice:

Ideal: 10-50 GB pro Shard
Maximum: 50-100 GB pro Shard

Beispiel-Rechnung:

Du hast 300 GB Daten:

300 GB ÷ 30 GB pro Shard = 10 Shards

Empfehlung: 10 Shards

Du hast 50 GB Daten:

50 GB ÷ 30 GB pro Shard = 1,6 Shards

Empfehlung: 2 Shards

Zu viele Shards = Schlecht!

Overhead: Jeder Shard hat Verwaltungsaufwand

Szenario: 1 GB Daten, 100 Shards

┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐  ... (100 Shards!)
│ ││ ││ ││ ││ ││ ││ ││ ││ ││ │
└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘

Jeder Shard: 10 MB Daten ❌

Probleme:
- Zu viele Metadaten zu verwalten
- Mehr Overhead als Nutzen
- Langsamer statt schneller!

Regel: Nicht mehr Shards als nötig!

WICHTIG: Shards sind nicht änderbar!

Das größte „Gotcha“ bei Shards

Du erstellst einen Index:
PUT /products
{
  "settings": {
    "number_of_shards": 1    ← ACHTUNG!
  }
}

Später stellst du fest: 1 Shard ist zu wenig!

Du versuchst zu ändern:
PUT /products/_settings
{
  "number_of_shards": 5     ← GEHT NICHT! ❌
}

Fehler:
"Can't update non dynamic settings 
 [number_of_shards] for open indices"

Warum nicht änderbar?

Technischer Grund:

Dokument-ID → Hash → Shard-Nummer

Bei 3 Shards:
- ID "prod-123" → Hash → Shard 1

Wenn du auf 5 Shards änderst:
- ID "prod-123" → Hash → Shard 3 (!)

Dokument müsste umziehen!
ALLE Dokumente müssten neu verteilt werden!

Elasticsearch erlaubt das nicht, weil:

Zu kompliziert
Zu fehleranfällig
Zu langsam bei großen Indizes

Was wenn ich die Anzahl ändern muss?

Lösung: Reindexing

1. Neuen Index mit mehr Shards erstellen:
   PUT /products-v2
   {
     "settings": {
       "number_of_shards": 5
     }
   }

2. Alle Daten kopieren:
   POST /_reindex
   {
     "source": { "index": "products" },
     "dest": { "index": "products-v2" }
   }

3. Alten Index löschen:
   DELETE /products

4. Alias auf neuen Index setzen:
   PUT /products-v2/_alias/products

Lernen wir später im Detail!

Praxis-Tipps für die Shard-Anzahl

Tipp 1: Lieber zu wenig als zu viel

Unsicher zwischen 3 und 5 Shards?

Wähle 3! ✅

Gründe:
- Weniger Overhead
- Einfacher zu verwalten
- Bei Bedarf: Reindexing zu mehr Shards möglich

Tipp 2: Wachstum einplanen

Heute: 20 GB Daten
In 1 Jahr: ~100 GB erwartet

Berechnung:
100 GB ÷ 30 GB pro Shard = 3,3 Shards

Wähle: 5 Shards ✅ (Puffer eingebaut)

Tipp 3: Zeit-basierte Indizes

Für Logs, Events, Time-Series-Daten:

Statt:
logs (1 Index, 50 Shards für 5 Jahre Daten)

Besser:
logs-2024-01 (5 Shards für Januar)
logs-2024-02 (5 Shards für Februar)
logs-2024-03 (5 Shards für März)
...

Vorteile:
- Alte Indizes können gelöscht werden
- Flexibel: Jeden Monat neu entscheiden
- Bessere Performance

Lernen wir in Advanced-Tutorials!

Vergleich: Unterschiedliche Shard-Strategien

Szenario: 100 GB Daten

Option A: 1 Shard

Vorteile:
✅ Einfach
✅ Wenig Overhead

Nachteile:
❌ Nicht skalierbar
❌ Langsam bei Wachstum
❌ Stuck auf 1 Server

Empfehlung: Nur für kleine Datenmengen (< 10 GB)

Option B: 5 Shards

Vorteile:
✅ Gute Balance
✅ Skalierbar auf 5 Server
✅ 5x parallele Verarbeitung

Nachteile:
⚠️ Etwas mehr Overhead

Empfehlung: Gut für 50-250 GB ✅

Option C: 50 Shards

Vorteile:
✅ Maximal parallel

Nachteile:
❌ VIEL zu viele Shards!
❌ Hoher Overhead
❌ Langsamer als 5 Shards!

Empfehlung: Nur bei Multi-TB-Datenmengen

Praktische Übung (Gedankenexperiment)

Aufgabe 1: Wie viele Shards?

Für jeden Szenario: Wie viele Shards würdest du wählen?

Szenario A:

Blog mit 5.000 Artikeln
Aktuell: 500 MB Daten
Wachstum: +100 Artikel/Monat

1 Shard

Begründung:

Sehr kleine Datenmenge
Auch in 2 Jahren nur ~3 GB
Kein Skalierungsbedarf
Overhead von mehreren Shards nicht nötig

</details>

Szenario B:

E-Commerce mit 500.000 Produkten
Aktuell: 80 GB Daten
Wachstum: +50.000 Produkte/Jahr

3-5 Shards

Begründung:

Mittlere Datenmenge
Wachstum auf ~120 GB in 2 Jahren
3 Shards: ~40 GB/Shard (gut)
5 Shards: ~24 GB/Shard (auch gut)
Empfehlung: 5 Shards (Puffer für Wachstum)

</details>

Szenario C:

Log-System von 1000 Servern
Aktuell: 2 TB Daten
Wachstum: +100 GB/Tag

20-30 Shards (oder besser: Zeit-basierte Indizes!)

Begründung:

Sehr große Datenmenge
2 TB ÷ 30 GB = ~66 Shards theoretisch
Aber: Besser zeit-basiert!
- logs-2024-11-12 (5 Shards)
- logs-2024-11-13 (5 Shards)
- Alte Logs nach 30 Tagen löschen
Flexibler und performanter

</details>

Konzept-Check

Fragen zum Verständnis

Was ist ein Shard? <details> <summary>Antwort</summary> Ein Teil/Stück eines Index. Teilt große Datenmengen auf mehrere Server auf für Skalierung und Performance. </details>

Warum sind Shards wichtig? <details> <summary>Antwort</summary> – Horizontale Skalierung (mehr Server statt größere Server) – Parallele Verarbeitung (schnellere Suchen) – Große Datenmengen handhabbar machen </details>

Wie werden Dokumente auf Shards verteilt? <details> <summary>Antwort</summary> Über einen Hash-Algorithmus basierend auf der Dokument-ID. Automatisch und gleichmäßig. </details>

Kann ich die Anzahl Shards später ändern? <details> <summary>Antwort</summary> Nein, nicht direkt. Nur durch Reindexing (alle Daten in neuen Index kopieren). </details>

Wie viele Shards für 5 GB Daten? <details> <summary>Antwort</summary> 1 Shard reicht völlig. Kleine Datenmenge braucht keine Aufteilung. </details>

Zusammenfassung

Was du gelernt hast:

✅ Shard = Teil eines Index (wie Splitter eines Spiegels)
✅ Zweck: Große Datenmengen aufteilen (Skalierung)
✅ Vorteil 1: Horizontal skalieren (mehr günstige Server)
✅ Vorteil 2: Parallele Verarbeitung (schneller)
✅ Hash-Algorithmus verteilt Dokumente automatisch
✅ Faustregel: 10-50 GB pro Shard ideal
✅ WICHTIG: Anzahl nicht änderbar nach Erstellung!
✅ Start-Empfehlung: Lieber weniger Shards, bei Bedarf reindexen

Praktische Richtlinien:

< 10 GB     → 1 Shard
10-50 GB    → 2-3 Shards
50-200 GB   → 5-10 Shards
> 200 GB    → 10+ Shards

Ziel: 10-50 GB pro Shard

Wichtigste Regel:

⚠️ Überlege gut BEVOR du den Index erstellst!
   Die Shard-Anzahl kannst du nicht mehr ändern!

Author: Andreas Lang

Sphinx-Flashdesign.de

Andreas Lang konzentriert sich seit zwei Jahrzehnten auf die Webentwicklung und Webdesign mit dem Schwerpunkt PHP, Laravel und Javascript und betreut seine Kunden mit Herz und Seele in allen Bereichen von Entwicklung, Design, Suchmaschinenoptimierung, IT-Recht, IT-Sicherheit etc.

Weiter