จัดเก็บรูปภาพเป็นไฟล์หรือในฐานข้อมูลสำหรับเว็บแอป?


125

คำถามของฉันค่อนข้างทั่วไปและฉันรู้ว่าอาจไม่มีคำตอบ 100% ฉันกำลังสร้างโซลูชันเว็บ ASP .NET ซึ่งจะมีรูปภาพจำนวนมากและหวังว่าจะมีปริมาณการใช้งานที่เหมาะสม ฉันต้องการบรรลุประสิทธิภาพจริงๆ

ฉันควรบันทึกรูปภาพในฐานข้อมูลหรือในระบบไฟล์? และไม่ว่าคำตอบนั้นฉันสนใจมากขึ้นว่าทำไมต้องเลือกวิธีที่เฉพาะเจาะจง

ขอบคุณมาก Stefan

ซ้ำซ้อน : การจัดเก็บภาพใน DB - ใช่หรือไม่? , วิธีจัดเก็บภาพในระบบไฟล์ของคุณ , การจัดเก็บภาพจำนวนน้อย: blob หรือ fs? และอาจเป็นอื่น ๆ


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

  • ฉันจะใช้โซลูชันที่โฮสต์ฉันมีพื้นที่เก็บข้อมูลจำนวนมาก (10gb) แต่มีเพียง 300MB สำหรับฐานข้อมูล จะมีค่าใช้จ่ายมากสำหรับพื้นที่จัดเก็บเพิ่มเติมในฐานข้อมูล

  • ฉันไม่ใช่ผู้เชี่ยวชาญด้าน DB และไม่ได้ควบคุมการตั้งค่าของ DB ด้วย โซลูชันที่ใช้ฐานข้อมูลอาจต้องการการกำหนดค่าแบบกำหนดเองตามที่ดูเหมือน

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


1
โปรดระบุฐานข้อมูลที่คุณใช้
Gerrie Schenck

1
ฉันตั้งใจจะใช้ MSSQL เวอร์ชันที่ใหม่กว่า
StefanE

1
@StefanE ระบบไฟล์เป็นไปตามเจตนาและวัตถุประสงค์ทั้งหมดฐานข้อมูลพิเศษที่ปรับให้เหมาะสมสำหรับการจัดเก็บไฟล์
LukeH

คำตอบ:


175

จัดเก็บรูปภาพในระบบไฟล์และตำแหน่งรูปภาพในฐานข้อมูล

ทำไม? เพราะ...

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

1
นอกจากนี้ใน SQL Server เมื่อคุณจัดเก็บอิมเมจเป็นฟิลด์ "Image" นี่คือสิ่งที่ SQL กำลังทำอย่างมีประสิทธิภาพนั่นคือการจัดเก็บตัวชี้ไปยังไฟล์บนดิสก์ที่ใดที่หนึ่ง นี่คือวิธีที่จะได้รับประมาณ 8KB page limit
Zhaph - Ben Duguid

9
สิ่งนี้ได้รับการแก้ไขแล้วคือ SQL Server 2008 มีการเปิดตัวประเภทใหม่ FILESTREAM technet.microsoft.com/en-us/library/bb895234.aspxซึ่งอนุญาตให้ใช้ประโยชน์จาก "ประสิทธิภาพของระบบไฟล์และในขณะเดียวกันก็รักษา ความสอดคล้องของธุรกรรมระหว่างข้อมูลที่ไม่มีโครงสร้างและข้อมูลที่มีโครงสร้างที่สอดคล้องกัน "
kristof

ใช่คุณทำถูกแล้ว คำถามของฉันคือขนาดของหยดคืออะไร? หรือเก็บหน่วยความจำได้มากแค่ไหน?
Ameer

11

ในโปรเจ็กต์ที่เพิ่งพัฒนาของฉันฉันเก็บรูปภาพ (และเอกสารไบนารีทุกชนิด) ไว้เป็นคอลัมน์รูปภาพในตารางฐานข้อมูล

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

