live system ను ప్రభావితం చేయకుండా ఒక భారీ dataset ను మీరు ఎలా export చేస్తారు?

Question

IT Interview Practice · Accepted Answer

**ఒక replica లేదా snapshot నుండి read చేయండి (ఎప్పుడూ primary కాదు), `OFFSET` కి బదులు keyset pagination తో page చేయండి, read rate ను throttle చేయండి, మరియు results ను నేరుగా object storage కి stream చేయండి.** లక్ష్యం long locks పట్టుకోకుండా, primary CPU ను spike చేయకుండా, లేదా memory ను పేల్చకుండా 500M rows ను export చేయడం.

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

## ప్రతి భాగం ఎందుకు

- **Read replica లేదా snapshot.** job ను ఒక follower వైపుకు point చేయండి తద్వారా heavy reads primary పై production writes తో ఎప్పుడూ compete చేయవు. ఒక **snapshot** ఒక stable, point-in-time view ను ఇస్తుంది తద్వారా live data మారుతూ ఉన్నా export consistent గా ఉంటుంది.
- **Keyset pagination, `OFFSET` కాదు.** `OFFSET 10000000` DB ను ప్రతి page కి 10M rows ను scan చేసి discard చేయిస్తుంది — export పై O(n²). Keyset చివరి key ను గుర్తుంచుకుని `WHERE id > :last ORDER BY id LIMIT 5000` చేస్తుంది, ఇది index పై O(1) per page లో rides చేస్తుంది.
- **Throttle.** batches మధ్య sleep చేయండి లేదా rows/sec ను cap చేయండి తద్వారా replica saturate అవ్వదు మరియు replication lag bounded గా ఉంటుంది.
- **Object store కి Stream.** ప్రతి batch ను S3/GCS కి NDJSON లేదా Parquet గా వ్రాయండి; మొత్తం result set ను ఎప్పుడూ memory లోకి load చేయవద్దు. driver rows ను stream చేయడానికి ఒక cursor/server-side cursor వాడండి.

## ఇంటర్వ్యూ దృక్కోణం

మీరు live system ను రక్షిస్తారా అని ఇంటర్వ్యూయర్ check చేస్తారు. ఒక **replica** ను పేర్కొనడం table stakes; senior signal అంటే **keyset over OFFSET** (మరియు O(n²) ఉచ్చును వివరించగలగడం) ప్లస్ **backpressure/throttling** మరియు ఒక snapshot ద్వారా **consistency**. ఒక సాధారణ ఉచ్చు: ఒక transaction లో ఒక్క `SELECT *` — ఇది గంటల పాటు ఒక read view ను తెరిచి ఉంచుతుంది, DB ను ఉబ్బిస్తుంది (long snapshot ఇంకా చూసే rows ను Postgres vacuum clean చేయలేదు), మరియు అంతా memory లో buffer చేస్తుంది.

**Trade-offs:** ఒక replica lag కావచ్చు, కాబట్టి export కొంచెం stale క్షణాన్ని ప్రతిబింబిస్తుంది — సాధారణంగా analytics కి పర్వాలేదు, exact-now data అవసరమైన financial reconciliation కి కాదు. Keyset కి ఒక stable, unique, indexed sort key అవసరం; arbitrary sort orders కి ఇది ఇబ్బంది. table భారీగా ఉండి మీరు storage layer ను కలిగి ఉన్నప్పుడు, ఒక native tool (`pg_dump`, snapshot export to S3, `COPY`) తరచుగా hand-rolled paging ను ఓడిస్తుంది.

Export pipeline

ప్రతి భాగం ఎందుకు

ఇంటర్వ్యూ దృక్కోణం

సంబంధిత ప్రశ్నలు