Miten tuot 100M CSV-tietuetta tietokantaan nopeasti?

Question

IT Interview Practice · Accepted Answer

Käytä tietokannan **natiivia bulk-load-polkua** (Postgres `COPY`, MySQL `LOAD DATA`), pilko tiedosto paloihin, jotka ladataan **rinnakkain** **staging-tauluun**, jonka indeksit ja constraintit ovat **poistettuina käytöstä**, rakenna sitten indeksit kerran ja yhdistä — ja tee koko työstä **idempotentti**, jotta kaatuminen voi jatkaa ilman rivien duplikointia.

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

## Miksi rivi-riviltä INSERT on väärä työkalu

Naiivi `INSERT` per rivi maksaa edestakaisen matkan, parsinnan, WAL/redo-kirjoituksen ja indeksipäivityksen **100 miljoonaa kertaa**. Jopa 1 ms kutakin kohti tuo yli vuorokauden. Bulk-polut voittavat amortisoimalla tämän kaiken: `COPY` striimaa rivit yhdessä protokollaviestissä, batchaa WAL:n ja ohittaa per-lause-suunnittelun. Oikealla raudalla yksittäinen `COPY` tekee 100k–500k riviä/s verrattuna muutamaan tuhanteen INSERTille.

## Liikkuvat osat

- **Staging-taulu ensin.** Lataa kertakäyttötauluun (`UNLOGGED` Postgresissa ohittaa WAL:n kokonaan), älä koskaan suoraan live-tauluun. Tämä eristää latauksen lukijoista ja antaa sinun validoida ennen julkaisua.
- **Poista indeksit ja constraintit käytöstä latauksen ajaksi.** Jokainen sekundaari-indeksi ja FK-tarkistus arvioidaan uudelleen per rivi. Pudota ne, lataa, sitten `CREATE INDEX` kerran — indeksin rakentaminen bulkkina (lajiteltuna) on paljon halvempaa kuin 100M inkrementaalista päivitystä.
- **Pilko + rinnakkaista.** Pilko tiedosto tavu-offsetin mukaan N palaan ja aja N `COPY`-striimiä. Throughput skaalautuu I/O:n ja CPU:n mukaan, kunnes saturoit levyn tai WAL:n. Sovita N ytimiin/IOPS:iin, ei "niin monta kuin mahdollista".
- **Idempotentti + jatkettavissa.** Merkitse jokainen pala id:llä; kirjaa mitkä palat committoituivat. Uudelleenkäynnistyksessä ohita valmiit palat. Julkaise `INSERT ... ON CONFLICT DO NOTHING/UPDATE`:lla (upsert), jottei uudelleenajo koskaan lisää kahdesti.

## Haastattelunäkökulma

Haastattelija tarkistaa, tiedätkö että **bulk-polku on olemassa** ja *miksi* se on suuruusluokkia nopeampi — ei COPY-syntaksia. Hyvä: "käytä COPY:ä". Loistava: "COPY UNLOGGED-staging-tauluun, indeksit pudotettuna, rinnakkaiset palat, rakenna jälkeenpäin, upsert julkaisuun, jatkettavissa pala-id:llä." Klassinen ansa on INSERTtien silmukointi (tai ORM:n `saveAll`) ja yllättyä, että se kestää tunteja; toinen ansa on lataaminen suoraan live-tauluun ja tuotannon estäminen.

## Kompromissit ja virhetilanteet

- **UNLOGGED / ei-WAL tarkoittaa ei kaatumispalautusta** staging-taululle — ok koska se on kertakäyttöinen, kohtalokasta jos teit sen oikealle taululle.
- **Liian korkea rinnakkaisuus** hakkaa levyä ja WAL:ia; saturaation jälkeen throughput *laskee*. Benchmarkkaa makea piste.
- **Indeksien uudelleenrakennus tarvitsee `maintenance_work_mem`/temp-tilaa**; 100M rivin indeksirakennus voi valua levylle.
- **Likainen CSV** (huono enkoodaus, upotetut erottimet) kaataa kokonaisen palan — validoi tyypit stagingissa, karanteenoi hylätyt, pidä lataus liikkeessä.

Miksi rivi-riviltä INSERT on väärä työkalu

Liikkuvat osat

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset