ਤੁਸੀਂ 10 ਕਰੋੜ CSV records ਨੂੰ ਇੱਕ DB ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਕਿਵੇਂ import ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

database ਦਾ **native bulk-load path** (Postgres `COPY`, MySQL `LOAD DATA`) ਵਰਤੋ, file ਨੂੰ chunks ਵਿੱਚ ਵੰਡੋ ਜੋ **parallel** ਵਿੱਚ ਇੱਕ **staging table** ਵਿੱਚ load ਹੋਣ ਜਿਸਦੇ indexes ਅਤੇ constraints **disabled** ਹੋਣ, ਫਿਰ 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 ਗਲਤ tool ਕਿਉਂ ਹੈ

ਇੱਕ naive per-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 skip ਕਰਦਾ ਹੈ। ਅਸਲੀ hardware ਉੱਤੇ ਇੱਕ single `COPY` INSERT ਦੇ ਕੁਝ ਹਜ਼ਾਰ ਦੇ ਮੁਕਾਬਲੇ 100k–500k rows/s ਕਰਦਾ ਹੈ।

## ਹਿੱਸੇ

- **ਪਹਿਲਾਂ Staging table.** ਇੱਕ throwaway table ਵਿੱਚ load ਕਰੋ (Postgres ਵਿੱਚ `UNLOGGED` WAL ਪੂਰੀ ਤਰ੍ਹਾਂ skip ਕਰਦਾ ਹੈ), ਕਦੇ ਸਿੱਧਾ live table ਵਿੱਚ ਨਹੀਂ। ਇਹ load ਨੂੰ readers ਤੋਂ isolate ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ publish ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ validate ਕਰਨ ਦਿੰਦਾ ਹੈ।
- **Load ਦੌਰਾਨ indexes ਅਤੇ constraints disable ਕਰੋ.** ਹਰ secondary index ਅਤੇ FK check ਹਰ row ਲਈ ਦੁਬਾਰਾ evaluate ਹੁੰਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ drop ਕਰੋ, load ਕਰੋ, ਫਿਰ `CREATE INDEX` ਇੱਕ ਵਾਰ ਕਰੋ — bulk ਵਿੱਚ (sorted) ਇੱਕ index ਬਣਾਉਣਾ 10 ਕਰੋੜ incremental updates ਤੋਂ ਕਿਤੇ ਸਸਤਾ ਹੈ।
- **Chunk + parallelise.** file ਨੂੰ byte offset ਨਾਲ N ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡੋ ਅਤੇ N `COPY` streams ਚਲਾਓ। Throughput I/O ਅਤੇ CPU ਨਾਲ scale ਕਰਦੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ disk ਜਾਂ WAL saturate ਨਹੀਂ ਕਰਦੇ। N ਨੂੰ cores/IOPS ਨਾਲ match ਕਰੋ, "ਜਿੰਨੇ ਹੋ ਸਕੇ ਓਨੇ" ਨਾਲ ਨਹੀਂ।
- **Idempotent + resumable.** ਹਰ chunk ਨੂੰ ਇੱਕ id ਨਾਲ tag ਕਰੋ; record ਕਰੋ ਕਿਹੜੇ chunks commit ਹੋਏ। restart ਉੱਤੇ, done chunks skip ਕਰੋ। `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) ਨਾਲ publish ਕਰੋ ਤਾਂ ਜੋ ਦੁਬਾਰਾ ਚਲਾਉਣ ਨਾਲ ਕਦੇ double-insert ਨਾ ਹੋਵੇ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਚੈੱਕ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ **bulk path ਮੌਜੂਦ ਹੈ** ਅਤੇ *ਕਿਉਂ* ਇਹ ਕਈ ਗੁਣਾ ਤੇਜ਼ ਹੈ — COPY syntax ਨਹੀਂ। ਵਧੀਆ: "COPY ਵਰਤੋ"। ਸ਼ਾਨਦਾਰ: "ਇੱਕ UNLOGGED staging table ਵਿੱਚ COPY, indexes dropped, parallel chunks, ਬਾਅਦ ਵਿੱਚ rebuild, publish ਲਈ upsert, chunk id ਨਾਲ resumable।" Classic ਫੰਦਾ ਹੈ INSERTs (ਜਾਂ ਇੱਕ ORM `saveAll`) loop ਕਰਨਾ ਅਤੇ ਹੈਰਾਨ ਹੋਣਾ ਕਿ ਇਸ ਨੂੰ ਘੰਟੇ ਲੱਗਦੇ ਹਨ; ਦੂਜਾ ਫੰਦਾ ਸਿੱਧਾ live table ਵਿੱਚ load ਕਰਨਾ ਅਤੇ production block ਕਰਨਾ ਹੈ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **UNLOGGED / no-WAL ਦਾ ਮਤਲਬ staging table ਲਈ ਕੋਈ crash recovery ਨਹੀਂ** — ਠੀਕ ਹੈ ਕਿਉਂਕਿ ਇਹ disposable ਹੈ, ਘਾਤਕ ਜੇ ਤੁਸੀਂ ਇਹ real table ਨੂੰ ਕੀਤਾ।
- **Parallel ਬਹੁਤ ਜ਼ਿਆਦਾ** disk ਅਤੇ WAL ਨੂੰ thrash ਕਰਦਾ ਹੈ; saturation ਤੋਂ ਅੱਗੇ throughput *ਘਟ* ਜਾਂਦੀ ਹੈ। sweet spot benchmark ਕਰੋ।
- **Indexes ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ `maintenance_work_mem`/temp space ਦੀ ਲੋੜ ਹੈ**; ਇੱਕ 100M-row index build disk ਉੱਤੇ spill ਹੋ ਸਕਦਾ ਹੈ।
- **Dirty CSV** (ਮਾੜੀ encoding, embedded delimiters) ਇੱਕ ਪੂਰੇ chunk ਨੂੰ fail ਕਰਦੀ ਹੈ — staging ਵਿੱਚ types validate ਕਰੋ, rejects quarantine ਕਰੋ, load ਜਾਰੀ ਰੱਖੋ।

row-by-row INSERT ਗਲਤ tool ਕਿਉਂ ਹੈ

ਹਿੱਸੇ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