Datenbank-Sharding – Horizontale Partitionierung

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Datenbank-Sharding:

Definition: Was ist Sharding und warum wird es benötigt?
Sharding vs. Replication: Der wichtige Unterschied
Sharding-Strategien: Range, Hash, Directory, Geo
Shard Keys: Die richtige Wahl des Schlüssels
Architekturen: Shared-Nothing, Proxy/Router
Vorteile & Nachteile: Wann lohnt sich Sharding?
Use Cases: E-Commerce, IoT, Social Media, Gaming
Challenges: Rebalancing, Cross-Shard Queries, Hotspots
FAQ: Häufige Fragen zu Sharding

1. Was ist Datenbank-Sharding?

Definition

Sharding (auch horizontale Partitionierung genannt) ist eine Datenbank-Architektur-Technik, bei der eine große Datenbank in kleinere, verwaltbare Teile – sogenannte Shards – aufgeteilt und auf mehrere Server verteilt wird. Jeder Shard enthält einen Teil der Gesamtdaten und läuft auf einem eigenen Datenbank-Server.

Im Gegensatz zur vertikalen Skalierung (mehr CPU/RAM auf einem Server) ermöglicht Sharding horizontale Skalierung – durch Hinzufügen weiterer Server kann die Datenbank-Kapazität und -Leistung nahezu unbegrenzt gesteigert werden.

Die drei Kernprinzipien von Sharding: Partitionierung (Daten aufteilen), Distribution (auf Server verteilen) und Transparenz (Anwendung sieht nur eine logische Datenbank).

Warum Sharding?

Sharding wird benötigt, wenn:

Daten zu groß: Eine einzelne Datenbank-Instanz kann die Datenmenge nicht mehr speichern
Performance-Probleme: Queries werden zu langsam, weil die Datenbank zu groß ist
Skalierungsbedarf: Vertikale Skalierung (größerer Server) ist zu teuer oder nicht mehr möglich
Geografische Verteilung: Daten sollen näher an den Benutzern gespeichert werden

2. Sharding vs. Replication

Sharding und Replication sind zwei unterschiedliche Techniken zur Skalierung von Datenbanken. Oft werden sie kombiniert.

Sharding

Daten aufteilen

Jeder Server enthält einen unterschiedlichen Teil der Daten. Zusammen bilden alle Shards die komplette Datenbank.

Horizontale Skalierung: Mehr Server = mehr Kapazität
Datenpartitionierung: Jeder Shard hat andere Daten
Write-Skalierung: Schreiblast wird verteilt
Keine Redundanz: Daten nur auf einem Shard
Komplexität: Höher (Shard Key, Rebalancing)

Replication

Daten kopieren

Jeder Server enthält eine komplette Kopie der Daten. Alle Replikate haben dieselben Daten.

Read-Skalierung: Leseanfragen werden verteilt
Hochverfügbarkeit: Fallback bei Serverausfall
Redundanz: Daten auf mehreren Servern
Einfachheit: Keine komplexe Logik nötig
Keine Write-Skalierung: Writes nur auf Primary

Kombination: Sharding + Replication

In der Praxis werden Sharding und Replication oft kombiniert:

Sharding: Daten werden auf mehrere Shards verteilt (horizontale Skalierung)
Replication: Jeder Shard hat mehrere Replikate (Hochverfügbarkeit + Read-Skalierung)
Beispiel: MongoDB Replica Sets mit Sharding, MySQL Group Replication

3. Sharding-Strategien

Es gibt verschiedene Strategien, wie Daten auf Shards verteilt werden können. Die Wahl der Strategie hängt von den Daten und den Anforderungen ab.

01

Range Sharding

Bereichsbasierte Verteilung

Daten werden basierend auf einem Wertebereich auf Shards verteilt. Jeder Shard enthält einen bestimmten Bereich.

Einfach zu implementieren
Gute Performance für Range-Queries
Vorhersagbare Datenverteilung
Risiko von Hotspots
Ungleiche Verteilung möglich

Beispiel:
Shard 1: ID 1-1.000.000
Shard 2: ID 1.000.001-2.000.000
Shard 3: ID 2.000.001-3.000.000

02

Hash Sharding

