live system-ஐ பாதிக்காமல் ஒரு பெரிய dataset-ஐ எப்படி export செய்வீர்கள்?

Question

IT Interview Practice · Accepted Answer

**ஒரு replica அல்லது snapshot-இலிருந்து படியுங்கள் (ஒருபோதும் primary அல்ல), `OFFSET`-க்குப் பதிலாக keyset pagination-உடன் page செய்யுங்கள், read rate-ஐ throttle செய்யுங்கள், மேலும் results-ஐ நேரடியாக object storage-க்கு stream செய்யுங்கள்.** நீண்ட locks வைத்திருக்காமல், primary CPU-ஐ spike செய்யாமல், அல்லது memory-ஐ வெடிக்கச் செய்யாமல் 500M rows-ஐ 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 செய்யுங்கள், இதனால் heavy reads ஒருபோதும் primary மீது production writes-உடன் போட்டியிடாது. ஒரு **snapshot** ஒரு நிலையான, point-in-time view தருகிறது, இதனால் live data தொடர்ந்து மாறினாலும் export consistent-ஆக இருக்கிறது.
- **Keyset pagination, `OFFSET` அல்ல.** `OFFSET 10000000` DB-ஐ ஒவ்வொரு page-இலும் 10M rows-ஐ scan செய்து நிராகரிக்கச் செய்கிறது — export முழுவதும் O(n²). Keyset கடைசி key-ஐ நினைவில் வைத்து `WHERE id > :last ORDER BY id LIMIT 5000` செய்கிறது, இது index-ஐ ஒரு page-க்கு O(1)-இல் ride செய்கிறது.
- **Throttle.** batches-க்கு இடையே sleep செய்யுங்கள் அல்லது rows/sec-ஐ cap செய்யுங்கள், இதனால் replica saturate ஆகாது மற்றும் replication lag bounded-ஆக இருக்கிறது.
- **object store-க்கு Stream செய்.** ஒவ்வொரு batch-ஐயும் S3/GCS-க்கு NDJSON அல்லது Parquet ஆக எழுதுங்கள்; முழு result set-ஐயும் ஒருபோதும் memory-க்குள் load செய்யாதீர்கள். driver rows-ஐ stream செய்ய ஒரு cursor/server-side cursor பயன்படுத்துங்கள்.

## நேர்காணல் கண்ணோட்டம்

நீங்கள் live system-ஐப் பாதுகாக்கிறீர்களா என்று நேர்காணல் செய்பவர் சரிபார்க்கிறார். ஒரு **replica** குறிப்பிடுவது table stakes; senior சமிக்ஞை **OFFSET மீது keyset** (மற்றும் O(n²) பொறியை விளக்க முடிவது) மற்றும் **backpressure/throttling** மற்றும் ஒரு snapshot மூலம் **consistency**. ஒரு பொதுவான பொறி: ஒரே transaction-இல் ஒரே `SELECT *` — இது ஒரு read view-ஐ மணிநேரம் திறந்து வைத்து, DB-ஐ bloat செய்து (நீண்ட snapshot இன்னும் பார்க்கும் rows-ஐ Postgres vacuum சுத்தம் செய்ய முடியாது), மற்றும் எல்லாவற்றையும் memory-இல் buffer செய்கிறது.

**சமரசங்கள்:** ஒரு replica lag ஆகலாம், எனவே export சற்று stale தருணத்தைப் பிரதிபலிக்கிறது — வழக்கமாக analytics-க்கு பரவாயில்லை, exact-now data தேவைப்படும் financial reconciliation-க்கு அல்ல. Keyset-க்கு ஒரு நிலையான, unique, indexed sort key தேவை; arbitrary sort orders-க்கு அது awkward. table மிகப் பெரியதாக இருந்து நீங்கள் storage layer-ஐ சொந்தமாக்கும்போது, ஒரு native tool (`pg_dump`, S3-க்கு snapshot export, `COPY`) அடிக்கடி hand-rolled paging-ஐ வெல்கிறது.

Export pipeline

ஏன் ஒவ்வொரு பகுதி

நேர்காணல் கண்ணோட்டம்

தொடர்புடைய கேள்விகள்