તમે live system ને અસર કર્યા વગર વિશાળ dataset કેવી રીતે export કરશો?

Question

IT Interview Practice · Accepted Answer

**replica અથવા snapshot માંથી વાંચો (ક્યારેય primary નહીં), `OFFSET` ને બદલે keyset pagination વડે page કરો, read rate throttle કરો, અને results ને સીધા object storage પર stream કરો.** goal એ 500M rows ને long 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 કરો જેથી heavy reads ક્યારેય primary પર production writes સાથે compete ન કરે. એક **snapshot** stable, point-in-time view આપે છે જેથી live data બદલાતું રહે તોય export consistent રહે.
- **Keyset pagination, `OFFSET` નહીં.** `OFFSET 10000000` DB ને દર page 10M rows scan અને discard કરાવે છે — 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 ન કરો. cursor/server-side cursor વાપરો જેથી driver rows stream કરે.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર તપાસે છે કે તમે live system ને protect કરો છો. એક **replica** નું નામ આપવું table stakes છે; senior signal એ **keyset over OFFSET** (અને O(n²) trap સમજાવવાની ક્ષમતા) વત્તા **backpressure/throttling** અને snapshot વડે **consistency** છે. સામાન્ય trap: એક transaction માં એક જ `SELECT *` — તે કલાકો સુધી read view ખુલ્લો રાખે છે, DB ને bloat કરે છે (Postgres vacuum એ rows clean કરી શકતું નથી જે long snapshot હજુ જુએ છે), અને બધું memory માં buffer કરે છે.

**Trade-offs:** replica lag કરી શકે, તેથી export સહેજ stale moment પ્રતિબિંબિત કરે છે — analytics માટે સામાન્ય રીતે ઠીક, exact-now data જોઈતું financial reconciliation માટે નહીં. Keyset ને stable, unique, indexed sort key જોઈએ; arbitrary sort orders માટે તે awkward છે. જ્યારે table વિશાળ હોય અને તમે storage layer ના owner હો, ત્યારે native tool (`pg_dump`, snapshot export to S3, `COPY`) ઘણી વાર hand-rolled paging ને હરાવે છે.

Export pipeline

દરેક ભાગ શા માટે

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

સંબંધિત પ્રશ્નો