Bagaimana Anda mengimpor 100 juta record CSV ke DB dengan cepat?

Question

IT Interview Practice · Accepted Answer

Gunakan **jalur bulk-load native** database (Postgres `COPY`, MySQL `LOAD DATA`), pecah file menjadi chunk yang dimuat **secara paralel** ke **staging table** dengan index dan constraint **dinonaktifkan**, lalu bangun ulang index sekali dan merge — dan buat seluruh job **idempotent** agar sebuah crash bisa dilanjutkan tanpa menduplikasi baris.

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

## Mengapa INSERT baris-per-baris adalah alat yang salah

Sebuah `INSERT` naif per baris membayar round-trip, parse, write WAL/redo, dan update index **100 juta kali**. Bahkan pada 1ms masing-masing itu lebih dari sehari. Jalur bulk menang dengan mengamortisasi semua ini: `COPY` men-stream baris dalam satu pesan protokol, mem-batch WAL, dan melewati planning per-statement. Pada hardware nyata satu `COPY` melakukan 100k–500k baris/detik versus beberapa ribu untuk INSERT.

## Bagian-bagian yang bergerak

- **Staging table dulu.** Muat ke tabel sekali pakai (`UNLOGGED` di Postgres melewati WAL sepenuhnya), tidak pernah langsung ke tabel live. Ini mengisolasi load dari pembaca dan memungkinkan Anda validasi sebelum publikasi.
- **Nonaktifkan index dan constraint selama load.** Setiap secondary index dan cek FK dievaluasi ulang per baris. Buang, load, lalu `CREATE INDEX` sekali — membangun index secara bulk (tersortir) jauh lebih murah daripada 100 juta update inkremental.
- **Chunk + paralelisasi.** Pecah file berdasarkan byte offset menjadi N potongan dan jalankan N stream `COPY`. Throughput menskala dengan I/O dan CPU sampai Anda menjenuhkan disk atau WAL. Sesuaikan N dengan core/IOPS, bukan "sebanyak mungkin".
- **Idempotent + resumable.** Tandai setiap chunk dengan id; catat chunk mana yang ter-commit. Saat restart, lewati chunk yang selesai. Publikasi dengan `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) agar menjalankan ulang tidak pernah insert ganda.

## Perspektif wawancara

Pewawancara memeriksa apakah Anda tahu **jalur bulk itu ada** dan *mengapa* ia beberapa orde besar lebih cepat — bukan sintaks COPY. Baik: "gunakan COPY". Hebat: "COPY ke UNLOGGED staging table, index dibuang, chunk paralel, bangun ulang setelahnya, upsert untuk publikasi, resumable berdasarkan chunk id." Jebakan klasik adalah loop INSERT (atau ORM `saveAll`) dan terkejut ternyata butuh berjam-jam; jebakan kedua adalah memuat langsung ke tabel live dan memblokir produksi.

## Trade-off & mode kegagalan

- **UNLOGGED / no-WAL berarti tanpa crash recovery** untuk staging table — baik karena ia dapat dibuang, fatal jika Anda melakukannya pada tabel sungguhan.
- **Paralel terlalu tinggi** menggilas disk dan WAL; melewati saturasi throughput *turun*. Benchmark titik optimalnya.
- **Membangun ulang index butuh `maintenance_work_mem`/ruang temp**; build index 100 juta baris bisa spill ke disk.
- **CSV kotor** (encoding buruk, delimiter tertanam) menggagalkan satu chunk penuh — validasi tipe di staging, karantina yang ditolak, jaga load tetap berjalan.

Mengapa INSERT baris-per-baris adalah alat yang salah

Bagian-bagian yang bergerak

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait