آپ 10 کروڑ CSV records کو DB میں تیزی سے کیسے import کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

database کا **native bulk-load path** (Postgres `COPY`، MySQL `LOAD DATA`) استعمال کریں، file کو chunks میں تقسیم کریں جو **متوازی** طور پر ایک **staging table** میں load ہوں جہاں indexes اور constraints **غیر فعال** ہوں، پھر ایک بار indexes rebuild کریں اور merge کریں — اور پورے job کو **idempotent** بنائیں تاکہ ایک crash rows دوہرائے بغیر resume کر سکے۔

```text
100M-row CSV
     │ split by byte offset
     ▼
[chunk 1] [chunk 2] ... [chunk N]     N parallel workers
     │        │             │
     └──── COPY / LOAD DATA (no indexes) ────▶ staging_table (UNLOGGED)
                                                    │
                                          rebuild indexes + validate
                                                    │
                                    INSERT ... SELECT (upsert) into target
```

## Row-by-row INSERT غلط اوزار کیوں ہے

ایک سادہ فی row `INSERT` ایک round-trip، ایک parse، ایک WAL/redo write اور ایک index update **10 کروڑ بار** ادا کرتا ہے۔ ہر ایک پر صرف 1ms پر بھی یہ ایک دن سے زیادہ ہے۔ Bulk paths یہ سب amortise کر کے جیتتے ہیں: `COPY` rows کو ایک protocol message میں stream کرتا ہے، WAL batch کرتا ہے، اور per-statement planning چھوڑ دیتا ہے۔ حقیقی hardware پر ایک واحد `COPY` 100k–500k rows/s کرتا ہے بمقابلہ INSERT کے چند ہزار۔

## moving parts

- **پہلے staging table۔** ایک throwaway table میں load کریں (Postgres میں `UNLOGGED` WAL کو مکمل چھوڑ دیتا ہے)، کبھی سیدھا live table میں نہیں۔ یہ load کو readers سے الگ کرتا ہے اور آپ کو publish کرنے سے پہلے validate کرنے دیتا ہے۔
- **Load کے دوران indexes اور constraints غیر فعال کریں۔** ہر secondary index اور FK check فی row دوبارہ evaluate ہوتا ہے۔ انہیں drop کریں، load کریں، پھر ایک بار `CREATE INDEX` کریں — ایک index کو bulk میں (sorted) بنانا 10 کروڑ incremental updates سے کہیں سستا ہے۔
- **Chunk + parallelise۔** file کو byte offset سے N ٹکڑوں میں تقسیم کریں اور N `COPY` streams چلائیں۔ Throughput I/O اور CPU کے ساتھ scale ہوتا ہے جب تک آپ disk یا WAL saturate نہ کریں۔ N کو cores/IOPS سے میل کھائیں، "جتنے ممکن ہو" سے نہیں۔
- **Idempotent + resumable۔** ہر chunk کو ایک id سے tag کریں؛ record کریں کہ کون سے chunks commit ہوئے۔ restart پر، done chunks چھوڑ دیں۔ `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) سے publish کریں تاکہ دوبارہ چلانا کبھی double-insert نہ کرے۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ کیا آپ جانتے ہیں کہ **bulk path موجود ہے** اور *کیوں* یہ کئی درجے تیز ہے — نہ کہ COPY syntax۔ اچھا: "COPY استعمال کرو۔" عمدہ: "ایک UNLOGGED staging table میں COPY، indexes گرائے ہوئے، parallel chunks، بعد میں rebuild، publish کے لیے upsert، chunk id سے resumable۔" کلاسک جال looping INSERTs (یا ایک ORM `saveAll`) ہے اور یہ حیران ہونا کہ اس میں گھنٹے لگتے ہیں؛ دوسرا جال سیدھا live table میں load کرنا اور production بلاک کرنا ہے۔

## توازن اور ناکامی کے طریقے

- **UNLOGGED / no-WAL کا مطلب** staging table کے لیے **کوئی crash recovery نہیں** — ٹھیک کیونکہ یہ disposable ہے، مہلک اگر آپ نے یہ اصل table پر کیا۔
- **Parallel بہت زیادہ** disk اور WAL کو thrash کرتا ہے؛ saturation کے بعد throughput *گر جاتا ہے*۔ sweet spot benchmark کریں۔
- **Indexes rebuild کرنے کو `maintenance_work_mem`/temp space چاہیے**؛ ایک 10 کروڑ row index build disk پر spill کر سکتا ہے۔
- **گندا CSV** (خراب encoding، embedded delimiters) ایک پورا chunk ناکام کرتا ہے — staging میں types validate کریں، rejects quarantine کریں، load کو چلتا رکھیں۔

Row-by-row INSERT غلط اوزار کیوں ہے

moving parts

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات