database ના native bulk-load path (Postgres COPY, MySQL ) વાપરો, file ને chunks માં split કરો જે indexes અને constraints સાથે માં માં load થાય, પછી indexes એક વાર rebuild કરો અને merge કરો — અને આખા job ને બનાવો જેથી crash rows duplicate કર્યા વગર resume કરી શકે.
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
એક naive INSERT પ્રતિ row એક round-trip, એક parse, એક WAL/redo write અને એક index update 10 કરોડ વાર ચૂકવે છે. દરેક 1ms પર પણ એ એક દિવસ કરતાં વધારે છે. Bulk paths આ બધું amortise કરીને જીતે છે: COPY rows ને એક protocol message માં stream કરે છે, WAL batch કરે છે, અને per-statement planning skip કરે છે. real hardware પર એક જ COPY INSERT ના થોડા હજાર સામે 100k–500k rows/s કરે છે.
UNLOGGED WAL સંપૂર્ણપણે skip કરે), ક્યારેય સીધું live table માં નહીં. આ load ને readers થી isolate કરે છે અને publish કરતાં પહેલાં validate કરવા દે છે.CREATE INDEX એક વાર — bulk માં (sorted) index બનાવવું 100M incremental updates કરતાં ઘણું સસ્તું છે.COPY streams ચલાવો. તમે disk કે WAL saturate ન કરો ત્યાં સુધી throughput I/O અને CPU સાથે scale થાય છે. N ને cores/IOPS સાથે match કરો, "as many as possible" સાથે નહીં.INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) સાથે publish કરો જેથી re-running ક્યારેય double-insert ન કરે.ઇન્ટરવ્યૂઅર તપાસી રહ્યા છે કે તમે જાણો છો કે bulk path અસ્તિત્વમાં છે અને તે અનેક ગણું ઝડપી શા માટે છે — COPY syntax નહીં. Good: "COPY વાપરો". Great: "UNLOGGED staging table માં COPY, indexes dropped, parallel chunks, પછી rebuild, publish કરવા upsert, chunk id વડે resumable." Classic trap એ INSERTs (અથવા ORM saveAll) loop કરવો અને કલાકો લાગે તેથી આશ્ચર્યચકિત થવું; બીજો trap live table માં સીધું load કરી production block કરવો.
maintenance_work_mem/temp space જોઈએ; 100M-row index build disk પર spill થઈ શકે.વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો