ตำแหน่งที่ดีที่สุดสำหรับการจัดเก็บไฟล์ไบนารีที่เกี่ยวข้องกับข้อมูลในฐานข้อมูลของคุณคืออะไร? คุณควร:

1. เก็บในฐานข้อมูลด้วย blob
2. เก็บในระบบไฟล์พร้อมลิงค์ในฐานข้อมูล
3. เก็บในระบบไฟล์ แต่เปลี่ยนชื่อเป็นแฮชของเนื้อหาและจัดเก็บแฮชบนฐานข้อมูล
4. บางสิ่งที่ฉันไม่ได้คิด

ข้อดีของ (1) คือ (ในหมู่อื่น ๆ ) ที่มีการเก็บรักษาปรมาณูของการทำธุรกรรม ค่าใช้จ่ายคือคุณอาจเพิ่มความต้องการในการจัดเก็บ (และการสตรีม / สำรองข้อมูลที่เกี่ยวข้อง) เป็นอย่างมาก

เป้าหมายของ (3) คือการรักษาอะตอมมิกให้อยู่ในระดับหนึ่ง - หากคุณสามารถบังคับใช้ว่าระบบไฟล์ที่คุณเขียนไม่อนุญาตให้เปลี่ยนหรือลบไฟล์และมีแฮชที่ถูกต้องเป็นชื่อไฟล์เสมอ ความคิดที่จะเขียนไฟล์ไปยังระบบไฟล์ก่อนที่จะอนุญาตให้มีการแทรก / อัปเดตอ้างอิงแฮ - ถ้าการทำธุรกรรมนี้ล้มเหลวหลังจากระบบไฟล์เขียน แต่ก่อน DML ฐานข้อมูลนั่นเป็นเรื่องดีเพราะระบบไฟล์ 'แกล้ง' เป็นที่เก็บของทั้งหมด ไฟล์และแฮชที่เป็นไปได้ - มันไม่สำคัญว่าจะมีไฟล์บางไฟล์ในนั้นที่ไม่ได้ชี้ไปที่ (และคุณสามารถล้างมันเป็นระยะถ้าคุณระวัง)

แก้ไข:

ดูเหมือนว่า RDBMS บางส่วนจะมีสิ่งนี้ครอบคลุมในแบบของตัวเอง - ฉันสนใจที่จะรู้ว่าคนอื่นทำได้อย่างไร - และโดยเฉพาะอย่างยิ่งในการแก้ปัญหาสำหรับ postgres

1. เก็บในฐานข้อมูลด้วย blob

   ข้อเสียคือทำให้ไฟล์ฐานข้อมูลของคุณมีขนาดใหญ่และอาจใหญ่เกินกว่าจะสำรองข้อมูลด้วยการตั้งค่าปัจจุบันของคุณ ข้อดีคือความซื่อสัตย์และอะตอมมิก

2. เก็บในระบบไฟล์พร้อมลิงค์ในฐานข้อมูล

   ฉันได้เจอกับภัยพิบัติที่น่ากลัวเช่นนี้และมันทำให้ฉันกลัวว่าผู้คนจะแนะนำต่อไป ภัยพิบัติบางอย่างรวมถึง:

   • ผู้ใช้ที่มีสิทธิพิเศษรายหนึ่งที่จะจัดเรียงไฟล์ใหม่และทำลายลิงก์ระหว่างพา ธ ในฐานข้อมูลบ่อยครั้งและพวกเขาอยู่ที่ไหน (แต่อย่างใดนี่กลายเป็นความผิดของฉัน)
   • เมื่อย้ายจากเซิร์ฟเวอร์หนึ่งไปยังเซิร์ฟเวอร์อื่นความเป็นเจ้าของไฟล์บางส่วนก็หายไปเนื่องจาก SID สำหรับบัญชีผู้ดูแลระบบของเครื่องเก่า (เว็บไซต์เก่าทำงานอยู่) ไม่ได้เป็นส่วนหนึ่งของโดเมนดังนั้นไฟล์ที่คัดลอกจึงมี ACL ไม่ได้รับการแก้ไขจึงแสดงผู้ใช้พร้อมท์ชื่อผู้ใช้ / รหัสผ่าน / การเข้าสู่ระบบโดเมน
   • เส้นทางบางเส้นทางสิ้นสุดลงมีความยาวเกิน 256 อักขระจากC:\ทางจนถึง.docและไม่ใช่ทุกเวอร์ชันของ NT ที่สามารถจัดการกับเส้นทางที่ยาวได้

3. เก็บในระบบไฟล์ แต่เปลี่ยนชื่อเป็นแฮชของเนื้อหาและจัดเก็บแฮชบนฐานข้อมูล

   สถานที่สุดท้ายที่ฉันทำงานอยู่ทำตามคำอธิบายของฉันเกี่ยวกับสถานการณ์ข้างต้นทำสิ่งนี้ พวกเขาคิดว่ามันเป็นการประนีประนอมระหว่างองค์กรที่ไม่สามารถที่จะได้รับประสบการณ์กับฐานข้อมูลขนาดใหญ่ (อะไรที่ใหญ่กว่าประมาณ 40G ถูกกำหนดให้เป็น "ใหญ่เกินไป") องค์กรไม่สามารถซื้อฮาร์ดไดรฟ์ขนาดใหญ่ได้ แก้ปัญหาและต้องหลีกเลี่ยงความเสี่ยง # 1 & # 3 ที่ฉันระบุไว้ด้านบน

