Kepiye sampeyan ngimpor 100 yuta record CSV menyang DB kanthi cepet?

Question

IT Interview Practice · Accepted Answer

Nganggo **jalur bulk-load asli** database (Postgres `COPY`, MySQL `LOAD DATA`), pisah file dadi bagian sing dimuat **paralel** menyang **staging table** kanthi indeks lan constraint **dipatèni**, banjur bangun maneh indeks sepisan lan gabungake — lan gawe kabeh job **idempotent** supaya crash bisa nerusake tanpa ndobelke row.

```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
```

## Kenapa INSERT baris-per-baris minangka alat sing salah

`INSERT` naif saben row mbayar round-trip, parse, tulisan WAL/redo lan update indeks **100 yuta kaping**. Sanajan mung 1ms saben-e, iku luwih saka sedina. Jalur bulk menang kanthi ngamortisasi kabeh iki: `COPY` nge-stream row ing siji pesen protokol, batch WAL, lan nglewati planning saben-statement. Ing hardware nyata, siji `COPY` nglakoni 100rb–500rb row/detik dibandhing sawetara ewu kanggo INSERT.

## Bagian-bagian sing gerak

- **Staging table dhisik.** Muat menyang tabel buangan (`UNLOGGED` ing Postgres nglewati WAL babar pisan), aja tau langsung menyang tabel langsung. Iki misahake beban saka pamaca lan ngidini sampeyan validasi sadurunge publikasi.
- **Patèni indeks lan constraint sajrone muat.** Saben indeks sekunder lan pamriksan FK dievaluasi maneh saben row. Buwang, muat, banjur `CREATE INDEX` sepisan — mbangun indeks kanthi bulk (urut) luwih murah adoh tinimbang 100 yuta update inkremental.
- **Chunk + paralelisasi.** Pisah file miturut byte offset dadi N potong lan mlakokake N stream `COPY`. Throughput nyekala karo I/O lan CPU nganti sampeyan njenuhi disk utawa WAL. Cocogake N karo core/IOPS, dudu "sakakehe sing bisa".
- **Idempotent + bisa dilanjutake.** Tandhani saben chunk nganggo id; cathet chunk endi sing komit. Nalika restart, lewati chunk sing rampung. Publikasi nganggo `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) supaya njalanake maneh ora tau nyisipake pindho.

## Sudut pandang wawancara

Pewawancara mriksa apa sampeyan ngerti **jalur bulk ana** lan *kenapa* iku orde-orde luwih cepet — dudu sintaks COPY. Apik: "nganggo COPY". Apik banget: "COPY menyang staging table UNLOGGED, indeks dibuwang, chunk paralel, bangun maneh sawise, upsert kanggo publikasi, bisa dilanjutake miturut id chunk." Jebakan klasik yaiku looping INSERT (utawa ORM `saveAll`) lan kaget yen butuh pirang-pirang jam; jebakan kapindho yaiku muat langsung menyang tabel langsung lan nge-blok produksi.

## Trade-off & mode kegagalan

- **UNLOGGED / tanpa WAL tegese ora ana crash recovery** kanggo staging table — apik amarga bisa dibuwang, fatal yen sampeyan nglakoni kuwi ing tabel nyata.
- **Paralel kedhuwuren** ngoyak-oyak disk lan WAL; sawise jenuh throughput *mudhun*. Benchmark titik manis.
- **Mbangun maneh indeks butuh `maintenance_work_mem`/ruang temp**; mbangun indeks 100 yuta row bisa tumpah menyang disk.
- **CSV reged** (encoding ala, delimiter tertanam) nggagalake sakabehing chunk — validasi jinis ing staging, karantina tolakan, jaga muat tetep mlaku.

Kenapa INSERT baris-per-baris minangka alat sing salah

Bagian-bagian sing gerak

Sudut pandang wawancara

Trade-off & mode kegagalan

Pitakon sing gegandhengan