آپ ایک بڑا dataset live system کو متاثر کیے بغیر کیسے export کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**ایک replica یا snapshot سے پڑھیں (کبھی primary سے نہیں)، `OFFSET` کے بجائے keyset pagination سے page کریں، read rate throttle کریں، اور نتائج سیدھا object storage میں stream کریں۔** مقصد 500M rows export کرنا ہے بغیر طویل 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 کی طرف مقرر کریں تاکہ بھاری reads کبھی primary پر production writes سے مقابلہ نہ کریں۔ ایک **snapshot** ایک مستحکم، point-in-time view دیتا ہے تاکہ export مطابق رہے چاہے 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 محدود کریں تاکہ replica saturate نہ ہو اور replication lag محدود رہے۔
- **Object store میں stream کریں۔** ہر batch کو S3/GCS پر NDJSON یا Parquet کے طور پر لکھیں؛ کبھی پورا result set memory میں load نہ کریں۔ ایک cursor/server-side cursor استعمال کریں تاکہ driver rows stream کرے۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ کیا آپ live system کی حفاظت کرتے ہیں۔ ایک **replica** کا نام لینا بنیادی بات ہے؛ senior signal **OFFSET پر keyset** (اور O(n²) جال بیان کر سکنا) کے ساتھ **backpressure/throttling** اور ایک snapshot کے ذریعے **consistency** ہے۔ ایک عام جال: ایک transaction میں ایک واحد `SELECT *` — یہ گھنٹوں کے لیے ایک read view کھلا رکھتا ہے، DB کو پھلاتا ہے (Postgres vacuum اُن rows کو صاف نہیں کر سکتا جنہیں طویل snapshot اب بھی دیکھتا ہے)، اور سب کچھ memory میں buffer کرتا ہے۔

**توازن:** ایک replica lag کر سکتا ہے، لہٰذا export ایک قدرے stale لمحہ ظاہر کرتا ہے — analytics کے لیے عموماً ٹھیک، exact-now data چاہنے والے financial reconciliation کے لیے نہیں۔ Keyset کو ایک مستحکم، منفرد، indexed sort key چاہیے؛ یہ arbitrary sort orders کے لیے مشکل ہے۔ جب table بہت بڑی ہو اور آپ storage layer کے مالک ہوں، ایک native tool (`pg_dump`، S3 میں snapshot export، `COPY`) اکثر hand-rolled paging کو مات دیتا ہے۔

Export pipeline

ہر حصہ کیوں

انٹرویو کا نقطۂ نظر

متعلقہ سوالات