ਤੁਸੀਂ live system ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਵਿਸ਼ਾਲ dataset ਕਿਵੇਂ export ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

**ਇੱਕ replica ਜਾਂ snapshot ਤੋਂ ਪੜ੍ਹੋ (ਕਦੇ primary ਤੋਂ ਨਹੀਂ), `OFFSET` ਦੀ ਬਜਾਏ keyset pagination ਨਾਲ page ਕਰੋ, read rate ਨੂੰ throttle ਕਰੋ, ਅਤੇ ਨਤੀਜੇ ਸਿੱਧਾ object storage ਵਿੱਚ stream ਕਰੋ।** ਟੀਚਾ 500M rows export ਕਰਨਾ ਹੈ ਬਿਨਾਂ long locks ਰੱਖੇ, primary CPU spike ਕੀਤੇ, ਜਾਂ memory ਉਡਾਏ।

## 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 ਕਰੋ ਤਾਂ ਜੋ ਭਾਰੀ reads ਕਦੇ primary ਉੱਤੇ production writes ਨਾਲ ਮੁਕਾਬਲਾ ਨਾ ਕਰਨ। ਇੱਕ **snapshot** ਇੱਕ stable, point-in-time view ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ export consistent ਹੋਵੇ ਭਾਵੇਂ live data ਬਦਲਦੀ ਰਹੇ।
- **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 ਉੱਤੇ ਹਰ page O(1) ਵਿੱਚ ਸਵਾਰ ਹੁੰਦਾ ਹੈ।
- **Throttle.** batches ਵਿਚਕਾਰ sleep ਕਰੋ ਜਾਂ rows/sec cap ਕਰੋ ਤਾਂ ਜੋ replica saturate ਨਾ ਹੋਵੇ ਅਤੇ replication lag bounded ਰਹੇ।
- **Object store ਵਿੱਚ stream ਕਰੋ.** ਹਰ batch ਨੂੰ S3/GCS ਵਿੱਚ NDJSON ਜਾਂ Parquet ਵਜੋਂ ਲਿਖੋ; ਕਦੇ ਪੂਰੇ result set ਨੂੰ memory ਵਿੱਚ load ਨਾ ਕਰੋ। ਇੱਕ cursor/server-side cursor ਵਰਤੋ ਤਾਂ ਜੋ driver rows ਨੂੰ stream ਕਰੇ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ live system ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹੋ। ਇੱਕ **replica** ਦਾ ਨਾਂ ਲੈਣਾ table stakes ਹੈ; senior signal **OFFSET ਉੱਤੇ keyset** (ਅਤੇ O(n²) ਫੰਦਾ ਸਮਝਾ ਸਕਣਾ) ਨਾਲ ਹੀ **backpressure/throttling** ਅਤੇ ਇੱਕ snapshot ਰਾਹੀਂ **consistency** ਹੈ। ਇੱਕ ਆਮ ਫੰਦਾ: ਇੱਕ transaction ਵਿੱਚ ਇੱਕ single `SELECT *` — ਇਹ ਘੰਟਿਆਂ ਲਈ ਇੱਕ read view ਖੁੱਲ੍ਹਾ ਰੱਖਦਾ ਹੈ, DB ਨੂੰ bloat ਕਰਦਾ ਹੈ (Postgres vacuum ਉਹਨਾਂ rows ਨੂੰ clean ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ long snapshot ਅਜੇ ਵੀ ਦੇਖਦਾ ਹੈ), ਅਤੇ ਸਭ ਕੁਝ 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`, S3 ਵੱਲ snapshot export, `COPY`) ਅਕਸਰ hand-rolled paging ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ।

Export pipeline

ਹਰ ਹਿੱਸਾ ਕਿਉਂ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਸੰਬੰਧਿਤ ਸਵਾਲ