Tumia native bulk-load path ya database (Postgres COPY, MySQL ), gawanya file kuwa chunks zinazoloadiwa kwenye yenye indexes na constraints , kisha jenga upya indexes mara moja na merge — na fanya kazi nzima iwe ili crash iweze kuendelea bila kurudia 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
INSERT ya kila row hulipa round-trip, parse, WAL/redo write na index update mara milioni 100. Hata kwa 1ms kila moja hiyo ni zaidi ya siku. Bulk paths hushinda kwa kuamortize haya yote: COPY hustream rows katika protocol message moja, hubatch WAL, na huruka per-statement planning. Kwenye hardware halisi COPY moja hufanya rows 100k–500k/sekunde dhidi ya elfu chache kwa INSERT.
UNLOGGED katika Postgres huruka WAL kabisa), kamwe si moja kwa moja kwenye live table. Hii huitenga load na readers na hukuruhusu kuthibitisha kabla ya kuchapisha.CREATE INDEX mara moja — kujenga index kwa bulk (sorted) ni nafuu zaidi kuliko updates 100M za incremental.COPY. Throughput huscale na I/O na CPU hadi ujaze disk au WAL. Linganisha N na cores/IOPS, si "nyingi iwezekanavyo".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) ili kuendesha tena kamwe kusi-double-insert.Mhojiwa anakagua kama unajua bulk path ipo na kwa nini ni haraka mara nyingi zaidi — si COPY syntax. Nzuri: "tumia COPY". Bora sana: "COPY kwenye UNLOGGED staging table, indexes zimeondolewa, parallel chunks, jenga upya baadaye, upsert kuchapisha, resumable kwa chunk id." Mtego wa kawaida ni loop ya INSERTs (au ORM saveAll) na kushangaa inachukua masaa; mtego wa pili ni kuload moja kwa moja kwenye live table na kuzuia production.
maintenance_work_mem/temp space; kujenga index ya 100M rows kunaweza kuspill kwenda disk.Maktaba ya maswali ya mahojiano ya IT yenye majibu ya kina — kutoka Junior hadi Senior.
Changia