Kaip greitai importuoti 100 mln. CSV įrašų į DB?

Question

IT Interview Practice · Accepted Answer

Naudokite duomenų bazės **natyvų bulk-load kelią** (Postgres `COPY`, MySQL `LOAD DATA`), suskaidykite failą į dalis, kraunamas **lygiagrečiai** į **staging lentelę** su išjungtais indeksais ir apribojimais, tada perkurkite indeksus vieną kartą ir sujunkite — ir padarykite visą darbą **idempotentišką**, kad gedimas galėtų tęsti be eilučių dubliavimo.

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

## Kodėl eilutė-po-eilutės INSERT yra netinkamas įrankis

Naivus `INSERT` kiekvienai eilutei moka round-trip, parse, WAL/redo įrašymą ir indekso atnaujinimą **100 milijonų kartų**. Net po 1ms kiekvienam tai virš dienos. Bulk keliai laimi amortizuodami visa tai: `COPY` perduoda eilutes srautu vienoje protokolo žinutėje, grupuoja WAL ir praleidžia sakinių planavimą. Ant realios aparatinės įrangos vienas `COPY` daro 100k–500k eilučių/s prieš keletą tūkstančių INSERT.

## Judančios dalys

- **Staging lentelė pirma.** Kraukite į vienkartinę lentelę (`UNLOGGED` Postgres visiškai praleidžia WAL), niekada tiesiai į gyvą lentelę. Tai izoliuoja krovimą nuo skaitytojų ir leidžia patikrinti prieš publikuojant.
- **Išjunkite indeksus ir apribojimus krovimo metu.** Kiekvienas antrinis indeksas ir FK patikra iš naujo įvertinama kiekvienai eilutei. Numeskite juos, kraukite, tada `CREATE INDEX` vieną kartą — indekso kūrimas grupine forma (surūšiuotas) yra kur kas pigesnis nei 100 mln. inkrementinių atnaujinimų.
- **Chunk + lygiagretinkite.** Suskaidykite failą pagal byte offset į N dalių ir vykdykite N `COPY` srautų. Throughput skalinasi su I/O ir CPU, kol prisotinate diską ar WAL. Derinkite N prie branduolių/IOPS, ne „kiek įmanoma daugiau".
- **Idempotentiška + tęsiama.** Pažymėkite kiekvieną chunk id; įrašykite, kurie chunk patvirtinti. Perkrovus, praleiskite atliktus chunk. Publikuokite su `INSERT ... ON CONFLICT DO NOTHING/UPDATE` (upsert), kad perleidimas niekada nedvigubintų.

## Interviu perspektyva

Interviuotojas tikrina, ar žinote, kad **bulk kelias egzistuoja** ir *kodėl* jis tvarkos dydžiais greitesnis — ne COPY sintaksę. Gerai: „naudokite COPY". Puikiai: „COPY į UNLOGGED staging lentelę, indeksai numesti, lygiagretūs chunk, perkurti po to, upsert publikavimui, tęsiama pagal chunk id." Klasikiniai spąstai — INSERT ciklas (ar ORM `saveAll`) ir nustebimas, kad tai užtrunka valandas; antri spąstai — krovimas tiesiai į gyvą lentelę ir produkcijos blokavimas.

## Kompromisai ir gedimai

- **UNLOGGED / no-WAL reiškia jokio crash recovery** staging lentelei — tinka, nes ji vienkartinė, mirtina, jei tai padarėte tikrai lentelei.
- **Per didelis lygiagretumas** daužo diską ir WAL; už prisotinimo ribos throughput *krenta*. Išmatuokite optimalų tašką.
- **Indeksų perkūrimui reikia `maintenance_work_mem`/temp erdvės**; 100 mln. eilučių indekso kūrimas gali persipilti į diską.
- **Nešvarus CSV** (bloga koduotė, įterpti skirtukai) sugadina visą chunk — patikrinkite tipus staging, karantinuokite atmetimus, laikykite krovimą judantį.

Kodėl eilutė-po-eilutės INSERT yra netinkamas įrankis

Judančios dalys

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai