live system लाई असर नगरी विशाल dataset कसरी export गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

**replica वा snapshot बाट पढ्नुहोस् (कहिल्यै primary बाट होइन), `OFFSET` को सट्टा keyset pagination ले page गर्नुहोस्, read rate throttle गर्नुहोस्, र नतिजा सिधै object storage मा stream गर्नुहोस्।** लक्ष्य लामो lock नराखी, primary CPU नबढाई, वा memory नफुटाई 50 करोड row 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 तिर पोइन्ट गर्नुहोस् ताकि भारी read कहिल्यै primary मा production write सँग नलडोस्। **snapshot** ले स्थिर, point-in-time दृश्य दिन्छ ताकि live data बदलिरहँदा पनि export consistent होस्।
- **Keyset pagination, `OFFSET` होइन.** `OFFSET 10000000` ले DB लाई हरेक page मा 1 करोड row scan र discard गर्न लगाउँछ — export भरि O(n²)। Keyset ले अन्तिम key सम्झन्छ र `WHERE id > :last ORDER BY id LIMIT 5000` गर्छ, जुन प्रति page O(1) मा index मा सवार हुन्छ।
- **Throttle.** batch बीच sleep गर्नुहोस् वा row/sec cap गर्नुहोस् ताकि replica saturate नहोस् र replication lag सीमित रहोस्।
- **Object store मा stream.** प्रत्येक batch S3/GCS मा NDJSON वा Parquet को रूपमा लेख्नुहोस्; कहिल्यै सम्पूर्ण result set memory मा load नगर्नुहोस्। row stream गर्न cursor/server-side cursor प्रयोग गर्नुहोस्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले live system जोगाउनुहुन्छ कि जाँच्छन्। **replica** नाम दिनु आधारभूत हो; senior संकेत **OFFSET भन्दा keyset** (र O(n²) जाल व्याख्या गर्न सक्नु) साथै **backpressure/throttling** र snapshot मार्फत **consistency** हो। एउटा साधारण जाल: एउटै transaction मा एउटा `SELECT *` — यसले घण्टौं read view खुला राख्छ, DB फुलाउँछ (लामो snapshot ले देख्ने row Postgres vacuum ले सफा गर्न सक्दैन), र सबै memory मा buffer गर्छ।

**ट्रेड-अफ:** replica lag हुन सक्छ, त्यसैले export अलि stale क्षण झल्काउँछ — analytics का लागि प्रायः ठीक, तर exact-now data चाहिने financial reconciliation का लागि होइन। Keyset लाई स्थिर, unique, indexed sort key चाहिन्छ; arbitrary sort order का लागि अप्ठ्यारो हुन्छ। table विशाल हुँदा र तपाईं storage layer आफैँ मालिक हुँदा, एउटा native tool (`pg_dump`, S3 मा snapshot export, `COPY`) प्रायः hand-rolled paging लाई जित्छ।

Export pipeline

किन प्रत्येक भाग

अन्तर्वार्ता दृष्टिकोण

सम्बन्धित प्रश्नहरू