Come esporti un dataset enorme senza impattare il sistema live?

Question

IT Interview Practice · Accepted Answer

**Leggi da una replica o da uno snapshot (mai dal primary), pagina con keyset pagination invece di `OFFSET`, applica throttling al rate di lettura, e fai streaming dei risultati direttamente verso l'object storage.** L'obiettivo è esportare 500M di righe senza tenere lock lunghi, senza far spikare la CPU del primary, né far esplodere la memoria.

## Pipeline di export

```text
  Primary DB ──async replication──▶ Read replica / snapshot
                                          │  (isolated from live traffic)
                                          ▼
                                   Export worker
                              keyset page: WHERE id > :last
                                          │  throttle (sleep / rate limit)
                                          ▼
                                   Stream (batches)
                                          │
                                          ▼
                                   S3 / GCS  (NDJSON / Parquet)
```

## Perché ogni pezzo

- **Read replica o snapshot.** Punta il job a un follower così che le letture pesanti non competano mai con le scritture di produzione sul primary. Uno **snapshot** dà una vista stabile, point-in-time, così l'export è consistente anche mentre i dati live continuano a cambiare.
- **Keyset pagination, non `OFFSET`.** `OFFSET 10000000` fa sì che il DB faccia scan e scarti 10M di righe a ogni pagina — O(n²) sull'intero export. Il keyset ricorda l'ultima chiave e fa `WHERE id > :last ORDER BY id LIMIT 5000`, che cavalca l'index in O(1) per pagina.
- **Throttle.** Dormi tra i batch o limita le righe/sec così che la replica non si saturi e il replication lag resti limitato.
- **Streaming verso l'object store.** Scrivi ogni batch su S3/GCS come NDJSON o Parquet; non caricare mai l'intero result set in memoria. Usa un cursor/server-side cursor così che il driver faccia streaming delle righe.

## Prospettiva del colloquio

L'intervistatore verifica se proteggi il sistema live. Nominare una **replica** è il minimo; il segnale senior è **keyset invece di OFFSET** (e saper spiegare la trappola O(n²)) più **backpressure/throttling** e **consistenza** via snapshot. Una trappola comune: un unico `SELECT *` in una sola transazione — tiene aperta una vista di lettura per ore, gonfia il DB (il vacuum di Postgres non può pulire le righe che il lungo snapshot vede ancora), e bufferizza tutto in memoria.

**Compromessi:** una replica può essere in ritardo, quindi l'export riflette un momento leggermente stale — di solito va bene per l'analytics, non per una riconciliazione finanziaria che richiede dati esatti al momento. Il keyset richiede una sort key stabile, univoca e indicizzata; è scomodo per ordinamenti arbitrari. Quando la tabella è enorme e possiedi il layer di storage, uno strumento nativo (`pg_dump`, export di snapshot su S3, `COPY`) spesso batte una paginazione fatta a mano.

Pipeline di export

Perché ogni pezzo

Prospettiva del colloquio

Domande correlate