live system वर परिणाम न करता एक प्रचंड dataset तुम्ही कसा export कराल?

Question

IT Interview Practice · Accepted Answer

**एका replica किंवा snapshot मधून वाचा (कधीही primary नाही), `OFFSET` ऐवजी keyset pagination ने page करा, read rate throttle करा, आणि results थेट object storage ला stream करा.** ध्येय म्हणजे long locks न धरता, primary CPU spike न करता, किंवा memory न फुगवता 50 कोटी 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 वर 1 कोटी rows scan करून टाकायला लावते — export वर O(n²). Keyset शेवटची key लक्षात ठेवते आणि `WHERE id > :last ORDER BY id LIMIT 5000` करते, जे index वर rides, प्रति 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 करते.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्ही live system चे रक्षण करता का हे तपासतो. एक **replica** नावाने सांगणे table stakes आहे; senior signal म्हणजे **keyset over OFFSET** (आणि O(n²) सापळा समजावता येणे) अधिक **backpressure/throttling** आणि एका snapshot द्वारे **consistency**. एक सामान्य सापळा: एका transaction मध्ये एकच `SELECT *` — तो तासभर एक read view उघडा ठेवतो, DB फुगवतो (long snapshot अजून पाहत असलेल्या rows Postgres vacuum साफ करू शकत नाही), आणि सर्व काही memory मध्ये buffer करतो.

**तडजोडी:** एक replica मागे राहू शकतो, म्हणून export किंचित stale क्षण दर्शवतो — analytics साठी सहसा ठीक, exact-now data लागणाऱ्या financial reconciliation साठी नाही. Keyset ला एक स्थिर, unique, indexed sort key लागते; arbitrary sort orders साठी ते अवघड आहे. table प्रचंड असेल आणि तुम्ही storage layer च्या मालकीचे असाल, तेव्हा एक native tool (`pg_dump`, S3 ला snapshot export, `COPY`) अनेकदा hand-rolled paging ला हरवते.

Export pipeline

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

मुलाखतीचा दृष्टिकोन

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