Hash-basierte Verteilung

Eine Hash-Funktion wird auf den Shard Key angewendet. Der Hash-Wert bestimmt, auf welchem Shard die Daten gespeichert werden.

Gleichmäßige Datenverteilung
Keine Hotspots
Gute Performance für Point-Queries
Schlecht für Range-Queries
Rebalancing schwierig

Beispiel:
Hash(User_ID) % Anzahl_Shards = Shard-Nummer
Hash("user123") % 4 = 2 → Shard 2

03

Directory Sharding

Lookup-Table-basiert

Ein zentrales Verzeichnis (Lookup-Table) speichert die Zuordnung zwischen Daten und Shards. Der Router fragt das Verzeichnis, wo die Daten liegen.

Maximale Flexibilität
Einfaches Rebalancing
Keine feste Zuordnung
Lookup-Table ist Single Point of Failure
Extra Latenz für Lookup

Beispiel:
Lookup-Table:
user123 → Shard 2
user456 → Shard 1
user789 → Shard 3

04

Geo Sharding

Geografische Verteilung

Daten werden basierend auf geografischen Kriterien verteilt. Jeder Shard ist in einer bestimmten Region platziert.

Niedrige Latenz für lokale Benutzer
Compliance (Datenhoheit)
Disaster Recovery
Cross-Region Queries langsam
Komplexes Rebalancing

Beispiel:
Shard EU: Europäische Benutzer
Shard US: US-Benutzer
Shard Asia: Asiatische Benutzer

Strategie	Verteilung	Vorteile	Nachteile	Einsatz
Range	Wertebereiche	Einfach, gut für Range-Queries	Hotspots möglich	Zeitserien, Logs
Hash	Hash-Funktion	Gleichmäßige Verteilung	Schlecht für Range-Queries	User-Daten, Key-Value
Directory	Lookup-Table	Flexibel, einfaches Rebalancing	Single Point of Failure	Komplexe Szenarien
Geo	Regionen	Niedrige Latenz, Compliance	Cross-Region langsam	Globale Anwendungen

4. Shard Keys – Die richtige Wahl

Der Shard Key ist das Feld (oder die Kombination von Feldern), das bestimmt, auf welchem Shard ein Datensatz gespeichert wird. Die Wahl des Shard Keys ist entscheidend für die Performance.

Kriterien für einen guten Shard Key

Hohe Kardinalität

Viele unterschiedliche Werte (z.B. User-ID, E-Mail). Vermeidet Hotspots und sorgt für gleichmäßige Verteilung.

Häufig in Queries

Der Shard Key sollte in den meisten Queries vorkommen, damit der Router direkt den richtigen Shard ansprechen kann.

Nicht änderbar

Der Shard Key sollte sich nicht ändern, da sonst Daten zwischen Shards verschoben werden müssten (teuer!).

Niedrige Kardinalität

Wenige unterschiedliche Werte (z.B. Status, Land) führen zu ungleicher Verteilung und Hotspots.

Monoton steigend

Zeitstempel oder auto-increment IDs führen dazu, dass alle Writes auf einen Shard gehen (Hotspot).

Compound Keys

Kombination mehrerer Felder (z.B. {User_ID, Timestamp}) kann Hotspots vermeiden, ist aber komplexer.

Beispiel: E-Commerce-Datenbank

Gute Shard Keys:

User_ID: Hohe Kardinalität, häufig in Queries, nicht änderbar
Order_ID: Eindeutig, häufig in Queries

Schlechte Shard Keys:

Timestamp: Monoton steigend → Hotspot
Status: Niedrige Kardinalität (nur "offen", "geschlossen") → ungleiche Verteilung

5. Sharding-Architekturen

Es gibt verschiedene Architekturen, wie Sharding implementiert werden kann.

Architektur	Beschreibung	Vorteile	Nachteile
Shared-Nothing	Jeder Shard ist unabhängig, keine gemeinsame Hardware	Maximale Skalierbarkeit, keine Single Point of Failure	Cross-Shard Queries komplex
Shared-Disk	Alle Shards teilen sich einen gemeinsamen Storage	Einfache Verwaltung, gute Konsistenz	Storage ist Bottleneck, teurer
Application-Level	Anwendung entscheidet, welcher Shard angesprochen wird	Maximale Kontrolle, keine Middleware nötig	Komplex in der Anwendung, schwer zu warten
Proxy/Router	Ein Proxy leitet Queries an den richtigen Shard weiter	Transparent für Anwendung, zentral gesteuert	Proxy ist Single Point of Failure, Latenz

