Bruk databasens native bulk-load-sti (Postgres COPY, MySQL ), del filen i chunks lastet inn i en med indekser og constraints , gjenoppbygg deretter indekser én gang og merge — og gjør hele jobben slik at en krasj kan gjenoppta uten å duplisere rader.
LOAD DATA100M-rads CSV
│ del på byte-offset
▼
[chunk 1] [chunk 2] ... [chunk N] N parallelle workere
│ │ │
└──── COPY / LOAD DATA (ingen indekser) ────▶ staging_table (UNLOGGED)
│
gjenoppbygg indekser + valider
│
INSERT ... SELECT (upsert) inn i target
En naiv INSERT per rad betaler en round-trip, en parse, en WAL/redo-write og en indeks-oppdatering 100 millioner ganger. Ved selv 1ms hver er det over en dag. Bulk-stier vinner ved å amortisere alt dette: COPY streamer rader i én protokollmelding, batcher WAL, og hopper over per-setnings planlegging. På reell maskinvare gjør en enkelt COPY 100k–500k rader/s versus noen få tusen for INSERT.
UNLOGGED i Postgres hopper over WAL helt), aldri rett inn i live-tabellen. Dette isolerer lastingen fra lesere og lar deg validere før publisering.CREATE INDEX én gang — å bygge en indeks i bulk (sortert) er langt billigere enn 100M inkrementelle oppdateringer.COPY-strømmer. Throughput skalerer med I/O og CPU til du metter disk eller WAL. Match N til cores/IOPS, ikke "så mange som mulig".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) slik at re-kjøring aldri dobbeltinserter.Intervjueren sjekker om du vet at bulk-stien eksisterer og hvorfor den er størrelsesordener raskere — ikke COPY-syntaks. Bra: "bruk COPY". Utmerket: "COPY inn i en UNLOGGED staging-tabell, indekser droppet, parallelle chunks, gjenoppbygg etterpå, upsert for å publisere, gjenopptagbar på chunk-id." Den klassiske fellen er å loope INSERT-er (eller en ORM saveAll) og bli overrasket over at det tar timer; den andre fellen er å laste direkte inn i live-tabellen og blokkere produksjon.
maintenance_work_mem/temp-plass; en 100M-rads indeks-bygging kan spille over til disk.Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner