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 spike না করে, বা memory না উড়িয়ে ৫০ কোটি 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 view দেয় যাতে live data বদলাতে থাকলেও export consistent থাকে।
- **Keyset pagination, `OFFSET` নয়.** `OFFSET 10000000` DB-কে প্রতি page-এ ১ কোটি row scan ও discard করায় — export জুড়ে O(n²)। Keyset শেষ key মনে রাখে এবং `WHERE id > :last ORDER BY id LIMIT 5000` করে, যা index-এ চড়ে প্রতি page O(1)।
- **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** নাম ধরে বলা table stakes; senior signal হলো **OFFSET-এর উপর keyset** (এবং O(n²) ফাঁদ ব্যাখ্যা করতে পারা) প্লাস **backpressure/throttling** এবং একটি snapshot-এর মাধ্যমে **consistency**। একটি সাধারণ ফাঁদ: এক transaction-এ একটি একক `SELECT *` — এটি ঘণ্টার পর ঘণ্টা একটি read view খোলা রাখে, DB ফোলায় (Postgres vacuum দীর্ঘ snapshot এখনও দেখা row পরিষ্কার করতে পারে না), এবং সব memory-তে buffer করে।

**ট্রেড-অফ:** একটি replica lag করতে পারে, তাই export একটি সামান্য stale মুহূর্ত প্রতিফলিত করে — সাধারণত analytics-এর জন্য ঠিক, exact-now data প্রয়োজন এমন financial reconciliation-এর জন্য নয়। Keyset-এর একটি স্থিতিশীল, unique, indexed sort key লাগে; নির্বিচার sort order-এর জন্য এটি অস্বস্তিকর। table যখন বিশাল এবং আপনি storage layer-এর মালিক, একটি native tool (`pg_dump`, S3-তে snapshot export, `COPY`) প্রায়ই hand-rolled paging-কে হারায়।

Export pipeline

প্রতিটি অংশ কেন

ইন্টারভিউ দৃষ্টিভঙ্গি

সম্পর্কিত প্রশ্ন