Gebruik het native bulk-load-pad van de database (Postgres COPY, MySQL ), splits het bestand in chunks die worden geladen in een met indexen en constraints , herbouw daarna de indexen één keer en merge — en maak de hele job zodat een crash kan hervatten zonder rows te dupliceren.
LOAD DATA100M-row CSV
│ splits op byte-offset
▼
[chunk 1] [chunk 2] ... [chunk N] N parallelle workers
│ │ │
└──── COPY / LOAD DATA (geen indexen) ────▶ staging_table (UNLOGGED)
│
herbouw indexen + valideer
│
INSERT ... SELECT (upsert) naar doel
Een naïeve INSERT per row betaalt een round-trip, een parse, een WAL/redo-write en een index-update 100 miljoen keer. Bij zelfs 1ms elk is dat meer dan een dag. Bulk-paden winnen door dit alles te amortiseren: COPY streamt rows in één protocolbericht, batcht WAL, en slaat per-statement planning over. Op echte hardware doet één COPY 100k–500k rows/s versus een paar duizend voor INSERT.
UNLOGGED in Postgres slaat WAL volledig over), nooit direct in de live tabel. Dit isoleert de load van readers en laat je valideren vóór publicatie.CREATE INDEX één keer — een index in bulk bouwen (gesorteerd) is veel goedkoper dan 100M incrementele updates.COPY-streams. Throughput schaalt met I/O en CPU tot je schijf of WAL verzadigt. Match N aan cores/IOPS, niet "zoveel mogelijk".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) zodat opnieuw draaien nooit dubbel-insert.De interviewer checkt of je weet dat het bulk-pad bestaat en waarom het ordes van grootte sneller is — niet COPY-syntaxis. Goed: "gebruik COPY". Uitstekend: "COPY in een UNLOGGED staging-tabel, indexen gedropt, parallelle chunks, herbouw achteraf, upsert om te publiceren, hervatbaar op chunk-id." De klassieke valkuil is INSERTs loopen (of een ORM saveAll) en verrast zijn dat het uren duurt; de tweede valkuil is direct in de live tabel laden en productie blokkeren.
maintenance_work_mem/temp-ruimte; een 100M-row index-build kan naar schijf spillen.Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren