Wie würdest du eine Datenbank für 1 Milliarde Nutzer sharden?

Question

IT Interview Practice · Accepted Answer

Sharde nach einem Key, der **in fast jeder Query vorkommt und die Last gleichmäßig verteilt** - meist eine gehashte `user_id` - und plane Resharding und Cross-Shard-Queries von Tag eins an ein. 1 Mrd. Nutzer passen oder performen nicht auf einem Node; du splittest Rows über viele Datenbanken und routest jede Query zu dem Shard, dem sie gehört.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Wahl des Shard Keys - die schwer rückgängig zu machende Entscheidung

Wähle einen Key mit **hoher Kardinalität, gleichmäßiger Verteilung und Präsenz in den meisten Queries**. `user_id` gewinnt meist: nutzerbezogene Queries ("mein Profil, meine Bestellungen") treffen genau einen Shard. Ein schlechter Key (z. B. `country`) erzeugt Hotspots - ein Shard hält ganz Indien, während ein anderer untätig ist.

## Hash vs. Range

- **Hash Sharding** (`shard = hash(user_id) % N`): verteilt gleichmäßig, beseitigt Hotspots - aber Range Queries ("in der letzten Woche erstellte Nutzer") müssen über alle Shards scatter-gathern.
- **Range Sharding** (`user_id 0–1M → shard 0`): hält Ranges lokal und erleichtert Resharding, riskiert aber Hotspots (die neuesten Nutzer landen alle auf dem letzten Shard).
- Übliche Antwort: **Hash für gleichmäßige Last**, mit einer **Lookup-/Directory-Tabelle**, sodass du Ranges verschieben kannst, ohne alles neu zu hashen.

## Resharding - plane, bevor du es brauchst

`% N` ist eine Falle: Ein Shard hinzuzufügen remappt fast jeden Key. Nutze **Consistent Hashing** oder **virtuelle Buckets** (mappe Keys → 4096 logische Buckets → physische Shards). Einen Shard zu splitten verschiebt dann Buckets, nicht den ganzen Keyspace. Tools wie **Vitess** (verwendet von YouTube/Slack) automatisieren Live-Resharding mit Cutover.

## Cross-Shard-Queries

Alles, was nicht nach dem Shard Key gekeyt ist, ist schmerzhaft: eine globale "Top Posts"-Query fächert auf jeden Shard aus und merged. Mildere das durch **Denormalisierung** oder halte einen separaten Index-/Such-Store (Elasticsearch) für übergreifende Reads.

## Interview-Perspektive

Interviewer sondieren, ob du verstehst, dass die Shard-Key-Wahl **semi-permanent** ist, und ob du über **Resharding und Cross-Shard-Joins** nachgedacht hast - die zwei Dinge, die in Produktion beißen. Gut: "nach user_id sharden." Hervorragend: Du bringst Consistent Hashing, Hot-Shard-Mitigation und die Tatsache auf, dass verteilte Transaktionen über Shards am besten ganz vermieden werden.

**Häufige Falle:** `hash % N` mit festem N - es macht künftiges Wachstum zu einer vollständigen Datenmigration.

## Trade-offs & Fehlermodi

- **Verlorenes Cross-Shard-ACID:** keine günstigen Joins/Transaktionen über Shards; nutze Sagas oder denormalisiere.
- **Hot Shard:** ein viraler Nutzer; sub-sharde oder cache diese Entität.
- **Rebalancing-Risiko:** Live-Migration muss vor dem Cutover doppelt schreiben und verifizieren.
- **Betriebskosten:** N Shards × Replicas = viele Datenbanken zu überwachen, zu sichern und zu failovern.

Wahl des Shard Keys - die schwer rückgängig zu machende Entscheidung

Hash vs. Range

Resharding - plane, bevor du es brauchst

Cross-Shard-Queries

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen