database को native bulk-load path (Postgres COPY, MySQL ) प्रयोग गर्नुहोस्, file लाई chunk मा विभाजन गरी रूपमा index र constraint गरिएको मा load गर्नुहोस्, अनि index एक पटक rebuild गरी merge गर्नुहोस् — र सम्पूर्ण job लाई बनाउनुहोस् ताकि crash ले row 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
प्रति row एउटा naive INSERT ले एउटा round-trip, एउटा parse, एउटा WAL/redo write र एउटा index update 10 करोड पटक तिर्छ। प्रति 1ms मा पनि यो एक दिनभन्दा बढी हो। Bulk path ले यी सबै amortise गरेर जित्छ: COPY ले row लाई एउटा protocol message मा stream गर्छ, WAL batch गर्छ, र प्रति-statement planning skip गर्छ। वास्तविक hardware मा एउटै COPY ले 100k–500k row/s गर्छ, INSERT को केही हजार को तुलनामा।
UNLOGGED ले WAL पूरै skip गर्छ) मा load गर्नुहोस्। यसले load लाई reader बाट अलग गर्छ र publish अघि validate गर्न दिन्छ।CREATE INDEX एक पटक — bulk मा (sorted) index बनाउनु 10 करोड incremental update भन्दा धेरै सस्तो छ।COPY stream चलाउनुहोस्। disk वा WAL saturate नभएसम्म throughput I/O र CPU सँग scale हुन्छ। N लाई "जति सक्दो धेरै" होइन, core/IOPS सँग मिलाउनुहोस्।INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) ले publish गर्नुहोस् ताकि पुनः-चलाउँदा कहिल्यै double-insert नहोस्।अन्तर्वार्ताकारले तपाईंले bulk path अवस्थित छ भन्ने र किन यो धेरै गुणा छिटो छ जान्नुहुन्छ कि जाँच्दै हुन्छन् — COPY syntax होइन। राम्रो: "COPY प्रयोग गर"। उत्कृष्ट: "index drop गरिएको UNLOGGED staging table मा COPY, parallel chunk, पछि rebuild, publish गर्न upsert, chunk id ले resumable।" classic जाल INSERT loop गर्नु (वा ORM saveAll) र घण्टौं लाग्दा छक्क पर्नु हो; दोस्रो जाल live table मा सिधै load गरेर production block गर्नु हो।
maintenance_work_mem/temp space चाहिन्छ; 10 करोड-row index build disk मा spill हुन सक्छ।विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्