Hur exporterar du ett enormt dataset utan att påverka livesystemet?

Question

IT Interview Practice · Accepted Answer

**Läs från en replica eller snapshot (aldrig primary:n), sida igenom med keyset-paginering istället för `OFFSET`, strypa läshastigheten, och strömma resultat direkt till objektlagring.** Målet är att exportera 500M rader utan att hålla långa lås, spika primary-CPU, eller spränga minnet.

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

## Varför varje del

- **Read replica eller snapshot.** Rikta jobbet mot en follower så att tunga läsningar aldrig konkurrerar med produktionsskrivningar på primary:n. En **snapshot** ger en stabil, point-in-time-vy så att exporten är konsistent även medan livedata fortsätter ändras.
- **Keyset-paginering, inte `OFFSET`.** `OFFSET 10000000` får DB:n att scanna och kasta 10M rader varje sida — O(n²) över exporten. Keyset kommer ihåg den senaste nyckeln och gör `WHERE id > :last ORDER BY id LIMIT 5000`, som rider på indexet i O(1) per sida.
- **Strypning.** Sov mellan batchar eller tak-begränsa rader/sek så att replican inte mättas och replication lag förblir begränsat.
- **Strömma till objektlagring.** Skriv varje batch till S3/GCS som NDJSON eller Parquet; ladda aldrig hela resultatmängden i minnet. Använd en cursor/server-side cursor så att drivrutinen strömmar rader.

## Intervjuperspektiv

Intervjuaren kontrollerar om du skyddar livesystemet. Att namnge en **replica** är grundkrav; seniorsignalen är **keyset över OFFSET** (och att kunna förklara O(n²)-fällan) plus **backpressure/strypning** och **konsistens** via en snapshot. En vanlig fälla: en enda `SELECT *` i en transaktion — den håller en läsvy öppen i timmar, sväller DB:n (Postgres vacuum kan inte städa rader som den långa snapshoten fortfarande ser), och buffrar allt i minnet.

**Avvägningar:** en replica kan ligga efter, så exporten speglar ett något inaktuellt ögonblick — vanligtvis okej för analys, inte för finansiell avstämning som behöver exakt-nu-data. Keyset behöver en stabil, unik, indexerad sorteringsnyckel; det är otympligt för godtyckliga sorteringsordningar. När tabellen är enorm och du äger lagringslagret slår ett inbyggt verktyg (`pg_dump`, snapshot-export till S3, `COPY`) ofta handrullad paginering.

Export-pipeline

Varför varje del

Intervjuperspektiv

Relaterade frågor