Sharding verteilt die Daten einer großen Datenbank auf mehrere Server (Shards), indem Datensätze nach einem festen Schlüssel aufgeteilt werden. Jeder Shard enthält einen Teil der Daten und bearbeitet seine Anfragen selbst – so skaliert das System horizontal, wenn eine einzelne Datenbank an ihre Grenzen stößt.
Wie funktioniert Sharding?
Eine Tabelle mit Millionen Zeilen wird über einen Shard-Key aufgeteilt. Der Shard-Key ist eine Spalte oder Kombination, die jede Zeile eindeutig einem Shard zuordnet, zum Beispiel:
shard = hash(user_id) % 4 -- 4 Shards, Verteilung über Hash
-- oder Range-Sharding:
-- user_id 1-1000000 -> Shard 1, 1000001-2000000 -> Shard 2- Hash-Sharding: Gleichmäßige Verteilung per Hash-Funktion, aber Bereichsabfragen über mehrere Shards nötig.
- Range-Sharding: Zusammenhängende Wertebereiche pro Shard – gut für zeitbasierte Daten, riskant bei Hotspots.
- Verzeichnisbasiertes Sharding: Eine Zuordnungstabelle entscheidet, welcher Shard zuständig ist – flexibel, aber ein zusätzlicher Schritt.
Vorteile
- Horizontal skalieren: Einfach weitere Server hinzufügen, statt einen immer größeren Einzelserver zu kaufen.
- Parallele Last: Anfragen verteilen sich auf viele Knoten und nutzen deren CPU, RAM und I/O gemeinsam.
- Kleinere Indizes: Jeder Shard hat nur einen Bruchteil der Daten – Indizes bleiben klein und schnell (siehe Indizes).
Herausforderungen
- Cross-Shard-Queries: JOINs über Shard-Grenzen sind langsam oder unmöglich – Schema und Abfragen müssen shard-freundlich entworfen werden.
- Transaktionen über Shards: ACID-Eigenschaften gelten nur innerhalb eines Shards; verteilte Transaktionen sind komplex (siehe ACID).
- Rebalancing: Datenmigration beim Hinzufügen eines Shards ist aufwendig (siehe Migration).
- Shard-Key-Wahl: Ein schlechter Shard-Key erzeugt Hotspots – ein Shard wird überlastet, während andere leer bleiben.
Sharding vs. Replikation
Die beiden Konzepte ergänzen sich: Replikation erzeugt Kopien für Ausfallsicherheit und Lesezugriffe, Sharding verteilt unterschiedliche Daten auf viele Knoten. Große Systeme kombinieren beides – jeder Shard wird zusätzlich repliziert.
Wann ist Sharding sinnvoll?
Erst wenn Replikation und Optimierung nicht mehr reichen: bei sehr großen Datenmengen, hoher Schreiblast oder wenn ein einzelner Server die Zielwerte für Speicher oder Durchsatz nicht mehr erreicht. Für die meisten Anwendungen bleiben SQL mit sauberen Indizes und Normalisierung der einfachere Weg.