Jak exportovat obrovský dataset bez dopadu na živý systém?

Question

IT Interview Practice · Accepted Answer

**Čtěte z repliky nebo snapshotu (nikdy z primary), stránkujte keyset paginací místo `OFFSET`, přiškrťte tempo čtení a streamujte výsledky rovnou do object storage.** Cílem je exportovat 500 milionů řádků bez držení dlouhých zámků, bez špičky CPU na primary a bez vyhození paměti.

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

## Proč každý kus

- **Read replika nebo snapshot.** Namiřte job na follower, aby těžká čtení nikdy nesoupeřila s produkčními zápisy na primary. **Snapshot** dá stabilní point-in-time pohled, takže export je konzistentní, i když se živá data dál mění.
- **Keyset paginace, ne `OFFSET`.** `OFFSET 10000000` nutí DB skenovat a zahodit 10M řádků na každou stránku — O(n²) přes celý export. Keyset si pamatuje poslední klíč a dělá `WHERE id > :last ORDER BY id LIMIT 5000`, což jede po indexu v O(1) na stránku.
- **Přiškrcení.** Uspávejte mezi dávkami nebo omezte řádky/s, aby replika nebyla nasycená a replication lag zůstal ohraničený.
- **Streamujte do object storu.** Zapisujte každou dávku do S3/GCS jako NDJSON nebo Parquet; nikdy nenačítejte celou sadu výsledků do paměti. Použijte kurzor/server-side kurzor, aby driver streamoval řádky.

## Pohled z pohovoru

Tazatel ověřuje, zda chráníte živý systém. Pojmenování **repliky** je základ; seniorní signál je **keyset nad OFFSET** (a schopnost vysvětlit O(n²) past) plus **backpressure/throttling** a **konzistence** přes snapshot. Častá past: jeden `SELECT *` v jedné transakci — drží read view otevřený hodiny, nafoukne DB (Postgres vacuum nemůže uklidit řádky, které dlouhý snapshot stále vidí) a bufferuje vše v paměti.

**Kompromisy:** replika může zaostávat, takže export odráží mírně zastaralý okamžik — obvykle v pořádku pro analytiku, ne pro finanční odsouhlasení vyžadující přesná data-teď. Keyset potřebuje stabilní, unikátní, indexovaný sort key; je nešikovný pro libovolná řazení. Když je tabulka enormní a vlastníte storage vrstvu, nativní nástroj (`pg_dump`, snapshot export do S3, `COPY`) často porazí ručně dělané stránkování.

Export pipeline

Proč každý kus

Pohled z pohovoru

Související otázky