Empfohlene Architektur: Proxy/Router

Die meisten modernen Sharding-Implementierungen nutzen einen Proxy oder Router:

MongoDB: Mongos (Query Router) leitet Anfragen an die richtigen Shards
MySQL: Vitess oder ProxySQL als Middleware
PostgreSQL: Citus oder Pgpool-II
Cassandra: Native Sharding-Unterstützung (kein Proxy nötig)

6. Vorteile & Nachteile von Sharding

Sharding bietet viele Vorteile, hat aber auch Herausforderungen, die berücksichtigt werden müssen.

Vorteile

Horizontale Skalierung: Mehr Server = mehr Kapazität und Performance
Write-Skalierung: Schreiblast wird auf mehrere Server verteilt
Reduzierte Latenz: Kleinere Datenbanken = schnellere Queries
Kosteneffizienz: Viele kleine Server sind günstiger als ein großer
Geografische Verteilung: Daten näher an den Benutzern
Parallelität: Mehrere Shards können parallel arbeiten

Nachteile & Herausforderungen

Komplexität: Sharding erfordert sorgfältige Planung und Implementierung
Cross-Shard Queries: Joins über mehrere Shards sind teuer und langsam
Rebalancing: Daten zwischen Shards verschieben ist aufwändig
Hotspots: Ungleiche Verteilung kann zu überlasteten Shards führen
Transaktionen: Distributed Transactions sind komplex (2-Phase-Commit)
Operationale Komplexität: Mehr Server = mehr Monitoring, Backup, Wartung

Wann lohnt sich Sharding?

Sharding eignet sich besonders für:

Sehr große Datenmengen (> 1 TB)
Hohe Schreiblast (viele Writes pro Sekunde)
Globale Anwendungen mit Benutzern weltweit
Skalierbare SaaS-Plattformen mit vielen Mandanten

Sharding ist weniger geeignet für:

Kleine bis mittlere Datenbanken (< 100 GB)
Viele Joins und komplexe Queries
Starke Konsistenzanforderungen (ACID über alle Daten)
Begrenzte IT-Ressourcen (kein Team für Sharding-Management)

7. Use Cases – Wo wird Sharding eingesetzt?

Sharding wird in verschiedenen Branchen und Anwendungsfällen eingesetzt.

E-Commerce

Millionen von Produkten, Bestellungen und Kunden. Sharding nach User_ID oder Product_ID ermöglicht Skalierung.

Beispiel: Amazon, eBay sharding nach User_ID für Bestellungen, nach Product_ID für Katalog.

IoT & Sensor-Daten

Milliarden von Zeitstempel-Daten von Sensoren. Sharding nach Device_ID oder Zeitbereich.

Beispiel: Tesla sharding nach Vehicle_ID für Telemetrie-Daten.

Online Gaming

Spielstände, Leaderboards, Multiplayer-Daten. Sharding nach Game_ID oder User_ID.

Beispiel: World of Warcraft sharding nach Realm/Server für Spielwelten.

Finanzdienstleistungen

Transaktionen, Konten, Trades. Sharding nach Account_ID oder Region (Compliance).

Beispiel: Banken sharding nach Region für DSGVO-Compliance (EU-Daten in EU).

Analytics & Big Data

Log-Daten, Clickstreams, Metriken. Sharding nach Zeitbereich oder Tenant_ID.

Beispiel: Google Analytics sharding nach Date für zeitbasierte Partitionierung.

8. Challenges & Lösungen

Sharding bringt spezifische Herausforderungen mit sich. Hier die wichtigsten und wie man sie löst.

Rebalancing

Wenn sich die Datenverteilung ändert (z.B. durch Wachstum), müssen Daten zwischen Shards verschoben werden. Dies ist teuer und kann zu Downtime führen.

Lösung: Consistent Hashing minimiert Datenverschiebungen. Online Rebalancing (z.B. MongoDB) vermeidet Downtime.

Cross-Shard Queries

Joins oder Aggregationen über mehrere Shards sind teuer, da Daten von mehreren Servern geholt werden müssen.

Lösung: Denormalisierung (Daten redundant speichern), Application-Level Joins, oder Materialized Views.

Hotspots

Einzelne Shards werden übermäßig belastet (z.B. durch populäre User oder monotone Keys), während andere unterausgelastet sind.

Lösung: Hash-basierte Verteilung, Compound Keys, Read Replicas für heiße Shards, Caching (Redis).

Distributed Transactions

Transaktionen über mehrere Shards erfordern 2-Phase-Commit (2PC), was komplex und langsam ist.

Lösung: Saga-Pattern (kompensierende Transaktionen), Eventual Consistency akzeptieren, oder Sharding so designen, dass Transaktionen innerhalb eines Shards bleiben.

Schema Changes

Schema-Änderungen (z.B. neue Spalte) müssen auf allen Shards gleichzeitig angewendet werden, was komplex ist.

Lösung: Online Schema Migration Tools (z.B. pt-online-schema-change für MySQL), oder NoSQL-Datenbanken mit flexiblem Schema.

Query Routing

Der Router muss wissen, auf welchem Shard die Daten liegen. Bei falschem Routing werden alle Shards abgefragt (Scatter-Gather).

Lösung: Shard Key in Queries immer angeben, Lookup-Table mit Caching, oder Metadata-Server (z.B. MongoDB Config Servers).

9. FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Sharding

Was ist der Unterschied zwischen Sharding und Partitionierung?

Partitionierung ist der Oberbegriff für das Aufteilen von Daten. Es gibt zwei Arten:

Vertikale Partitionierung: Verschiedene Spalten auf verschiedene Tabellen/Server verteilen
Horizontale Partitionierung (Sharding): Verschiedene Zeilen auf verschiedene Server verteilen

Sharding ist also eine spezifische Form der horizontalen Partitionierung, bei der die Partitionen auf verschiedene Server verteilt werden.

Wie wähle ich den richtigen Shard Key?

Ein guter Shard Key sollte folgende Eigenschaften haben:

Hohe Kardinalität: Viele unterschiedliche Werte (z.B. User-ID, nicht Status)
Häufig in Queries: Der Shard Key sollte in den meisten Queries vorkommen
Nicht änderbar: Der Wert sollte sich nicht ändern
Gleichmäßige Verteilung: Vermeidet Hotspots

Beispiele: User_ID für Social Media, Order_ID für E-Commerce, Device_ID für IoT.

Was ist Consistent Hashing?

Consistent Hashing ist eine Hashing-Technik, die das Rebalancing minimiert, wenn Server hinzugefügt oder entfernt werden:

Hash-Ring: Server und Keys werden auf einen Ring abgebildet
Jeder Key wird dem nächsten Server im Uhrzeigersinn zugeordnet
Wenn ein Server entfernt wird, müssen nur seine Keys zum nächsten Server verschoben werden
Wenn ein Server hinzugefügt wird, übernimmt er nur einen Teil der Keys vom nächsten Server

Vorteil: Minimale Datenverschiebungen bei Skalierung. Wird von Cassandra, DynamoDB und anderen verwendet.

Kann ich Sharding rückgängig machen?

Ja, aber es ist aufwändig. Die Daten müssen von allen Shards wieder auf einen Server konsolidiert werden:

Alle Shards müssen gelesen und zusammengeführt werden
Cross-Shard References müssen aufgelöst werden
Downtime oder komplexe Migration nötig

Empfehlung: Sharding sollte gut geplant sein und nicht leichtfertig eingeführt werden. Einmal implementiert, ist es schwer rückgängig zu machen.

Welche Datenbanken unterstützen Sharding nativ?

Verschiedene Datenbanken bieten native Sharding-Unterstützung:

MongoDB: Native Sharding mit Config Servers und Mongos Router
Cassandra: Native Sharding mit Consistent Hashing (kein Router nötig)
CockroachDB: Distributed SQL mit automatischem Sharding
TiDB: MySQL-kompatibel mit horizontalem Sharding
PostgreSQL: Native Partitionierung (ab PG 10), Citus für Sharding
MySQL: Keine native Sharding, aber Vitess oder ProxySQL als Middleware