เมื่อใช้เทคโนโลยีในปัจจุบันฉันขอแนะนำให้คุณเก็บภาพในคอลัมน์ SQL Server 2008 FILESTREAM (อย่างน้อยนั่นคือสิ่งที่ฉันกำลังจะทำกับโปรเจ็กต์ถัดไปของฉัน) เนื่องจากพวกเขารวมข้อดีของการจัดเก็บข้อมูลในฐานข้อมูลและการมีไบนารีขนาดใหญ่ในไฟล์แยกกัน (ที่ น้อยที่สุดตามโฆษณา;))


คุณได้ทดสอบการทำงานของ Filestream หรือยัง?
StefanE

1
จริงๆแล้วเมื่อลบ DB record สามารถเข้ารหัสเพื่อลบจากระบบไฟล์ได้ด้วย ดังนั้นฉันคิดว่าดีที่จะจัดเก็บใน FS แทนที่จะเป็น DB
kailash19


6

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

เมื่อให้บริการแสดงผล <img src = ไปยังไฟล์ที่มีอยู่แล้วบนเซิร์ฟเวอร์น่าจะเร็วกว่าการสร้างไฟล์ชั่วคราวจากฟิลด์ฐานข้อมูลและชี้แท็ก <img ไปที่

ฉันพบคำตอบนี้จาก googling คำถามของคุณและอ่านความคิดเห็นที่http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html


1
โพสต์ที่อ้างถึงดูเหมือนจะล้าสมัยไปหน่อย
devio

6

ฉันมักจะชอบมีไฟล์ไบนารีในฐานข้อมูลเนื่องจาก:

  • ความสมบูรณ์ของข้อมูล: ไม่มีไฟล์ที่ไม่ได้อ้างอิงไม่มีเส้นทางในฐานข้อมูลโดยไม่มีไฟล์ใด ๆ ที่เกี่ยวข้อง
  • ความสอดคล้องของข้อมูล: ถ่ายโอนข้อมูลฐานข้อมูลและนั่นคือทั้งหมด ไม่ "ฉันลืม targz ไดเรกทอรีข้อมูลนี้"

4

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

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


3

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


0

เพียงเพื่อเพิ่มคำตอบที่ดีอยู่แล้ว คุณยังสามารถได้รับประโยชน์จากการแคชจากทั้งในระดับเว็บอาจและระดับฐานข้อมูลถ้าคุณไปเส้นทางการรักษาคุณภาพในฐานข้อมูล

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

ในทางเว็บฉันเดาได้ว่าเนื่องจากคำถามของคุณถูกแท็กด้วย asp.net ว่าคุณจะไปตามเส้นทางของการใช้ตัวจัดการ http เพื่อแสดงรูปภาพ จากนั้นคุณจะได้รับประโยชน์ทั้งหมดของเฟรมเวิร์กตามที่คุณต้องการและคุณสามารถทำให้ลอจิกโดเมนของคุณสะอาดขึ้นโดยเพียงแค่ส่งคีย์ไปยังรูปภาพของคุณไปยังตัวจัดการ http


-1

ทำไมไม่เลือกฐานข้อมูล NoSql แต่ละรายการเพื่อจัดเก็บไฟล์ของคุณ

ทำให้คุณมีความสมบูรณ์ของข้อมูลความสอดคล้องของข้อมูลตามที่ @chburd กล่าวไว้

ในขณะที่คุณยังคงมีขนาดเล็ก


-1
  1. นี่คือตัวอย่างทีละขั้นตอน (วิธีการทั่วไปการใช้งาน Spring Eclipse) ของการจัดเก็บภาพในระบบไฟล์และเก็บข้อมูลเมตาไว้ใน DB - http://www.devmanuals.com/tutorials/java/spring/spring3/mvc /Spring3MVCImageUpload.html
  2. นี่คือตัวอย่างเช่นกัน - http://www.journaldev.com/2573/spring-mvc-file-upload-example-tutorial-single-and-multiple-files
  3. นอกจากนี้คุณสามารถตรวจสอบ codebase ของโครงการนี้ - https://github.com/jdmr/fileUpload ความสนใจกับเรื่องนี้ควบคุม
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.