Come partizioni una singola tabella con miliardi di righe?

Question

IT Interview Practice · Accepted Answer

**Suddividi la tabella gigante in tabelle figlie fisiche più piccole per una partition key, così che ogni query tocchi solo le partizioni di cui ha bisogno (partition pruning) invece di fare scan di miliardi di righe.** Una tabella con 5B di righe d'ordine si comporta comunque come un'unica tabella logica, ma il motore salta il 99% di essa quando il tuo `WHERE` filtra sulla partition key.

## La forma di una tabella partizionata

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## Scelta di una strategia di partitioning

- **Range** — per range di date/id. Ideale per serie temporali (ordini, log, eventi); i dati recenti restano caldi e i range vecchi sono facili da eliminare.
- **Hash** — distribuzione uniforme su N partizioni tramite `hash(key) % N`. Usalo quando non c'è un range naturale e vuoi carico bilanciato (es. `user_id`).
- **List** — bucket espliciti (`region IN ('EU','US')`). Buono per isolamento per tenant o region.

```sql
-- Postgres: range partition per mese, pruning su created_at
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- Questo fa scan SOLO di orders_2025_01, non dell'intera tabella
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, index, manutenzione

- **Il partition pruning** funziona solo se la query filtra sulla **partition key**. Filtra su qualcos'altro e fai scan di ogni partizione — l'errore n.1.
- **Local index** = un index per figlia (default in Postgres); economico da costruire ed eliminare con la partizione. **Global index** (Oracle) copre tutte le partizioni — aiuta i lookup univoci tra partizioni ma va ricostruito quando ne elimini una.
- **La manutenzione** diventa O(partizione): archivia i dati vecchi con `DROP TABLE orders_2019` (istantaneo, nessun gigantesco `DELETE`), e `ATTACH`/`DETACH` per finestre scorrevoli.

## Prospettiva del colloquio

L'intervistatore sonda se comprendi che **il partitioning non è indexing** — riduce i dati sottoposti a scan, un index riduce le righe esaminate all'interno di uno scan; spesso ti servono entrambi. La buona risposta nomina range/hash/list; l'eccellente sottolinea che **la partition key deve corrispondere al tuo filtro di query dominante**, avverte che una chiave sbagliata uccide il pruning, e menziona l'archiviazione economica via `DROP`.

**Compromesso:** le query cross-partition (nessun filtro sulla chiave, o vincoli univoci tra partizioni) diventano più lente e l'enforcement dell'unicità è più difficile. Non partizionare una tabella da 10M di righe — aggiungi complessità operativa senza guadagno. Partiziona quando la tabella è enorme **e** le query sono naturalmente delimitate dalla chiave.

La forma di una tabella partizionata

Scelta di una strategia di partitioning

Pruning, index, manutenzione

Prospettiva del colloquio

Domande correlate