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 INSERT per row ஒரு round-trip, ஒரு parse, ஒரு WAL/redo write மற்றும் ஒரு index update-ஐ 100 மில்லியன் முறை செலுத்துகிறது. ஒவ்வொன்றுக்கும் 1ms என்றாலும் அது ஒரு நாளுக்கு மேல். Bulk paths இவை அனைத்தையும் amortise செய்வதன் மூலம் வெல்கின்றன: COPY rows-ஐ ஒரே protocol message-இல் stream செய்து, WAL-ஐ batch செய்து, per-statement planning-ஐ skip செய்கிறது. உண்மையான hardware-இல் ஒரே COPY 100k–500k rows/s செய்கிறது, INSERT-க்கான சில ஆயிரங்களுக்கு எதிராக.
UNLOGGED WAL-ஐ முழுவதுமாக skip செய்கிறது) load செய்யுங்கள், ஒருபோதும் live table-க்குள் நேரடியாக அல்ல. இது load-ஐ readers-இலிருந்து தனிமைப்படுத்தி, publish செய்வதற்கு முன் validate செய்ய அனுமதிக்கிறது.CREATE INDEX ஒருமுறை — bulk-இல் ஒரு index கட்டுவது (sorted) 100M incremental updates-ஐ விட மிக மலிவானது.COPY streams இயக்குங்கள். disk அல்லது WAL-ஐ saturate செய்யும் வரை Throughput I/O மற்றும் CPU உடன் அளவிடுகிறது. N-ஐ cores/IOPS-க்குப் பொருத்துங்கள், "முடிந்தவரை பல" அல்ல.INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) உடன் publish செய்யுங்கள், இதனால் மீண்டும் இயக்குவது ஒருபோதும் double-insert செய்யாது.நேர்காணல் செய்பவர் bulk path உள்ளது என்பதையும் அது ஏன் பல மடங்கு வேகமானது என்பதையும் நீங்கள் அறிவீர்களா என்று சரிபார்க்கிறார் — COPY syntax அல்ல. நல்லது: "COPY பயன்படுத்து". சிறந்தது: "indexes drop செய்யப்பட்ட ஒரு UNLOGGED staging table-க்குள் COPY, parallel chunks, பிறகு rebuild, publish செய்ய upsert, chunk id மூலம் resumable." classic பொறி INSERTs-ஐ loop செய்வது (அல்லது ஒரு ORM saveAll) மற்றும் அது மணிநேரம் எடுப்பதைக் கண்டு ஆச்சரியப்படுவது; இரண்டாவது பொறி நேரடியாக live table-க்குள் load செய்து production-ஐத் தடுப்பது.
maintenance_work_mem/temp space தேவை; ஒரு 100M-row index build disk-க்கு spill ஆகலாம்.விரிவான பதில்களுடன் கூடிய IT நேர்காணல் கேள்விகளின் நூலகம் — Junior முதல் Senior வரை.
நன்கொடை