ความคิดเห็นของฉันคือการจัดเก็บในฐานข้อมูลเป็นหยดเป็นทางออกที่ดีกว่าและปรับขนาดได้มากขึ้นในสถานการณ์หลายเซิร์ฟเวอร์โดยเฉพาะอย่างยิ่งเมื่อเกิดข้อผิดพลาดและปัญหาความพร้อมใช้งาน

หมายเลข 1 เพื่อความสมบูรณ์ของข้อมูล ใช้ตัวเลือกอื่น ๆ หากคุณไม่สนใจคุณภาพของข้อมูล มันง่ายมาก

RDBMS ส่วนใหญ่มีการปรับแต่งสำหรับการจัดเก็บ BLOB (เช่น SQL Server filestream) ต่อไป

ถ้าไปเพื่อ oracle ลองดูที่ dbfs และ Secure Files

Secure Files บอกทุกอย่างให้ข้อมูลทั้งหมดของคุณปลอดภัยในฐานข้อมูล มันถูกจัดระเบียบใน lobs Secure Files เป็น lobs รุ่นทันสมัยที่ควรเปิดใช้งาน

dbfs เป็นระบบไฟล์ในฐานข้อมูล คุณสามารถติดตั้งมันคล้ายกับระบบไฟล์เครือข่ายบนโฮสต์ Linux มันเป็นพลังที่แท้จริง ดูบล็อกนอกจากนี้ยังมีตัวเลือกมากมายเพื่อปรับแต่งตามความต้องการเฉพาะของคุณ ในฐานะที่เป็น dba ได้รับระบบไฟล์ (ขึ้นอยู่กับฐานข้อมูลติดตั้งบน Linux) ฉันสร้างฐานข้อมูล Oracle โดยไม่มีปัญหาใด ๆ (ฐานข้อมูลที่เก็บในฐานข้อมูล ... ) ไม่ใช่ว่ามันจะมีประโยชน์มาก แต่มันจะแสดงพลัง

ข้อดีเพิ่มเติมคือความพร้อมใช้งานการสำรองข้อมูลการกู้คืนการอ่านทั้งหมดสอดคล้องกับข้อมูลเชิงสัมพันธ์อื่น ๆ

บางครั้งขนาดจะถูกกำหนดเป็นเหตุผลที่จะไม่เก็บเอกสารในฐานข้อมูล อาจต้องทำการสำรองข้อมูลด้วยวิธีใด ๆ ดังนั้นจึงไม่ใช่เหตุผลที่ดีที่จะไม่เก็บไว้ในฐานข้อมูล โดยเฉพาะอย่างยิ่งในสถานการณ์ที่ต้องพิจารณาเอกสารเก่าอ่านอย่างเดียวทำให้ง่ายต่อการทำให้ส่วนใหญ่ของฐานข้อมูลอ่านได้อย่างเดียว ในกรณีดังกล่าวส่วนต่างๆของฐานข้อมูลไม่จำเป็นต้องมีการสำรองข้อมูลบ่อยครั้งอีกต่อไป

การอ้างอิงในตารางกับบางสิ่งนอกฐานข้อมูลไม่ปลอดภัย มันสามารถจัดการได้ยากที่จะตรวจสอบและสามารถหลงทางได้ง่าย เกี่ยวกับธุรกรรม ฐานข้อมูลนำเสนอแนวทางแก้ไขสำหรับปัญหาเหล่านี้ทั้งหมด ด้วย Oracle DBFS คุณสามารถให้เอกสารของคุณแก่แอปพลิเคชันที่ไม่ใช่ฐานข้อมูลและพวกเขาจะไม่รู้ด้วยซ้ำว่าพวกมันกำลังโผล่เข้ามาในฐานข้อมูล

สุดท้ายที่น่าประหลาดใจอย่างมากประสิทธิภาพของระบบไฟล์ dbfs มักจะดีกว่าระบบไฟล์ปกติ นี่เป็นจริงโดยเฉพาะอย่างยิ่งหากไฟล์มีขนาดใหญ่กว่าสองสามบล็อก

ฉันคิดว่าคำตอบที่ถูกต้องที่นี่ขึ้นอยู่กับใบสมัครของคุณเป็นอย่างมากและเอกสารเหล่านั้นสำคัญเพียงใด

สำหรับระบบการจัดการเอกสารหรือระบบที่ความสามารถในการกู้คืนเอกสารที่เก็บไว้เป็นสิ่งสำคัญ (ดังนั้นสิ่งที่เกี่ยวข้องกับการเงิน, ทรัพยากรบุคคลหรือ CRM), การจัดเก็บเอกสารแบบอินไลน์หรือการใช้เทคโนโลยีเอกสารที่เป็นกรรมสิทธิ์ของผู้ค้าฐานข้อมูล

อย่างไรก็ตามมีแอพพลิเคชั่นมากมายที่ฉันเชื่อว่าการตัดสินใจตรงกันข้ามนั้นเหมาะสม

ระบบ Helpdesk และระบบประเภท wiki เป็นระบบที่ฉันคิดว่ามันสมเหตุสมผลมากที่จะเก็บข้อมูลออกจากฐานข้อมูล ฉันเชื่อว่าบางคนเช่นจิรามีตัวเลือกให้เลือกว่าคุณต้องการจัดเก็บเอกสารแบบอินไลน์หรือไม่

สำหรับธุรกิจขนาดกลางการจัดเก็บเอกสารสำหรับระบบจำหน่ายตั๋วแบบอินไลน์อาจหมายถึงความแตกต่างระหว่างการสำรองข้อมูลแบบบีบอัดที่วัดเป็นเมกะไบต์และอีกหนึ่งหน่วยวัดเป็นกิกะไบต์

โดยส่วนตัวฉันต้องการที่จะนำระบบการจองตั๋วกลับมาออนไลน์ในอีกไม่กี่นาทีและต่อสู้กับเอกสาร (โดยทั่วไปมีความสำคัญน้อยกว่า) เป็นเวลาสองสามชั่วโมงกว่าเพิ่ม "มันเสียและ CTO หายใจคอของฉัน" RTO โดยต้องกู้คืน และเล่นซ้ำบันทึกจากการสำรองข้อมูลขนาดใหญ่กว่ามาก

มีข้อดีอื่น ๆ ของการแยกเอกสาร

