Wann greift man zu Partitionierung statt zu Sharding, um MySQL zu skalieren?

Question

IT Interview Practice · Accepted Answer

Beide teilen eine große Tabelle, aber auf unterschiedlichen Ebenen. **Partitionierung** teilt eine Tabelle über mehrere Dateien **innerhalb eines einzigen MySQL-Servers**. **Sharding** teilt Daten über **mehrere unabhängige Server**. Partitionierung hilft einer Tabelle, die für eine Datei zu groß ist; Sharding hilft einem Workload, der für eine Maschine zu groß ist.

## Partitionierung (ein Server)

```sql
CREATE TABLE events (
  id BIGINT, created_at DATETIME, payload JSON,
  PRIMARY KEY (id, created_at)          -- partition key must be in every unique key
) PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION p2026 VALUES LESS THAN (2027)
);
-- Queries filtering on created_at hit ONE partition (partition pruning);
-- dropping old data is an instant ALTER TABLE ... DROP PARTITION p2024.
```

Großartig für Zeitreihen und einfache Archivierung, aber es ist immer noch ein Server — nicht mehr Gesamt-CPU, -RAM oder -Schreibdurchsatz.

## Sharding (viele Server)

Wähle einen **Shard-Key** (z. B. `user_id`) und leite jede Zeile per Hash oder Bereich an einen Shard:

```
shard = hash(user_id) % N
  user 42 -> shard 2 (server B)     user 99 -> shard 0 (server A)
```

- **Vorteile** — nahezu lineare Skalierung von Schreibvorgängen, Speicher und Verbindungen.
- **Nachteile** — Cross-Shard-JOINs und -Transaktionen sind schwer oder unmöglich; ein schlechter Shard-Key erzeugt Hotspots; **Resharding** beim Hinzufügen von Servern ist schmerzhaft. Wähle einen Schlüssel mit hoher Kardinalität und gleichmäßiger Verteilung und vermeide Abfragen, die über alle Shards fächern müssen.

## Reihenfolge des Vorgehens

Schöpfe zuerst die günstigeren Gewinne aus: Indexierung, Query-Tuning, Read-Replicas, Caching, dann Partitionierung. Greife zu Sharding erst, wenn ein einzelner Primary das **Schreibvolumen** nicht mehr aufnehmen kann — es ist der größte Sprung in operativer Komplexität.

## Warum es wichtig ist

Skalierungsentscheidungen sind weitgehend irreversibel und teuer. Zu wissen, dass Partitionierung ein Organisationswerkzeug auf einem einzelnen Server ist, während Sharding ein Bekenntnis zu verteilten Systemen darstellt — mit seinen Shard-Key- und Cross-Shard-Kosten — hält Teams davon ab, verfrüht zu sharden oder von der Partitionierung zu erwarten, dass sie eine Schreibdurchsatz-Obergrenze löst, die sie nicht lösen kann.

Partitionierung (ein Server)

Sharding (viele Server)

Reihenfolge des Vorgehens

Warum es wichtig ist

Ähnliche Fragen