database चा native bulk-load path वापरा (Postgres COPY, MySQL ), file ला chunks मध्ये विभागून एका मध्ये 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 प्रति row INSERT एक round-trip, एक parse, एक WAL/redo write आणि एक index update 10 कोटी वेळा मोजते. प्रत्येकी 1ms असले तरी तो एक दिवसाहून जास्त आहे. Bulk paths हे सर्व amortise करून जिंकतात: COPY rows एका protocol message मध्ये stream करते, WAL batch करते, आणि per-statement planning skip करते. खऱ्या hardware वर एक single COPY 100k–500k rows/s करते तर INSERT काही हजार.
UNLOGGED WAL पूर्णपणे skip करते), कधीही थेट live table मध्ये नाही. हे load ला readers पासून isolate करते आणि publish आधी validate करू देते.CREATE INDEX एकदाच — bulk मध्ये (sorted) एक index बांधणे 10 कोटी incremental updates पेक्षा खूप स्वस्त आहे.COPY streams चालवा. Throughput I/O आणि CPU सह scale होते जोपर्यंत तुम्ही disk किंवा WAL saturate करत नाही. N ला cores/IOPS शी जुळवा, "शक्य तितके" नाही.INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) ने publish करा जेणेकरून पुन्हा चालवणे कधीही double-insert करत नाही.मुलाखत घेणारा तुम्हाला bulk path अस्तित्वात आहे आणि तो कित्येक पटींनी जलद का आहे हे माहीत आहे का हे तपासतो — COPY syntax नव्हे. चांगले: "COPY वापरा". उत्तम: "UNLOGGED staging table मध्ये COPY, indexes dropped, parallel chunks, नंतर rebuild, publish ला upsert, chunk id ने resumable." classic सापळा म्हणजे INSERTs (किंवा एक ORM saveAll) loop करणे आणि तासाला लागतात हे पाहून आश्चर्य वाटणे; दुसरा सापळा म्हणजे थेट live table मध्ये load करून production block करणे.
maintenance_work_mem/temp space लागते; एक 10 कोटी-row index build disk वर spill होऊ शकतो.सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या