Cum exporți un set de date uriaș fără a afecta sistemul live?

Question

IT Interview Practice · Accepted Answer

**Citește dintr-o replică sau un snapshot (niciodată din primary), paginează cu keyset pagination în loc de `OFFSET`, throttlează rata de citire și transmite rezultatele direct în stocare de obiecte.** Scopul este să exporți 500M de rânduri fără a ține lock-uri lungi, a face spike la CPU-ul primary-ului sau a arunca în aer memoria.

## Pipeline de export

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

## De ce fiecare piesă

- **Read replica sau snapshot.** Îndreaptă jobul către un follower, astfel încât citirile grele să nu concureze niciodată cu scrierile de producție pe primary. Un **snapshot** oferă o vedere stabilă, point-in-time, astfel încât exportul să fie consistent chiar dacă datele live continuă să se schimbe.
- **Keyset pagination, nu `OFFSET`.** `OFFSET 10000000` face DB-ul să scaneze și să arunce 10M de rânduri la fiecare pagină — O(n²) pe tot exportul. Keyset-ul reține ultima cheie și face `WHERE id > :last ORDER BY id LIMIT 5000`, care călărește indexul în O(1) per pagină.
- **Throttle.** Dormi între batch-uri sau plafonează rânduri/sec, astfel încât replica să nu fie saturată, iar replication lag-ul să rămână delimitat.
- **Transmite către object store.** Scrie fiecare batch în S3/GCS ca NDJSON sau Parquet; nu încărca niciodată întregul set de rezultate în memorie. Folosește un cursor/server-side cursor, astfel încât driverul să transmită rândurile.

## Perspectiva de interviu

Intervievatorul verifică dacă protejezi sistemul live. A numi o **replică** este minimul; semnalul de senior este **keyset peste OFFSET** (și capacitatea de a explica capcana O(n²)) plus **backpressure/throttling** și **consistență** printr-un snapshot. O capcană obișnuită: un singur `SELECT *` într-o tranzacție — ține o vedere de citire deschisă ore întregi, umflă DB-ul (vacuum-ul Postgres nu poate curăța rândurile pe care le vede încă snapshot-ul lung) și buffer-uiește tot în memorie.

**Compromisuri:** o replică poate fi în urmă, deci exportul reflectă un moment ușor învechit — de obicei în regulă pentru analytics, nu pentru reconcilierea financiară care are nevoie de date exact-acum. Keyset-ul are nevoie de o cheie de sortare stabilă, unică, indexată; este incomod pentru ordine de sortare arbitrare. Când tabela este enormă și deții stratul de stocare, o unealtă nativă (`pg_dump`, export de snapshot către S3, `COPY`) bate adesea paginarea făcută manual.

Pipeline de export

De ce fiecare piesă

Perspectiva de interviu

Întrebări conexe