Comment exporter un énorme dataset sans impacter le système live ?

Question

IT Interview Practice · Accepted Answer

**Lisez depuis un réplica ou un snapshot (jamais le primary), paginez avec la pagination keyset au lieu d'`OFFSET`, throttlez le débit de lecture, et streamez les résultats directement vers un stockage objet.** Le but est d'exporter 500M de lignes sans tenir de longs verrous, sans faire spiker le CPU du primary, ni faire exploser la mémoire.

## Pipeline d'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)
```

## Pourquoi chaque pièce

- **Read replica ou snapshot.** Pointez le job vers un follower pour que les lectures lourdes ne concurrencent jamais les écritures de production sur le primary. Un **snapshot** donne une vue stable, à un instant précis, pour que l'export soit cohérent même pendant que les données live continuent de changer.
- **Pagination keyset, pas `OFFSET`.** `OFFSET 10000000` fait scanner et jeter 10M de lignes à la DB à chaque page — O(n²) sur l'export. Le keyset retient la dernière clé et fait `WHERE id > :last ORDER BY id LIMIT 5000`, qui chevauche l'index en O(1) par page.
- **Throttle.** Dormez entre les batchs ou plafonnez les lignes/sec pour que le réplica ne soit pas saturé et que le replication lag reste borné.
- **Streamer vers le store objet.** Écrivez chaque batch vers S3/GCS en NDJSON ou Parquet ; ne chargez jamais tout le result set en mémoire. Utilisez un cursor/server-side cursor pour que le driver streame les lignes.

## Perspective d'entretien

L'examinateur vérifie si vous protégez le système live. Nommer un **réplica** est le minimum ; le signal senior est le **keyset plutôt qu'OFFSET** (et être capable d'expliquer le piège O(n²)) plus le **backpressure/throttling** et la **cohérence** via un snapshot. Un piège courant : un seul `SELECT *` dans une transaction — il tient une vue de lecture ouverte pendant des heures, gonfle la DB (le vacuum de Postgres ne peut pas nettoyer les lignes que le long snapshot voit encore), et bufferise tout en mémoire.

**Compromis :** un réplica peut être en retard, donc l'export reflète un instant légèrement périmé — généralement acceptable pour l'analytique, pas pour une réconciliation financière nécessitant des données exactes à l'instant. Le keyset nécessite une sort key stable, unique et indexée ; il est malaisé pour des ordres de tri arbitraires. Quand la table est énorme et que vous possédez la couche de stockage, un outil natif (`pg_dump`, export de snapshot vers S3, `COPY`) bat souvent une pagination faite main.

Pipeline d'export

Pourquoi chaque pièce

Perspective d'entretien

Questions connexes