Brug databasens native bulk-load-path (Postgres COPY, MySQL ), split filen i chunks loadet ind i en med indexes og constraints , genopbyg derefter indexes én gang og merge — og gør hele jobbet , så et crash kan genoptage uden at duplikere rows.
Brug databasens native bulk-load-path (Postgres COPY, MySQL ), split filen i chunks loadet ind i en med indexes og constraints , genopbyg derefter indexes én gang og merge — og gør hele jobbet , så et crash kan genoptage uden at duplikere rows.
LOAD DATA100M-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
Et naivt INSERT pr. row betaler en round-trip, en parse, en WAL/redo-write og en index-update 100 millioner gange. Ved bare 1ms hver er det over et døgn. Bulk-paths vinder ved at amortisere alt dette: COPY streamer rows i én protokolbesked, batcher WAL, og springer per-statement-planlægning over. På ægte hardware laver en enkelt COPY 100k–500k rows/s versus nogle få tusinde for INSERT.
UNLOGGED i Postgres springer WAL helt over), aldrig direkte ind i live-tabellen. Dette isolerer loadet fra readers og lader dig validere før publicering.CREATE INDEX én gang — at bygge et index i bulk (sorteret) er langt billigere end 100M inkrementelle updates.COPY-streams. Throughput skalerer med I/O og CPU indtil du mætter disk eller WAL. Match N til cores/IOPS, ikke "så mange som muligt".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) så genkørsel aldrig dobbelt-inserter.Intervieweren tjekker, om du ved, at bulk-pathen findes og hvorfor den er størrelsesordener hurtigere — ikke COPY-syntaks. Godt: "brug COPY". Fremragende: "COPY ind i en UNLOGGED staging-tabel, indexes droppet, parallelle chunks, genopbyg bagefter, upsert for at publicere, resumable efter chunk-id." Den klassiske fælde er at loope INSERTs (eller en ORM saveAll) og blive overrasket over, at det tager timer; den anden fælde er at loade direkte ind i live-tabellen og blokere produktion.
maintenance_work_mem/temp-plads; en 100M-row index-build kan spilde til disk.Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér