Hvordan eksporterer du et enormt datasæt uden at påvirke live-systemet?

Question

IT Interview Practice · Accepted Answer

**Læs fra en replica eller snapshot (aldrig primary'en), paginer med keyset pagination i stedet for `OFFSET`, throttle read-raten, og stream resultater direkte til object storage.** Målet er at eksportere 500M rows uden at holde lange locks, spike primary-CPU eller sprænge hukommelsen.

## Export-pipeline

```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)
```

## Hvorfor hver del

- **Read replica eller snapshot.** Peg jobbet mod en follower, så tunge reads aldrig konkurrerer med produktions-writes på primary'en. Et **snapshot** giver en stabil, point-in-time-visning, så eksporten er konsistent selv mens live-data bliver ved med at ændre sig.
- **Keyset pagination, ikke `OFFSET`.** `OFFSET 10000000` får DB'en til at scanne og kassere 10M rows hver side — O(n²) over eksporten. Keyset husker den sidste nøgle og kører `WHERE id > :last ORDER BY id LIMIT 5000`, som rider index'et i O(1) pr. side.
- **Throttle.** Sov mellem batches eller begræns rows/sek, så replicaen ikke mættes og replication lag forbliver afgrænset.
- **Stream til object store.** Skriv hver batch til S3/GCS som NDJSON eller Parquet; load aldrig hele result-settet i hukommelsen. Brug en cursor/server-side cursor så driveren streamer rows.

## Interview-perspektiv

Intervieweren tjekker, om du beskytter live-systemet. At navngive en **replica** er table stakes; senior-signalet er **keyset over OFFSET** (og at kunne forklare O(n²)-fælden) plus **backpressure/throttling** og **konsistens** via et snapshot. En almindelig fælde: et enkelt `SELECT *` i én transaction — det holder en read-visning åben i timer, opsvulmer DB'en (Postgres vacuum kan ikke rydde rows det lange snapshot stadig ser), og buffer alt i hukommelsen.

**Trade-offs:** en replica kan sakke, så eksporten afspejler et lidt forældet øjeblik — som regel fint for analytics, ikke for finansiel afstemning der kræver eksakt-nu-data. Keyset kræver en stabil, unik, indekseret sort key; det er akavet for arbitrære sort-rækkefølger. Når tabellen er enorm og du ejer storage-laget, slår et native værktøj (`pg_dump`, snapshot-eksport til S3, `COPY`) ofte hjemmelavet paging.

Export-pipeline

Hvorfor hver del

Interview-perspektiv

Relaterede spørgsmål