Koristite nativni bulk-load put baze (Postgres COPY, MySQL LOAD DATA), podijelite datoteku u dijelove učitane u s onemogućenim indeksima i ograničenjima, zatim ponovno izgradite indekse jednom i spojite — i učinite cijeli posao tako da pad može nastaviti bez dupliciranja redaka.
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
Naivan INSERT po retku plaća round-trip, parse, WAL/redo upis i ažuriranje indeksa 100 milijuna puta. Čak i pri 1 ms svako, to je više od dana. Bulk putevi pobjeđuju amortiziranjem svega toga: COPY streama retke u jednoj protokolarnoj poruci, batchira WAL i preskače planiranje po naredbi. Na stvarnom hardveru jedan COPY radi 100k–500k redaka/s naspram nekoliko tisuća za INSERT.
UNLOGGED u Postgresu potpuno preskače WAL), nikad izravno u živu tablicu. To izolira učitavanje od čitatelja i omogućuje validaciju prije objave.CREATE INDEX jednom — izgradnja indeksa u bulku (sortirano) daleko je jeftinija od 100 milijuna inkrementalnih ažuriranja.COPY streamova. Throughput skalira s I/O i CPU-om dok ne zasitite disk ili WAL. Uskladite N s jezgrama/IOPS, ne "koliko god moguće".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) tako da ponovno pokretanje nikad dvaput ne umeće.Ispitivač provjerava znate li da bulk put postoji i zašto je nekoliko redova veličine brži — ne COPY sintaksu. Dobro: "koristi COPY". Odlično: "COPY u UNLOGGED staging tablicu, izbačeni indeksi, paralelni chunkovi, ponovna izgradnja nakon, upsert za objavu, nastavljivo po chunk id-u." Klasična zamka je petlja INSERT-ova (ili ORM saveAll) i iznenađenje da traje satima; druga zamka je učitavanje izravno u živu tablicu i blokiranje produkcije.
maintenance_work_mem/temp prostor; izgradnja indeksa od 100 milijuna redaka može se preliti na disk.Knjižnica IT pitanja za razgovore za posao s detaljnim odgovorima — od Juniora do Seniora.
Doniraj