Wie handhabe ich Joins über mehrere Shards?

Joins über mehrere Shards sind eine der größten Herausforderungen. Lösungsansätze:

Denormalisierung: Daten redundant auf mehreren Shards speichern
Application-Level Joins: Anwendung holt Daten von mehreren Shards und joined sie
Materialized Views: Vorberechnete Join-Ergebnisse speichern
Same-Shard Design: Verwandte Daten auf demselben Shard speichern (z.B. User und seine Orders)
Graph-Datenbanken: Für komplexe Beziehungen (Neo4j, Amazon Neptune)

Best Practice: Sharding so designen, dass die meisten Queries innerhalb eines Shards bleiben.

Was ist der Unterschied zwischen Sharding und Replication?

Sharding:

Daten werden aufgeteilt (jeder Shard hat andere Daten)
Horizontale Skalierung (mehr Kapazität)
Write-Skalierung (Schreiblast verteilt)
Keine Redundanz (Daten nur auf einem Shard)

Replication:

Daten werden kopiert (jedes Replikat hat alle Daten)
Read-Skalierung (Leseanfragen verteilt)
Hochverfügbarkeit (Fallback bei Ausfall)
Redundanz (Daten auf mehreren Servern)

In der Praxis: Oft werden beide Techniken kombiniert (Sharding + Replication pro Shard).

Wann sollte ich mit Sharding beginnen?

Nicht zu früh! Sharding sollte erst eingeführt werden, wenn:

Die Datenbank zu groß für einen einzelnen Server ist (> 1 TB)
Die Schreiblast zu hoch für einen einzelnen Server ist
Vertikale Skalierung (größerer Server) zu teuer oder nicht mehr möglich ist
Performance-Optimierungen (Indizes, Caching, Query-Optimierung) nicht mehr ausreichen

Frühe Anzeichen:

Queries werden langsam trotz Indizes
CPU/RAM auf dem Datenbank-Server ist dauerhaft hoch ausgelastet
Writes werden zum Flaschenhals

Empfehlung: Erst alle anderen Optimierungen ausschöpfen, dann Sharding als letzte Option.

Zusammenfassung

             Die wichtigsten Punkte
            Sharding: Horizontale Partitionierung – Daten auf mehrere Server verteilen
Strategien: Range, Hash, Directory, Geo – je nach Use Case
Shard Key: Hohe Kardinalität, häufig in Queries, nicht änderbar
Architekturen: Shared-Nothing, Proxy/Router (empfohlen)
Vorteile: Horizontale Skalierung, Write-Skalierung, reduzierte Latenz
Nachteile: Komplexität, Cross-Shard Queries, Rebalancing
Use Cases: E-Commerce, IoT, Social Media, Gaming, Finance, Analytics
Challenges: Hotspots, Distributed Transactions, Schema Changes
Best Practice: Sharding erst einführen, wenn andere Optimierungen nicht mehr ausreichen

        

             Enterprise-Tipps
            Shard Key sorgfältig wählen: Hohe Kardinalität, häufig in Queries, nicht änderbar
Consistent Hashing nutzen: Minimiert Rebalancing-Aufwand
Monitoring einrichten: Shard-Größe, Hotspots, Query-Performance überwachen
Sharding + Replication kombinieren: Jeder Shard hat mehrere Replikate
Application-Level Caching: Redis oder Memcached für häufige Queries
Same-Shard Design: Verwandte Daten auf demselben Shard speichern

        

Weiterführende Themen

Replikation

Master-Slave, Multi-Master, Synchron vs. Asynchron – Datenbanken replizieren.

Zur Replikation

Datenbank-Grundlagen

SQL vs. NoSQL, ACID, CAP-Theorem – die Basis für Datenbank-Verständnis.

Zu Grundlagen

Big Data

Hadoop, Spark, Data Lakes – Verarbeitung riesiger Datenmengen.

Zu Big Data

Datenbank-Optimierung

Indizes, Query-Optimierung, Caching – Performance steigern.

Zur Optimierung