आप एक विशाल dataset को live system को प्रभावित किए बिना कैसे export करते हैं?

Question

IT Interview Practice · Accepted Answer

**एक replica या snapshot से पढ़ें (कभी primary नहीं), `OFFSET` के बजाय keyset pagination से page करें, read rate throttle करें, और results को सीधे object storage में stream करें।** लक्ष्य है 50 करोड़ rows को बिना लंबे locks रखे, primary CPU spike किए, या memory उड़ाए 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 करें ताकि भारी reads primary पर production writes से कभी न लड़ें। एक **snapshot** एक stable, point-in-time view देता है ताकि export consistent हो भले ही live data बदलता रहे।
- **Keyset pagination, `OFFSET` नहीं.** `OFFSET 10000000` DB को हर page पर 1 करोड़ 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 सीमित रहे।
- **Object store में stream करें.** हर batch को S3/GCS में NDJSON या Parquet के रूप में लिखें; कभी पूरा result set memory में load न करें। एक cursor/server-side cursor इस्तेमाल करें ताकि driver rows stream करे।

## इंटरव्यू का नज़रिया

Interviewer परखता है कि क्या आप live system की रक्षा करते हैं। एक **replica** नाम लेना table stakes है; senior signal है **keyset over OFFSET** (और O(n²) जाल समझा पाना) plus **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 को एक stable, unique, indexed sort key चाहिए; यह मनमाने sort orders के लिए अटपटा है। जब table विशाल हो और आप storage layer के मालिक हों, एक native tool (`pg_dump`, S3 में snapshot export, `COPY`) अक्सर hand-rolled paging को पीट देता है।

Export pipeline

हर हिस्सा क्यों

इंटरव्यू का नज़रिया

संबंधित प्रश्न