• คุณสามารถเรียกใช้กระบวนการแยกต่างหากที่ทำแค็ตตาล็อกข้อมูลเมตาของเอกสารทำการสแกนไวรัสดำเนินการจัดทำดัชนีคำหลักเป็นต้น
• คุณสามารถใช้ประโยชน์จากเครื่องมือเพื่อช่วยในการสำรองหรือกู้คืน - rsync, สแนปชอตของสตอเรจและอื่น ๆ - ซึ่งให้ประโยชน์กับไฟล์มากกว่าฐานข้อมูล
• คุณสามารถใช้พื้นที่เก็บข้อมูลที่สนับสนุนการบีบอัดหรือการขจัดข้อมูลซ้ำซ้อน (สิ่งที่ผู้ดูแลระบบ SAN ของคุณมีการพูดพล่อยๆเป็นเวลาหลายปี
• สำหรับการติดตั้งในหลาย ๆ ไซต์คุณสามารถเสริมฐานข้อมูลส่วนกลางด้วยระบบไฟล์แบบกระจาย

ฉันคิดว่าชุดค่าผสมแบบผสมของ # 2 และ # 3 อาจชาญฉลาด เก็บชื่อไฟล์ดั้งเดิมไว้ แต่คำนวณและจัดเก็บ hash / checksum ของเอกสารเพื่อให้คุณมีจุดอ้างอิงบางอย่างที่จะช่วยการกู้คืนในกรณีที่มีคนย้ายหรือเปลี่ยนชื่อไฟล์

การจัดเก็บไฟล์ด้วยชื่อไฟล์ดั้งเดิมหมายความว่าแอปพลิเคชันสามารถดึงไฟล์เหล่านั้นโดยตรงจากระบบไฟล์และส่งผ่านสายหรือในโลกไคลเอนต์ที่มีความหนาหรืออาจชี้ผู้ใช้ไปยังเซิร์ฟเวอร์ไฟล์โดยตรง

อย่าทำมัน

จริงๆแล้วมันมีข้อดีที่จะไม่เก็บไฟล์ไว้ในฐานข้อมูล

มันไม่ได้รู้สึกแปลก ๆ และคาวเมื่อคุณคิดกับตัวเองอยู่แล้ว:

ฉันควรเก็บไฟล์ไว้ในฐานข้อมูลหรือระบบไฟล์หรือไม่?

ยิ่งไปกว่านั้นจงพูดออกมาดัง ๆ

ตามข้อเท็จจริง:

การใช้ฐานข้อมูล

" ข้อดี " ... แต่ไม่มาก :

• "Atomicity" ซึ่งถูกต้อง แต่เป็นดาบสองคม เพราะมันลากไปพร้อมกับมัน
• ความสมบูรณ์ เช่นเดียวกับข้างต้น

ฉันไม่ต้องการที่จะลำเอียงจริงๆ แต่ฉันไม่คิดว่าจะมีอะไรเพิ่มเติม ข้อดีไม่ดีนักถ้าคุณคิดเกี่ยวกับมัน

หากฉันลืมความคิดเห็นบางอย่างด้านล่างในขณะเดียวกันโปรดอ่านด้านล่าง

ข้อเสีย:

• เครื่องมือผิดสำหรับงาน
• บำรุงรักษายาก
• ช้า
• ลืมเกี่ยวกับการจัดเก็บหลายร้อย MB / กิกะไบต์ของข้อมูลต่อผู้ใช้
• การสำรองเว็บไซต์ที่เติบโตอย่างรวดเร็วจะเป็นฝันร้าย
• การเรียกคืน / ย้ายจะดูด

การใช้ระบบไฟล์

ข้อดี:

• วิธีบำรุงรักษาง่ายกว่า
• รวดเร็ว
• การสำรองฐานข้อมูลไม่มีส่วนเกี่ยวข้องกับสิ่งนี้
• เนื้อหาที่เบากว่า *

ข้อเสีย :

• ไม่มี*

* พิมพ์ดี

ตอนนี้คุณกำลังถามตัวเองว่าคุณไม่มีข้อเสีย? Howcome?

ข้อผิดพลาดที่ใหญ่ที่สุดที่นี่คือคนพยายามที่จะขันสกรูด้วยค้อน

เหตุผลหลักและฉันต้องการไปเท่าที่จะพูดเท่านั้นด้วยเหตุนี้การที่จะถูกถามเป็นเพราะการเชื่อมโยงไฟล์

นี่เป็นปัญหาที่ฐานข้อมูลไม่ได้มีไว้เพื่อแก้ไข มันฟังดูไร้สาระหากคุณคิดถึงมัน

"ฐานข้อมูลจะแก้ไขปัญหาการเชื่อมโยงไฟล์ของฉัน"

เมื่อในความเป็นจริงแอปพลิเคชันที่มีเหตุผลควรจะรับผิดชอบการจัดการและการให้บริการลิงก์

ทางออก:

1. ทำให้แอปพลิเคชันของคุณจัดการคำขอ URL ด้วยเส้นทางที่กำหนดเอง
2. บันทึกเส้นทางนี้ไปยังฐานข้อมูลของคุณ
3. ภายในทุกครั้งที่เส้นทางนี้เรียกว่า map เป็นไฟล์ที่คุณต้องการ
4. หากคุณย้ายไฟล์ของคุณไปที่อื่นเพียงแค่เปลี่ยนค่าชื่อไฟล์ของเส้นทางและเส้นทางนั้นจะให้บริการไฟล์เดียวกันเสมอไม่ว่าไฟล์จะถูกจัดเก็บหรืออ้างอิงทั่วทั้งเว็บ

สิ่งนี้จะทำให้เส้นทางดั้งเดิมหายไปทำให้แอปพลิเคชั่นพกพาบำรุงรักษาได้ดีขึ้นและอนุญาตให้เปลี่ยนไปใช้ระบบไฟล์ประเภทใดก็ได้โดยไม่ทำลายอะไรเลย

สำหรับวิธีการใช้งานนั้นอยู่นอกเหนือขอบเขตของคำตอบนี้ แต่คุณสามารถดูตัวอย่างทั่วไปในภาษาเว็บที่ใช้กันอย่างแพร่หลาย (PHP):

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

ทั้งสองอย่างรวมกันนั้นทรงพลังจริงๆ

ฉันต้องการเพิ่มประสบการณ์ของฉันที่นี่เพื่อการแลกเปลี่ยน ใน PostgreSQL อย่างน้อยที่สุดผลกระทบต่อประสิทธิภาพค่อนข้างน้อยในแง่ของเซิร์ฟเวอร์ db Blob ขนาดใหญ่จะถูกเก็บไว้ในไฟล์แยกต่างหากไม่ใช่ในตารางฮีปหลักเพื่อย้ายออกจากวิธีการทำงานที่อาจนับจำนวนเรคคอร์ดจำนวนมาก ดีบีเอสอื่น ๆ อาจทำสิ่งที่คล้ายกัน

ข้อได้เปรียบที่สำคัญคือความสามารถในการเก็บข้อมูลที่เกี่ยวข้องทั้งหมดไว้ในที่เดียวเพื่อการปรมาณูและการสำรองข้อมูล สิ่งนี้จะลดโอกาสที่จะเกิดข้อผิดพลาดอย่างมาก

ข้อเสียที่สำคัญไม่ใช่สิ่งที่ฉันได้เห็นข้างต้นและนั่นคือการใช้หน่วยความจำในส่วนหน้า ฉันไม่ทราบว่า db ทุกตัวจัดการสิ่งนี้ได้อย่างไรดังนั้นสิ่งนี้อาจขึ้นอยู่กับการนำไปใช้ แต่สำหรับ PostgreSQL ข้อมูลนั้นจะมาในรูปของสตริง ASCII ที่ใช้ Escape (อาจเป็นเลขฐานสิบหก สิ่งนี้จะต้องถูกแปลงกลับไปเป็นเลขฐานสองในส่วนหน้า เฟรมเวิร์กจำนวนมากที่ฉันได้เห็นในการทำสิ่งนี้เกี่ยวข้องกับการส่งผ่านค่า (ไม่ใช่เป็นการอ้างอิง) จากนั้นสร้างสตริงไบนารีใหม่ที่อ้างอิง ฉันคำนวณว่าการใช้ Perl ในการทำเช่นนี้สิ้นสุดลงโดยใช้หน่วยความจำของไบนารีดั้งเดิมที่ทำให้สำเร็จ

คำตัดสิน: หากไฟล์นั้นถูกเข้าถึงเป็นครั้งคราวเท่านั้นฉันจะเก็บไว้ในฐานข้อมูล หากพวกเขามีการเข้าถึงบ่อยครั้งและซ้ำ ๆ อย่างน้อยกับ PostgreSQL ฉันคิดว่าค่าใช้จ่ายมีประโยชน์มากกว่าประโยชน์

ย้อนกลับไปในวันนี้ Microsoft ได้เพิ่มความสามารถในการจัดเก็บภาพ (และชนิดข้อมูล Blob ที่คล้ายกัน) ในฐานข้อมูล นี่เป็นฟีเจอร์ใหม่ที่ยอดเยี่ยมของ SQL Server 2000 (ฉันค่อนข้างแน่ใจว่ามันคือ 2000 ไม่ใช่ 7.0) และหลาย ๆ คนกระโดดขึ้นไปบน bandwagon

การจัดเก็บ BLOBS ในฐานข้อมูลมีข้อดีและข้อเสีย:

ในอีกด้านหนึ่งข้อมูลและรูปภาพหรือเอกสารที่เกี่ยวข้องทั้งหมดของคุณสามารถจัดเก็บและเข้าถึงได้ในที่เดียว ผู้ใช้แอปพลิเคชันไม่ต้องการสิทธิ์เครือข่ายพิเศษเนื่องจากเป็น SQL ที่แสดงรูปภาพ / ไฟล์ / เอกสาร

ในทางกลับกันฐานข้อมูลของคุณสามารถเติบโตได้ค่อนข้างใหญ่ทั้งนี้ขึ้นอยู่กับขนาดและจำนวนของบล็อกที่คุณจัดเก็บ สิ่งนี้มีผลต่อการสำรองข้อมูลข้อกำหนดในการจัดเก็บข้อมูลการดำเนินการกู้คืนตามเวลาที่ละเอียดอ่อน ฯลฯ

SQL Server 2008 แนะนำการสตรีมไฟล์ ฐานข้อมูลมีตัวชี้ไปยังไฟล์ไฟล์ที่อยู่บนเซิร์ฟเวอร์ไม่ได้อยู่ในฐานข้อมูล แต่เมื่อคุณสำรองฐานข้อมูลไฟล์จะถูกสำรองเช่นกัน

การสำรองข้อมูลของคุณอาจมีขนาดใหญ่ แต่คุณไม่ต้องจบด้วยไฟล์ / เอกสาร / blobs / images

ความชอบส่วนตัวของฉันคือการให้พอยน์เตอร์ที่เก็บฐานข้อมูล / ตำแหน่งเครือข่ายและให้เซิร์ฟเวอร์ไฟล์จัดการกับไฟล์ ไฟล์เซิร์ฟเวอร์ได้รับการปรับให้เหมาะสำหรับงานดังกล่าวต่อไป

อย่าเก็บไฟล์ไว้ในฐานข้อมูล

ทุกคนโดยไม่มีข้อยกเว้นที่สามารถเรียกใช้ RDBMS ใด ๆ ในตลาดมีฐานข้อมูลเฉพาะสำหรับการจัดเก็บไฟล์และ RDBMS เองก็ใช้งานมัน! ฐานข้อมูลที่เป็นระบบแฟ้ม ตอนนี้เราจะมาพูดถึงข้อเสียของการจัดเก็บไฟล์ในฐานข้อมูลรวมถึงปัจจัยบางประการที่มีผลต่อการจัดเก็บไฟล์ในฐานข้อมูล

• ไม่มีfilehandesไปยังไฟล์ในฐานข้อมูล สิ่งนี้หมายความว่า?

  • โปรแกรมเมอร์พูดคุย: คุณไม่สามารถหา ( fseek) ไม่มีความสามารถในการจัดการทรัพยากรที่มีการเข้าถึงแบบอะซิงโครนัส ( asyncioหรือepoll) ไม่มีsendfile(บันทึกสำเนาของคุณจากพื้นที่เคอร์เนล)

  • แอปพลิเคชั่นที่ใช้งานได้: ต้องการส่งวิดีโอหรือรูปภาพไปยังไคลเอนต์ผ่าน HTTP2 / 3 หรือไม่? หากอยู่ในฐานข้อมูลคุณจะต้องค้นหาก่อน สำหรับการสืบค้นใดก็ตามที่ส่งคืนไฟล์นั้นคุณจะต้องรอให้การสืบค้นทั้งหมดสรุปก่อนที่ไฟล์นั้นจะสามารถย้ายไปยังขั้นตอนถัดไปได้ ในการติดตั้งแบบใช้งานจริงด้วย rdbms บนเซิร์ฟเวอร์ที่แตกต่างจากเว็บเซิร์ฟเวอร์อันดับแรกคุณจะต้องถ่ายโอนไฟล์ทั้งหมดจาก rdbms ไปยังเว็บเซิร์ฟเวอร์แทนที่จะสตรีมผ่าน อย่างไรก็ตามหากเลเยอร์การขนส่งให้สิ่งที่เป็นนามธรรมของระบบไฟล์ (ซึ่งแม้แต่ NFS รองรับ) คุณสามารถค้นหาไฟล์ได้ครึ่งทางและเริ่มสตรีมกลับไปยังไคลเอ็นต์ทันทีโดยไม่ต้องบัฟเฟอร์ไฟล์ใด ๆ เกินความจำเป็น สิ่งนี้ทำโดยเว็บเซิร์ฟเวอร์เป็นประจำnginx , Apache , PureFTP และ ProFTP

• คัดลอกสองครั้งบน RDBMS จากข้อเท็จจริงที่ว่ามันอยู่ในฐานข้อมูลคุณอาจจะเขียนสองครั้ง ครั้งเดียวในบันทึกการเขียนล่วงหน้า (WAL) จากนั้นเข้าสู่พื้นที่ตารางอีกครั้ง

• ไม่มีการอัปเดต MVCCหมายถึงไม่มีการอัปเดตคัดลอกใหม่อีกครั้งพร้อมการแก้ไขจากนั้นแถวเก่าจะถูกทำเครื่องหมายว่าหมดอายุ (ลบ) การอัปเดตใด ๆ ในไฟล์จะต้องเขียนทั้งแถวไม่ใช่เฉพาะไฟล์ทั้งแถว ระบบไฟล์สามารถให้ข้อมูลนี้ได้เช่นกันโดยใช้การบันทึกข้อมูล แต่คุณก็ไม่จำเป็นต้องทำเช่นนั้น

• อ่านไฟล์และถ่ายโอนเพื่อชะลอการสืบค้นหากไฟล์ถูกเก็บไว้ในแถวที่คุณต้องการสอบถามทั้งแถวจะต้องรอให้ไฟล์โอนหรือคุณจะต้องออกแบบสอบถามสองชุดแยกกัน .

• การใช้หน่วยความจำบนฐานข้อมูลไคลเอนต์ DB- ไคลเอนต์ (libpq, jdbc, odbc, freetds, ฯลฯ ) หรือสิ่งที่คล้ายกันอาจจะบัฟเฟอร์การสืบค้นในหน่วยความจำ เมื่อบัฟเฟอร์ในหน่วยความจำหมดอาจเริ่มบัฟเฟอร์ดิสก์หรือยิ่งแย่กว่านั้นก็อาจกลับไปที่เคอร์เนลที่จะเพจกับดิสก์

• การสืบค้นปริมาณข้อมูลฐานข้อมูลจำนวนมากให้ความสามารถในการฆ่าและเก็บเกี่ยวแบบสอบถามเมื่อพวกเขาใช้เวลามากเกินไปหรือทรัพยากร โปรดทราบว่าการถ่ายโอนไฟล์จะไม่ถูกแยกรายการ คำค้นหานั้นถูกฆ่าหลังจาก 3 วินาทีหรือไม่ หรือใช้เวลา 1 วินาทีและแบ็คเอนด์ใช้เวลา 2 วินาทีในการถ่ายโอนไฟล์ ไม่ใช่เพียงแค่ "แยกเป็นส่วน ๆ " คุณจะระบุอย่างมีประสิทธิภาพว่าควรใช้เวลานานเท่าใดในการสอบถามเมื่อ 99.9% ของข้อความค้นหาส่งคืน 1 KB และอีกข้อหนึ่งส่งคืน 1 GB

• XFS และ BTRFS ไม่มีการคัดลอกตามการเขียนหรือการลดความซ้ำซ้อนสนับสนุนการคัดลอกบนการเขียนและการทำซ้ำอย่างโปร่งใส ซึ่งหมายความว่ามีภาพเดียวกันทุกที่หรือต้องการสำเนาที่สองของมันสามารถจัดการได้อย่างโปร่งใสโดยระบบไฟล์ อย่างไรก็ตามหากไฟล์นั้นไม่ได้อยู่ในสถานะเดียวและอยู่ในแถวหรือในร้านค้าระบบไฟล์ก็อาจไม่สามารถลดความซ้ำซ้อนได้

• ความซื่อสัตย์ผู้คนจำนวนมากอยู่ที่นี่กำลังพูดถึงความซื่อสัตย์ คุณคิดว่าอะไรดีกว่าในการตรวจจับความเสียหายของระบบไฟล์แอพพลิเคชั่นที่ใช้ระบบไฟล์หรือยูทิลิตี้หลักของระบบไฟล์ จัดเก็บไฟล์ในแถวหรือไม่อยู่ในบรรทัดและระบบไฟล์เสียหายใด ๆ จะถูกบดบังฐานข้อมูล xfs_repairเป็นการดีที่กู้คืนเมื่อคุณมีระบบแฟ้มหรือฮาร์ดไดรฟ์เสียหายและหากล้มเหลวมันจะยังคงง่ายกว่ามากในการทำนิติเวช

• การโอนย้ายระบบคลาวด์หากคุณต้องการจัดเก็บไฟล์บน SAN หรือระบบคลาวด์คุณจะมีความยากลำบากมากขึ้นเพราะตอนนี้การย้ายที่จัดเก็บข้อมูลเป็นการย้ายฐานข้อมูล หากไฟล์ของคุณอยู่เช่นเก็บไว้ในระบบแฟ้มคุณค่อนข้างง่ายสามารถย้ายไปยัง S3 (และกับสิ่งที่ต้องการs3fsก็สามารถโปร่งใส)

ข้อยกเว้น

การจัดเก็บไฟล์ในฐานข้อมูลมีกรณีการใช้งานที่ถูกต้องสองสามกรณี

• เมื่อคุณจำเป็นต้องแก้ไขไฟล์ตามลำดับ นั่นหมายความว่าเป็นส่วนหนึ่งของธุรกรรมของคุณในการแก้ไขไฟล์ หรือคุณต้องการความสามารถในการย้อนกลับแก้ไขไฟล์ถ้าธุรกรรมล้มเหลวสำหรับปัญหาความสมบูรณ์ของข้อมูลในความสัมพันธ์ (ตาราง)
• เมื่อคุณต้องการตรวจสอบให้แน่ใจว่าระบบไฟล์นั้นมีข้อมูลเวอร์ชันที่แม่นยำและคุณไม่สามารถเสี่ยงได้ในการทำให้ข้อมูลตรงกัน
• เมื่อคุณฐานข้อมูลสามารถแจงไฟล์จริงและคุณสามารถค้นหาได้ ใน PostgreSQL นั้นทอปอโลยีสามารถสืบค้นด้วย PostGIS ณ จุดนี้ในขณะที่มันเป็นไฟล์มันก็เป็นข้อมูลสำหรับการสืบค้นและไม่ใช่ที่เก็บข้อมูล

การบรรเทา

• ฐานข้อมูลบางตัวมีแนวคิดเกี่ยวกับ "ทรัพยากรที่มีการจัดการภายนอก" ซึ่งฐานข้อมูลจะจัดการไฟล์แบบส่วนตัวบนดิสก์เช่น

  • PostgreSQL ผ่านโครงสร้างพื้นฐานวัตถุที่มีขนาดใหญ่จัดทำแฟ้มข้อมูลให้กับทรัพยากรในช่วงระยะเวลาของการทำธุรกรรม

  • โครงสร้างพื้นฐาน filestream ของ SQL Server 2017ให้การเข้าถึงชั่วคราวที่จะคงอยู่ตลอดระยะเวลาของการทำธุรกรรมซึ่งคุณสามารถใช้เพื่อรับเส้นทางของไฟล์และเปิดตัวจัดการไฟล์

  • Oracle นำเสนอBFILE(สิ่งนี้ไม่เกี่ยวข้องกับสิ่งที่ลอบภายในซึ่งเรียกว่าSecureFile

• ฐานข้อมูลบางส่วนเก็บวัตถุไบนารีขนาดใหญ่ที่ไม่อยู่ในขอบเขตหรือสามารถเช่น Oracle SecureFile สิ่งนี้อนุญาตให้คุณอัพเดตแถวโดยไม่ต้องเขียนไฟล์ใหม่

• ฐานข้อมูลบางอย่างเช่น Oracle ทำ MVC โดยไม่มีบันทึก WAL และไม่ต้องเขียนไฟล์ซ้ำ

• ฐานข้อมูลบางส่วนเช่น SQL Server และ Oracle ให้ความสามารถในการ "สตรีม" ข้อมูลจากไฟล์โดยไม่ต้องมีไฟล์จัดการ สิ่งนี้อาจหรือไม่ทำงานในการเชื่อมต่อที่แตกต่างจากแบบสอบถามข้อมูล แต่ที่สำคัญคือในขณะที่คุณสามารถสตรีมไฟล์ (ในทางทฤษฎี) ฉันไม่สามารถหาหลักฐานของผลิตภัณฑ์ใด ๆ ที่ไม่ได้ทำโดยผู้ให้บริการที่ใช้คุณสมบัตินั้น ตัวอย่างเช่นสะพาน NGINX / Apache ช่วยให้คุณทำสิ่งนี้ได้ที่ไหน

• Oracle นำเสนอการลดความซ้ำซ้อนการบีบอัดและการเข้ารหัสที่เป็นตัวเลือกผ่านหน่วยความจำภายใน -LOB (เช่น SecureFile)

ข้อสรุป

สถานการณ์กรณีที่เลวร้ายที่สุดเมื่อคุณวางไฟล์ในฐานข้อมูลนั้นแย่มากต่อประสิทธิภาพและความเข้ากันได้กับการใช้เครื่องมือ มันขึ้นอยู่กับการใช้งานเป็นพิเศษเสมอ ไม่ว่าฐานข้อมูลจะดีกว่าในการเป็นระบบไฟล์หรือระบบไฟล์ก็ตาม ในทุก ๆ ทางมันเป็นการประนีประนอมและแม้ว่าคุณจะได้รับฟีเจอร์ลดการใช้งานที่มีประสิทธิภาพ (เช่นกรณีของ SecureFile) การใช้เครื่องมือนั้นแย่มากจนไม่มากไปกว่าจุดการตลาดเว้นแต่สแต็คทั้งหมดของคุณจะถูกสร้างขึ้น

ให้มันง่ายและกฎทั่วไปคือเก็บไฟล์ออกจากฐานข้อมูล

วิธีการแก้

คุณควรจัดเก็บไฟล์หรือทำให้ระบบไฟล์เป็นแบบนามธรรมเพื่อให้ทำงานได้อย่างมีประสิทธิภาพสำหรับผู้เช่าและผู้ใช้หลายคนได้อย่างไร ฉันเป็นบางส่วนเพื่อ hashing เนื้อหาของไฟล์ นี่เป็นเรื่องธรรมดาในทุกวันนี้และใช้งานได้ดี

แม้ว่าบางส่วนจะขึ้นอยู่กับแอปพลิเคชัน / สภาพแวดล้อม (รวมคน) ฉันจะไปสำหรับหยด

การเก็บทุกอย่างไว้ในฐานข้อมูลหมายถึงการจำลองข้อมูลทำงานได้กับข้อมูลไฟล์ คุณต้องการกลไกแยกต่างหากในการซิงโครไนซ์ไฟล์ FS

ในบางแอปพลิเคชันไม่ควรแก้ไขระบบไฟล์ ตัวอย่างเช่นในเว็บไซต์ที่ใช้งานจริงฉันจะหลีกเลี่ยงการใช้ระบบไฟล์สำหรับข้อมูลที่ไม่ใช้แล้วทิ้ง (เว็บไซต์อยู่ภายใต้ SCM ข้อมูลในฐานข้อมูล)

สมมติว่าเรามีผู้ใช้ / แอพพลิเคชั่นหลายตัวที่มีการอนุญาตแยกต่างหากจากนั้นที่เก็บระบบไฟล์ใด ๆ จะให้โอกาสในการเข้าถึง DB และ FS ที่แตกต่างกัน

การปรับแต่งที่ฉันต้องการพิจารณาในการจัดเก็บ BLOB คือการแยกข้อมูลหากเหมาะสม ถ้าคุณต้องการเพียง 512 ไบต์จาก BLOB 20Mb การเข้าถึงแบบเซกเตอร์นี้เป็นประโยชน์อย่างแท้จริงโดยเฉพาะอย่างยิ่งถ้าคุณกำลังติดต่อกับไคลเอนต์ระยะไกล

การลงคะแนนของฉันจะไม่ใช่ เก็บข้อมูลในระบบเช่น Amazon S3 หรือ CDN ของ Microsft และเก็บ URL นั้นในฐานข้อมูล

วิธีนี้คุณจะได้รับความน่าเชื่อถือในการเข้าถึงข้อมูลได้ตลอดเวลาโดยไม่ต้องมีฐานข้อมูลขนาดใหญ่เพื่อจัดการกับมอนสเตอร์

สำหรับ postgres:

ตรงไปตรงมาจริงๆ มีBYTEAประเภทที่สามารถใช้สำหรับการจัดเก็บสตริงไบนารี ตามค่าเริ่มต้นจะไม่มีบิลด์ในการใช้ประโยชน์เหมือนกับที่กล่าวไว้สำหรับ MS หรือ Oracle ดังนั้นการจัดเก็บไฟล์ขนาดใหญ่จำนวนมากและการเรียกดูจึงน่าเบื่อ คุณต้องทำการแปลงไฟล์ภายในแอพพลิเคชั่น (เช่นเดียวกับByteStreamหรือคล้ายกัน แต่ไม่ทราบว่าวิธีการทำงานกับไฟล์ MS / Oracle เฉพาะ <-> โซลูชั่นฐานข้อมูล) นอกจากนี้ยังมีloประเภทที่ช่วยในการจัดการ BLOBs เนื่องจากการจัดการภายในบางประเภทอาจไม่ได้ติดตามการอ้างอิง

แบ่งปันประสบการณ์ของฉันเกี่ยวกับเซิร์ฟเวอร์ MS SQL และไฟล์จำนวนมาก เราบันทึกไฟล์บนเซิร์ฟเวอร์ไฟล์ ฐานข้อมูลมีสองตารางหนึ่งตารางสำหรับโฟลเดอร์ไฟล์และสิทธิการเข้าถึงหนึ่งรายการสำหรับชื่อไฟล์ ง่ายต่อการบำรุงรักษาฐานข้อมูลและไฟล์ คุณสามารถย้ายไฟล์ได้อย่างง่ายดายแม้กระทั่งข้ามเซิร์ฟเวอร์เพียงแค่ต้องปรับเปลี่ยนตารางโฟลเดอร์