database-এর native bulk-load path (Postgres COPY, MySQL ) ব্যবহার করুন, file-কে chunk-এ split করুন যা index ও constraint সহ একটি -এ load হয়, তারপর একবার index পুনর্নির্মাণ করে 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
একটি naive per-row INSERT একটি round-trip, একটি parse, একটি WAL/redo write এবং একটি index update দেয় ১০ কোটি বার। প্রতিটিতে মাত্র ১ms হলেও এটি একদিনের বেশি। Bulk path এসব amortise করে জেতে: COPY এক protocol message-এ row stream করে, WAL batch করে, এবং per-statement planning skip করে। বাস্তব hardware-এ একটি একক COPY INSERT-এর কয়েক হাজারের বিপরীতে ১ লক্ষ–৫ লক্ষ row/s করে।
UNLOGGED WAL পুরোপুরি skip করে), কখনও সরাসরি live table-এ নয়। এটি load-কে reader থেকে আলাদা করে এবং publish করার আগে validate করতে দেয়।CREATE INDEX করুন — bulk-এ (sorted) একটি index তৈরি করা ১০ কোটি incremental update-এর চেয়ে অনেক সস্তা।COPY stream চালান। Throughput I/O ও CPU-এর সঙ্গে scale করে যতক্ষণ না disk বা WAL saturate করেন। "যত বেশি সম্ভব" নয়, core/IOPS-এর সঙ্গে N মেলান।INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) দিয়ে publish করুন যাতে পুনরায় চালানো কখনও double-insert না করে।ইন্টারভিউয়ার যাচাই করছেন আপনি জানেন কিনা bulk path বিদ্যমান এবং কেন এটি বহু গুণ দ্রুত — COPY syntax নয়। ভালো: "COPY ব্যবহার করুন।" দারুণ: "একটি UNLOGGED staging table-এ COPY, index dropped, parallel chunk, পরে rebuild, publish-এ upsert, chunk id দিয়ে resumable।" ক্লাসিক ফাঁদ হলো INSERT loop করা (বা একটি ORM saveAll) এবং এতে ঘণ্টা লাগায় অবাক হওয়া; দ্বিতীয় ফাঁদ হলো সরাসরি live table-এ load করে production block করা।
maintenance_work_mem/temp space লাগে; একটি ১০ কোটি-row index build disk-এ spill করতে পারে।বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন