Kif timporta 100M record CSV ġo DB malajr?

Question

IT Interview Practice · Accepted Answer

Uża l-**bulk-load path nattiv** tad-database (Postgres `COPY`, MySQL `LOAD DATA`), aqsam il-file f'chunks mgħobbija **b'mod parallel** ġo **staging table** bl-indexes u l-constraints **diżattivati**, imbagħad erġa' ibni l-indexes darba u agħmel merge — u agħmel ix-xogħol kollu **idempotenti** biex crash ikun jista' jkompli mingħajr ma jidduplika rows.

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

## Għaliex INSERT row-by-row huwa l-għodda ħażina

`INSERT` naïve għal kull row iħallas round-trip, parse, WAL/redo write u index update **100 miljun darba**. Anke b'1ms kull wieħed dan huwa aktar minn ġurnata. Il-bulk paths jirbħu billi jamortizzaw dan kollu: `COPY` jagħmel stream tar-rows f'messaġġ tal-protokoll wieħed, jagħmel batch tal-WAL, u jaqbeż il-planning għal kull statement. Fuq hardware reali `COPY` wieħed jagħmel 100k–500k rows/s versus ftit eluf għal INSERT.

## Il-biċċiet li jiċċaqilqu

- **Staging table l-ewwel.** Għabbi ġo table li tarmi (`UNLOGGED` f'Postgres jaqbeż il-WAL għalkollox), qatt direttament fit-table live. Dan jiżola l-load mir-readers u jħallik tivvalida qabel ma tippubblika.
- **Diżattiva l-indexes u l-constraints waqt il-load.** Kull secondary index u FK check jiġi re-evalwat għal kull row. Warrabhom, għabbi, imbagħad `CREATE INDEX` darba — li tibni index b'mod bulk (issortjat) huwa ħafna irħas minn 100M update inkrementali.
- **Chunk + parallelize.** Aqsam il-file skont il-byte offset f'N biċċiet u ħaddem N `COPY` streams. It-throughput jiskala mal-I/O u CPU sakemm tissatura d-disk jew WAL. Aġġusta N mal-cores/IOPS, mhux "kemm jista' jkun".
- **Idempotenti + resumable.** Immarka kull chunk b'id; irreġistra liema chunks committjaw. Fuq restart, aqbeż chunks lesti. Ippubblika b'`INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert) biex tħaddem mill-ġdid qatt ma jinsertja darbtejn.

## Perspettiva tal-intervista

L-intervistatur qed jiċċekkja jekk tafx li l-**bulk path jeżisti** u *għaliex* huwa ordnijiet ta' kobor aktar mgħaġġel — mhux is-sintassi ta' COPY. Tajjeb: "uża COPY". Eċċellenti: "COPY ġo staging table UNLOGGED, indexes imwarrba, chunks paralleli, erġa' ibni wara, upsert biex tippubblika, resumable bil-chunk id." In-nassa klassika hija li tagħmel loop ta' INSERTs (jew ORM `saveAll`) u tissorprendi ruħek li jieħu sigħat; it-tieni nassa hija li tgħabbi direttament fit-table live u timblokka l-produzzjoni.

## Trade-offs u modi ta' fallimenti

- **UNLOGGED / no-WAL ifisser ebda crash recovery** għat-staging table — tajjeb għax hija disponibbli, fatali jekk għamiltha lit-table reali.
- **Parallel għoli wisq** iħabbat id-disk u WAL; wara s-saturazzjoni t-throughput *jaqa'*. Bbenchmarkja l-punt aħjar.
- **Li terġa' tibni l-indexes teħtieġ `maintenance_work_mem`/temp space**; index build ta' 100M row jista' jinżel għad-disk.
- **CSV maħmuġ** (encoding ħażin, delimiters imdaħħla) ifalli chunk sħiħ — ivvalida t-types fl-istaging, ikkwarantina r-rifjuti, żomm il-load miexi.

Għaliex INSERT row-by-row huwa l-għodda ħażina

Il-biċċiet li jiċċaqilqu

Perspettiva tal-intervista

Trade-offs u modi ta' fallimenti

Mistoqsijiet relatati