Quando ricorrere al partitioning rispetto allo sharding per scalare MySQL?

Question

IT Interview Practice · Accepted Answer

Entrambi suddividono una grande tabella, ma a livelli diversi. Il **partitioning** suddivide una tabella su più file **all'interno di un singolo server MySQL**. Lo **sharding** suddivide i dati su **più server indipendenti**. Il partitioning aiuta una tabella troppo grande per un solo file; lo sharding aiuta un carico di lavoro troppo grande per una sola macchina.

## Partitioning (un server)

```sql
CREATE TABLE events (
  id BIGINT, created_at DATETIME, payload JSON,
  PRIMARY KEY (id, created_at)          -- la partition key deve stare in ogni 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)
);
-- Le query che filtrano su created_at colpiscono UNA sola partizione (partition pruning);
-- eliminare i dati vecchi è un istantaneo ALTER TABLE ... DROP PARTITION p2024.
```

Ottimo per le serie temporali e l'archiviazione facile, ma è pur sempre un solo server — nessun aumento di CPU, RAM o throughput di scrittura totali.

## Sharding (molti server)

Scegli una **shard key** (es. `user_id`) e instrada ogni riga a uno shard tramite hash o range:

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

- **Pro** — scaling quasi lineare di scritture, storage e connessioni.
- **Contro** — i JOIN e le transazioni cross-shard sono difficili o impossibili; una shard key sbagliata crea hotspot; il **resharding** quando aggiungi server è doloroso. Scegli una chiave ad alta cardinalità e distribuita in modo uniforme, ed evita le query che devono fare fan-out su tutti gli shard.

## Ordine delle operazioni

Esaurisci prima le soluzioni più economiche: indicizzazione, tuning delle query, read replica, caching, poi partitioning. Ricorri allo sharding solo quando un singolo primary non riesce più ad assorbire il volume di **scritture** — è il salto più grande in complessità operativa.

## Perché è importante

Le decisioni di scaling sono in gran parte irreversibili e costose. Sapere che il partitioning è uno strumento organizzativo su singolo server mentre lo sharding è un impegno da sistemi distribuiti — con i suoi costi di shard key e cross-shard — evita ai team di fare sharding prematuramente o di aspettarsi che il partitioning risolva un tetto di throughput in scrittura che non può risolvere.

Partitioning (un server)

Sharding (molti server)

Ordine delle operazioni

Perché è importante

Domande correlate