Hvordan eksporterer du et enormt datasett uten å påvirke live-systemet?

Question

IT Interview Practice · Accepted Answer

**Les fra en replica eller snapshot (aldri primaryen), bla gjennom med keyset pagination i stedet for `OFFSET`, strup lese-raten, og stream resultater rett til object storage.** Målet er å eksportere 500M rader uten å holde lange locks, spike primary-CPU, eller sprenge minnet.

## Eksport-pipeline

```text
  Primary DB ──async replikering──▶ Read replica / snapshot
                                          │  (isolert fra live trafikk)
                                          ▼
                                   Eksport-worker
                              keyset side: WHERE id > :last
                                          │  strup (sleep / rate limit)
                                          ▼
                                   Stream (batcher)
                                          │
                                          ▼
                                   S3 / GCS  (NDJSON / Parquet)
```

## Hvorfor hver del

- **Read replica eller snapshot.** Pek jobben mot en follower slik at tunge lesninger aldri konkurrerer med produksjons-writes på primaryen. Et **snapshot** gir en stabil, point-in-time visning slik at eksporten er konsistent selv mens live data fortsetter å endres.
- **Keyset pagination, ikke `OFFSET`.** `OFFSET 10000000` får DB-en til å skanne og forkaste 10M rader hver side — O(n²) over eksporten. Keyset husker siste key og gjør `WHERE id > :last ORDER BY id LIMIT 5000`, som rir indeksen i O(1) per side.
- **Strup.** Sov mellom batcher eller cap rader/sek slik at replica-en ikke mettes og replication lag holder seg avgrenset.
- **Stream til object store.** Skriv hver batch til S3/GCS som NDJSON eller Parquet; last aldri hele resultatsettet inn i minnet. Bruk en cursor/server-side cursor slik at driveren streamer rader.

## Intervjuperspektiv

Intervjueren sjekker om du beskytter live-systemet. Å navngi en **replica** er grunnleggende; senior-signalet er **keyset over OFFSET** (og å kunne forklare O(n²)-fellen) pluss **backpressure/throttling** og **konsistens** via et snapshot. En vanlig felle: en enkelt `SELECT *` i én transaksjon — den holder en read view åpen i timer, blåser opp DB-en (Postgres vacuum kan ikke rydde rader det lange snapshotet fortsatt ser), og buffrer alt i minnet.

**Avveininger:** en replica kan henge etter, så eksporten reflekterer et litt stale øyeblikk — vanligvis greit for analytics, ikke for finansiell avstemming som trenger exact-now-data. Keyset trenger en stabil, unik, indeksert sorteringsnøkkel; den er upraktisk for vilkårlige sorteringsrekkefølger. Når tabellen er enorm og du eier lagringslaget, slår et native verktøy (`pg_dump`, snapshot-eksport til S3, `COPY`) ofte håndlaget paging.

Eksport-pipeline

Hvorfor hver del

Intervjuperspektiv

Relaterte spørsmål