Sharding

Wenn dein Server (Vertical Scaling) am Limit ist (100% CPU, 100% RAM). Du fügst einen zweiten Server hinzu. Du brauchst einen Shard Key (z. B. CustomerID).

• User 1-1000 -> Server A.
• User 1001-2000 -> Server B. Datenbanken wie MongoDB oder Cassandra machen das automatisch.

1. Cross-Shard Joins

Der Horror. Du willst: SELECT * FROM Orders WHERE Date = Today. Das Datum ist aber nicht der Shard Key (sondern UserID). Jetzt musst du alle Shards fragen ("Scatter-Gather"). Das ist langsam. Noch schlimmer: Ein Join zwischen zwei Tabellen, die auf verschiedenen Shards liegen. Das geht oft gar nicht (Anwendung muss es im Code machen).

2. Resharding (The Thundering Herd)

Ein Shard wird zu voll (Hotspot). Du musst ihn aufteilen. Daten zur Laufzeit zu verschieben, ohne die DB zu stoppen, ist extrem komplex. Consistent Hashing hilft, die Datenwanderung zu minimieren.

1. Shard Key Selection & High Cardinality

Die Wahl des Shard Keys ist die wichtigste Entscheidung der DB-Architektur. Sie kann später fast nicht mehr geändert werden. Du suchst ein Feld mit hoher Kardinalität (viele verschiedene Werte) und gleichmäßiger Verteilung. Schlechtes Beispiel: Land. Wenn 80% deiner User aus Deutschland kommen, wird Shard DE zum Flaschenhals, während Island leer bleibt. Ideale Shard Keys sind oft UUIDs oder Hashes von UserIDs. Aber Vorsicht: Wenn du nach Zeit sortieren willst (ORDER BY created_at), zerstören zufällige Hashes die Performance, da die Daten über alle Platten verstreut liegen (kein Sequential I/O). Man muss oft einen Kompromiss finden oder Hashed Sharding nutzen, um Hotspots zu vermeiden.

2. Consistent Hashing & The Thundering Herd

Wenn du von 10 auf 11 Server skalierst (Sharding-Limit erhöhen), müssten bei einem naiven ID % 11-Ansatz plötzlich 90% deiner Daten auf einen neuen Server umziehen. Das würde das Netzwerk grillen. Consistent Hashing löst das: Die Server werden auf einem virtuellen Ring angeordnet. Bei einem neuen Server müssen nur ca. $1/n$ der Daten umziehen. Noch besser: Virtuelle Nodes. Ein physischer Server "besitzt" hunderte kleine Punkte auf dem Ring. Fällt ein Server aus, verteilen sich seine Daten gleichmäßig auf alle anderen Nachbarn, anstatt nur einen einzigen Nachbarn mit einer "Thundering Herd" an neuen Anfragen zu erschlagen.

3. Vitess & NewSQL: Abstraktion vom Schmerz

Sharding von Hand in der Applikationslogik zu verwalten (z. B. in PHP/Python verschiedene DB-Handles führen), ist ein Albtraum. Systeme wie Vitess (entwickelt für YouTube) setzen sich als Proxy vor eine MySQL-Farm. Die App denkt weiterhin, sie spricht mit einer einzigen riesigen Datenbank. Vitess zerlegt die Queries im Hintergrund, schickt sie an die richtigen Shards und fügt die Ergebnisse zusammen. Das nimmt den Entwicklern die Komplexität ab, kostet aber Latenz (der Proxy braucht Zeit zum Denken). Moderne "NewSQL" Datenbanken wie CockroachDB oder TiDB integrieren Sharding nativ tief im Speichersystem (Raft-basierte Partitionen), sodass man sich um das "Zerschneiden des Buches" überhaupt nicht mehr kümmern muss.