Hogyan exportálsz egy hatalmas adathalmazt az élő rendszer befolyásolása nélkül?

Question

IT Interview Practice · Accepted Answer

**Olvass egy replikából vagy snapshotból (sose a primaryből), lapozz keyset lapozással az `OFFSET` helyett, throttle-özd az olvasási sebességet, és streameld az eredményeket egyenesen object storage-be.** A cél 500M sort exportálni hosszú lockok tartása, primary CPU csúcs, vagy memória-felrobbanás nélkül.

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

## Miért minden darab

- **Read replika vagy snapshot.** Irányítsd a jobot egy followerre, hogy a nehéz olvasások sose versengjenek a produkciós írásokkal a primaryn. Egy **snapshot** egy stabil, point-in-time nézetet ad, így az export konzisztens még akkor is, ha az élő adat tovább változik.
- **Keyset lapozás, nem `OFFSET`.** Az `OFFSET 10000000` arra kényszeríti a DB-t, hogy 10M sort szkenneljen és dobjon el minden oldalon — O(n²) az export során. A keyset megjegyzi az utolsó kulcsot és `WHERE id > :last ORDER BY id LIMIT 5000`-et csinál, ami az indexre lovagol O(1)-ben oldalanként.
- **Throttle.** Aludj a batchek között vagy sapkázd meg a sor/mp-et, hogy a replika ne telítődjön és a replikációs lag korlátozott maradjon.
- **Streamelj object store-ba.** Írd minden batchet S3-ba/GCS-be NDJSON-ként vagy Parquetként; sose töltsd be az egész eredményhalmazt memóriába. Használj egy kurzort/server-side kurzort, hogy a driver streamelje a sorokat.

## Interjú szemszög

Az interjúztató azt ellenőrzi, véded-e az élő rendszert. Egy **replika** megnevezése alapelvárás; a senior jel a **keyset az OFFSET felett** (és képesnek lenni megmagyarázni az O(n²) csapdát) plusz a **backpressure/throttling** és a **konzisztencia** egy snapshoton keresztül. Gyakori csapda: egyetlen `SELECT *` egy tranzakcióban — órákig nyitva tart egy olvasási nézetet, felfújja a DB-t (a Postgres vacuum nem tudja tisztítani a sorokat, amiket a hosszú snapshot még lát), és mindent memóriába pufferel.

**Kompromisszumok:** egy replika lemaradhat, így az export egy kissé állott pillanatot tükröz — általában rendben van analitikához, de nem pénzügyi egyeztetéshez, ami pontos-most adatot igényel. A keysetnek egy stabil, egyedi, indexelt rendezőkulcsra van szüksége; kényelmetlen tetszőleges rendezési sorrendekhez. Amikor a tábla óriási és te birtoklod a tárolási réteget, egy natív eszköz (`pg_dump`, snapshot export S3-ba, `COPY`) gyakran veri a kézzel írt lapozást.

Export pipeline

Miért minden darab

Interjú szemszög

Kapcsolódó kérdések