Kiedy sięgać po partycjonowanie, a kiedy po sharding, aby skalować MySQL?

Question

IT Interview Practice · Accepted Answer

Oba dzielą dużą tabelę, ale na różnych poziomach. **Partycjonowanie** dzieli jedną tabelę na wiele plików **wewnątrz pojedynczego serwera MySQL**. **Sharding** dzieli dane na **wiele niezależnych serwerów**. Partycjonowanie pomaga tabeli, która jest zbyt duża na jeden plik; sharding pomaga obciążeniu, które jest zbyt duże na jedną maszynę.

## Partycjonowanie (jeden serwer)

```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.
```

Świetne dla szeregów czasowych i łatwej archiwizacji, ale to wciąż jeden serwer — brak dodatkowej łącznej mocy CPU, RAM czy przepustowości zapisu.

## Sharding (wiele serwerów)

Wybierz **klucz shardowania** (np. `user_id`) i kieruj każdy wiersz do sharda przez hash lub zakres:

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

- **Zalety** — niemal liniowe skalowanie zapisów, pamięci masowej i połączeń.
- **Wady** — złączenia i transakcje między shardami są trudne lub niemożliwe; zły klucz shardowania tworzy gorące punkty; **resharding** przy dodawaniu serwerów jest bolesny. Wybierz klucz o wysokiej liczności i równomiernym rozkładzie oraz unikaj zapytań, które muszą rozgałęziać się do wszystkich shardów.

## Kolejność działań

Wyczerp najpierw tańsze zdobycze: indeksowanie, strojenie zapytań, repliki do odczytu, buforowanie, potem partycjonowanie. Po sharding sięgaj dopiero wtedy, gdy pojedynczy master nie jest już w stanie wchłonąć wolumenu **zapisów** — to największy skok w złożoności operacyjnej.

## Dlaczego to ważne

Decyzje o skalowaniu są w dużej mierze nieodwracalne i kosztowne. Świadomość, że partycjonowanie to narzędzie organizacyjne pojedynczego serwera, podczas gdy sharding to zobowiązanie z zakresu systemów rozproszonych — z jego kosztami klucza shardowania i operacji między shardami — chroni zespoły przed przedwczesnym shardingiem lub oczekiwaniem, że partycjonowanie rozwiąże pułap przepustowości zapisu, którego nie jest w stanie.

Partycjonowanie (jeden serwer)

Sharding (wiele serwerów)

Kolejność działań

Dlaczego to ważne

Powiązane pytania