Hoe exporteer je een enorme dataset zonder het live systeem te belasten?

Question

IT Interview Practice · Accepted Answer

**Lees uit een replica of snapshot (nooit de primary), pagineer met keyset-paginatie in plaats van `OFFSET`, throttle de leessnelheid, en stream resultaten direct naar object storage.** Het doel is 500M rows exporteren zonder lange locks vast te houden, primary-CPU te laten pieken, of het geheugen op te blazen.

## Export-pipeline

```text
  Primaire DB ──async replicatie──▶ Read replica / snapshot
                                          │  (geïsoleerd van live verkeer)
                                          ▼
                                   Export-worker
                              keyset-pagina: WHERE id > :last
                                          │  throttle (sleep / rate limit)
                                          ▼
                                   Stream (batches)
                                          │
                                          ▼
                                   S3 / GCS  (NDJSON / Parquet)
```

## Waarom elk onderdeel

- **Read replica of snapshot.** Wijs de job naar een follower zodat zware reads nooit concurreren met productie-writes op de primary. Een **snapshot** geeft een stabiele, point-in-time view zodat de export consistent is, zelfs terwijl live data blijft veranderen.
- **Keyset-paginatie, niet `OFFSET`.** `OFFSET 10000000` laat de DB elke pagina 10M rows scannen en weggooien — O(n²) over de export. Keyset onthoudt de laatste key en doet `WHERE id > :last ORDER BY id LIMIT 5000`, wat de index berijdt in O(1) per pagina.
- **Throttle.** Slaap tussen batches of begrens rows/sec zodat de replica niet verzadigt en replicatie-lag begrensd blijft.
- **Stream naar object store.** Schrijf elke batch naar S3/GCS als NDJSON of Parquet; laad nooit de hele resultset in geheugen. Gebruik een cursor/server-side cursor zodat de driver rows streamt.

## Interviewperspectief

De interviewer checkt of je het live systeem beschermt. Een **replica** benoemen is basisniveau; het senior-signaal is **keyset boven OFFSET** (en de O(n²)-valkuil kunnen uitleggen) plus **backpressure/throttling** en **consistentie** via een snapshot. Een veelvoorkomende valkuil: één `SELECT *` in één transactie — het houdt urenlang een read-view open, blaast de DB op (Postgres vacuum kan geen rows opruimen die de lange snapshot nog ziet), en buffert alles in geheugen.

**Afwegingen:** een replica kan achterlopen, dus de export weerspiegelt een licht verouderd moment — meestal prima voor analytics, niet voor financiële reconciliatie die exact-nu-data vereist. Keyset heeft een stabiele, unieke, geïndexeerde sorteersleutel nodig; het is lastig voor willekeurige sorteervolgordes. Wanneer de tabel enorm is en je de storage-laag bezit, verslaat een native tool (`pg_dump`, snapshot-export naar S3, `COPY`) vaak handmatig gebouwde paginatie.

Export-pipeline

Waarom elk onderdeel

Interviewperspectief

Gerelateerde vragen