ดังนั้นฉันจึงใช้แอพที่เก็บภาพไว้ในฐานข้อมูลอย่างหนัก ทัศนะของคุณเกี่ยวกับเรื่องนี้คืออะไร? ฉันเป็นประเภทที่จะจัดเก็บตำแหน่งในระบบแฟ้มมากกว่าเก็บไว้ในฐานข้อมูลโดยตรง
คุณคิดว่าข้อดี / ข้อเสียคืออะไร
คำตอบ:
ฉันรับผิดชอบแอพพลิเคชั่นบางตัวที่จัดการภาพ TB จำนวนมาก เราพบว่าการจัดเก็บเส้นทางไฟล์ในฐานข้อมูลให้ดีที่สุด
มีสองประเด็น:
เช่นเดียวกับปัญหาส่วนใหญ่มันไม่ง่ายอย่างที่คิด มีหลายกรณีที่ควรเก็บรูปภาพไว้ในฐานข้อมูล
ในขณะที่มีปัญหาที่เกี่ยวข้อง
ที่เก็บไฟล์ วิศวกร Facebook พูดถึงมันได้อย่างยอดเยี่ยม สิ่งที่ต้องคำนึงถึงอย่างหนึ่งคือรู้ขีด จำกัด ของไฟล์ในไดเร็กตอรี่
เข็มในกองหญ้า: จัดเก็บภาพถ่ายนับพันล้านภาพอย่างมีประสิทธิภาพ
นี่อาจเป็นช็อตเล็กน้อย แต่ถ้าคุณกำลังใช้ (หรือวางแผนที่จะใช้) SQL Server 2008 ฉันขอแนะนำให้ดูที่ชนิดข้อมูลFileStreamใหม่
FileStream แก้ปัญหาส่วนใหญ่เกี่ยวกับการจัดเก็บไฟล์ใน DB:
อย่างไรก็ตาม "การเข้ารหัสข้อมูลที่โปร่งใส" ของ SQL ไม่ได้เข้ารหัสวัตถุ FileStream ดังนั้นหากเป็นการพิจารณาคุณอาจจะดีกว่าเพียงเก็บไว้เป็น varbinary
จากบทความ MSDN:
คำสั่ง Transact-SQL สามารถแทรกอัปเดตสอบถามค้นหาและสำรองข้อมูล FILESTREAM อินเตอร์เฟสระบบไฟล์ Win32 จัดเตรียมการเข้าถึงสตรีมข้อมูล
FILESTREAM ใช้แคชระบบ NT สำหรับการแคชข้อมูลไฟล์ สิ่งนี้จะช่วยลดผลกระทบใด ๆ ที่ข้อมูล FILESTREAM อาจมีต่อประสิทธิภาพของโปรแกรมฐานข้อมูล ไม่ได้ใช้พูลบัฟเฟอร์ของ SQL Server ดังนั้นหน่วยความจำนี้สามารถใช้สำหรับการประมวลผลแบบสอบถาม
เส้นทางของไฟล์ในฐานข้อมูลเป็นวิธีที่จะไปแน่นอน - ฉันเคยได้ยินเรื่องราวหลังจากเล่าเรื่องราวจากลูกค้าด้วยภาพวัณโรคที่กลายเป็นฝันร้ายที่พยายามจัดเก็บรูปภาพจำนวนมากในฐานข้อมูล - ประสิทธิภาพการทำงานเพียงอย่างเดียวนั้นมากเกินไป
จากประสบการณ์ของผมบางครั้งการแก้ปัญหาที่ง่ายที่สุดคือการตั้งชื่อภาพให้เป็นไปตามคีย์หลัก ดังนั้นจึงเป็นเรื่องง่ายที่จะค้นหาภาพที่เป็นของบันทึกเฉพาะและในทางกลับกัน แต่ในเวลาเดียวกันคุณไม่ได้เก็บอะไรเกี่ยวกับภาพในฐานข้อมูล
เคล็ดลับที่นี่คือการไม่กลายเป็นคนกระตือรือร้น
สิ่งหนึ่งที่ควรทราบที่นี่คือไม่มีใครในค่ายระบบไฟล์มืออาชีพที่มีรายชื่อระบบไฟล์เฉพาะ สิ่งนี้หมายความว่าทุกอย่างตั้งแต่ FAT16 ถึง ZFS ใช้ประโยชน์ได้ดีในทุกฐานข้อมูลหรือไม่
เลขที่
ความจริงก็คือฐานข้อมูลจำนวนมากเอาชนะระบบไฟล์จำนวนมากแม้ว่าเราจะพูดถึงความเร็วที่แท้จริงเท่านั้น
การดำเนินการที่ถูกต้องคือการตัดสินใจที่ถูกต้องสำหรับสถานการณ์ที่แม่นยำของคุณและเพื่อที่จะทำเช่นนั้นคุณจะต้องใช้ตัวเลขและการประมาณค่าการใช้เคส
ในสถานที่ที่คุณต้องรับประกัน Referential Integrity และความสอดคล้องกับ ACID จำเป็นต้องมีการจัดเก็บรูปภาพในฐานข้อมูล
คุณไม่สามารถทำธุรกรรมรับประกันได้ว่าภาพและ meta-data เกี่ยวกับภาพที่เก็บไว้ในฐานข้อมูลอ้างถึงไฟล์เดียวกัน กล่าวอีกนัยหนึ่งเป็นไปไม่ได้ที่จะรับประกันว่าไฟล์ในระบบไฟล์นั้นจะถูกเปลี่ยนแปลงในเวลาเดียวกันและในการทำธุรกรรมเดียวกับเมตาดาต้า
ดังที่คนอื่น ๆ บอกว่า SQL 2008 มาพร้อมกับประเภท Filestream ที่ให้คุณจัดเก็บชื่อไฟล์หรือตัวระบุเป็นตัวชี้ใน db และจัดเก็บภาพในระบบไฟล์ของคุณโดยอัตโนมัติซึ่งเป็นสถานการณ์ที่ยอดเยี่ยม
หากคุณอยู่ในฐานข้อมูลที่เก่ากว่าฉันจะบอกว่าถ้าคุณเก็บไว้เป็นข้อมูลหยดคุณก็จะไม่ได้อะไรออกจากฐานข้อมูลในทางของการค้นหาคุณสมบัติดังนั้นมันอาจจะดีที่สุด เพื่อจัดเก็บที่อยู่บนระบบไฟล์และจัดเก็บภาพในลักษณะนั้น
ด้วยวิธีนี้คุณยังประหยัดพื้นที่ในระบบไฟล์ของคุณเนื่องจากคุณจะประหยัดพื้นที่ในจำนวนที่แน่นอนหรือแม้แต่พื้นที่ที่ถูกบีบอัดบนระบบไฟล์
นอกจากนี้คุณสามารถตัดสินใจที่จะบันทึกด้วยโครงสร้างหรือองค์ประกอบบางอย่างที่ช่วยให้คุณสามารถเรียกดูรูปภาพดิบในระบบไฟล์ของคุณโดยไม่มีการเข้าชม db หรือถ่ายโอนไฟล์จำนวนมากไปยังระบบอื่นฮาร์ดไดรฟ์ S3 หรือสถานการณ์อื่น - อัปเดตตำแหน่งใน โปรแกรมของคุณ แต่คงโครงสร้างไว้อีกครั้งโดยไม่มีการพยายามที่จะนำภาพออกมาจากฐานข้อมูลของคุณเมื่อพยายามเพิ่มที่เก็บข้อมูล
อาจเป็นไปได้ว่ามันจะช่วยให้คุณสามารถโยนองค์ประกอบแคชบางอย่างขึ้นอยู่กับ URL ของภาพที่นิยมเข้าไปในโปรแกรมเว็บ / โปรแกรมของคุณเพื่อให้คุณประหยัดด้วยตัวคุณเอง
รูปภาพขนาดเล็กแบบสแตติก (ไม่เกินสองสาม megs) ที่ไม่ได้ถูกแก้ไขบ่อยครั้งควรถูกเก็บไว้ในฐานข้อมูล วิธีนี้มีประโยชน์หลายประการรวมถึงความสะดวกในการพกพา (ภาพถูกถ่ายโอนด้วยฐานข้อมูล) สำรองข้อมูล / คืนค่าได้ง่ายขึ้น (ภาพสำรองด้วยฐานข้อมูล) และความสามารถในการปรับขยายที่ดีขึ้น (โฟลเดอร์ระบบไฟล์ที่มีไฟล์ ผม).
การให้บริการรูปภาพจากฐานข้อมูลนั้นทำได้ง่ายเพียงแค่ใช้ตัวจัดการ http ที่ให้บริการอาร์เรย์ไบต์ที่ส่งคืนจากเซิร์ฟเวอร์ฐานข้อมูลเป็นกระแสข้อมูลแบบไบนารี
นี่คือกระดาษขาวที่น่าสนใจในหัวข้อ
เป็น BLOB หรือไม่ถึง BLOB: ที่เก็บวัตถุขนาดใหญ่ในฐานข้อมูลหรือระบบไฟล์
คำตอบคือ "ขึ้นอยู่กับ" แน่นอนมันจะขึ้นอยู่กับเซิร์ฟเวอร์ฐานข้อมูลและวิธีการในการจัดเก็บหยด นอกจากนี้ยังขึ้นอยู่กับประเภทของข้อมูลที่จัดเก็บใน Blobs ตลอดจนวิธีการเข้าถึงข้อมูลนั้น
ไฟล์ขนาดเล็กสามารถจัดเก็บและส่งมอบได้อย่างมีประสิทธิภาพโดยใช้ฐานข้อมูลเป็นกลไกการจัดเก็บ ไฟล์ที่มีขนาดใหญ่กว่าอาจถูกเก็บไว้อย่างดีที่สุดโดยใช้ระบบไฟล์โดยเฉพาะหากไฟล์เหล่านั้นจะถูกแก้ไข / อัพเดทบ่อยครั้ง (การกระจายตัวของหยดกลายเป็นปัญหาเกี่ยวกับประสิทธิภาพ)
นี่คือจุดเพิ่มเติมที่ควรทราบ เหตุผลหนึ่งที่สนับสนุนการใช้ฐานข้อมูลเพื่อเก็บ blobs คือการปฏิบัติตามข้อกำหนดของกรด อย่างไรก็ตามวิธีการที่ผู้ทดสอบใช้ในเอกสารข้อมูลสีขาว (ตัวเลือกบันทึกข้อมูลจำนวนมากของ SQL Server) ซึ่งเพิ่มปริมาณงานของเซิร์ฟเวอร์ SQL เป็นสองเท่าได้อย่างมีประสิทธิภาพเปลี่ยน 'D' ในกรดเป็น 'd' เนื่องจากข้อมูล Blob ไม่ได้ถูกบันทึกไว้ การเขียนเริ่มต้นสำหรับการทำธุรกรรม ดังนั้นหากการปฏิบัติตามข้อกำหนด ACID เต็มรูปแบบเป็นข้อกำหนดที่สำคัญสำหรับระบบของคุณให้ลดทอนตัวเลขปริมาณงานของ SQL Server สำหรับการเขียนฐานข้อมูลเมื่อเปรียบเทียบไฟล์ I / O กับฐานข้อมูล Blob I / O
สิ่งหนึ่งที่ฉันยังไม่เคยเห็นใครพูดถึง แต่น่าสังเกตว่ามีปัญหาเกี่ยวกับการจัดเก็บรูปภาพจำนวนมากในระบบไฟล์ส่วนใหญ่เช่นกัน ตัวอย่างเช่นหากคุณใช้วิธีการที่กล่าวถึงข้างต้นและตั้งชื่อไฟล์ภาพแต่ละไฟล์หลังจากคีย์หลักในระบบไฟล์ส่วนใหญ่คุณจะพบปัญหาหากคุณพยายามวางรูปภาพทั้งหมดไว้ในไดเรกทอรีขนาดใหญ่หนึ่งไดเรกทอรีเมื่อคุณเข้าถึงภาพจำนวนมาก ( เช่นในแสนแสนล้าน)
เมื่อวิธีแก้ปัญหาทั่วไปนี้คือการแฮชพวกเขาออกเป็นต้นไม้ย่อยของไดเรกทอรีย่อย
สิ่งที่ไม่มีใครพูดถึงคือฐานข้อมูลรับประกันการกระทำของอะตอมความสมบูรณ์ของธุรกรรมและข้อตกลงพร้อมกัน แม้แต่ความสมบูรณ์แบบอ้างอิงก็ออกไปนอกหน้าต่างด้วยระบบไฟล์ดังนั้นคุณจะรู้ได้อย่างไรว่าชื่อไฟล์ของคุณยังคงถูกต้องจริง ๆ ?
หากคุณมีภาพในระบบไฟล์และมีคนกำลังอ่านไฟล์ในขณะที่คุณกำลังเขียนเวอร์ชันใหม่หรือแม้กระทั่งการลบไฟล์ - จะเกิดอะไรขึ้น?
เราใช้ blobs เพราะพวกเขาจัดการได้ง่ายกว่า (การสำรองข้อมูลการจำลองแบบการถ่ายโอน) ด้วย พวกเขาทำงานได้ดีสำหรับเรา
ปัญหาเกี่ยวกับการจัดเก็บเฉพาะไฟล์พา ธ ไปยังรูปภาพในฐานข้อมูลคือความสมบูรณ์ของฐานข้อมูลไม่สามารถบังคับได้อีกต่อไป
หากอิมเมจจริงที่ชี้ไปยัง filepath นั้นไม่พร้อมใช้งานฐานข้อมูลจะมีข้อผิดพลาดด้านความสมบูรณ์โดยไม่เจตนา
ระบุว่ารูปภาพเป็นข้อมูลจริงที่ต้องการค้นหาและสามารถจัดการได้ง่ายขึ้น (ภาพจะไม่หายไปทันที) ในฐานข้อมูลรวมเดียวแทนที่จะต้องเชื่อมต่อกับระบบไฟล์บางประเภท (หากระบบไฟล์นั้นเข้าถึงได้โดยอิสระ ภาพอาจจะ "หายไป" ในทันใดฉันจะไปเก็บมันโดยตรงในรูปแบบ BLOB หรืออย่างนั้น
ที่ บริษัท ที่ฉันเคยทำงานเราเก็บรูปภาพ 155 ล้านรูปในฐานข้อมูล Oracle 8i (จากนั้น 9i) 7.5TB คุ้มค่า
โดยปกติฉันมักจะไม่ยอมสละส่วนที่แพงที่สุดและยากที่สุดในการปรับขนาดของโครงสร้างพื้นฐานของคุณ (ฐานข้อมูล) และวางภาระทั้งหมดไว้ในนั้น ในทางกลับกัน: มันช่วยลดความซับซ้อนของกลยุทธ์การสำรองข้อมูลโดยเฉพาะอย่างยิ่งเมื่อคุณมีเว็บเซิร์ฟเวอร์หลายเครื่องและจำเป็นต้องซิงค์ข้อมูล
เช่นเดียวกับสิ่งอื่น ๆ ส่วนใหญ่ขึ้นอยู่กับขนาดและงบประมาณที่คาดหวัง
เราได้นำระบบภาพเอกสารมาใช้เพื่อจัดเก็บภาพทุกภาพในเขตข้อมูลหยด SQL2005 ขณะนี้มีหลายร้อย GB และเราเห็นเวลาตอบสนองที่ยอดเยี่ยมและประสิทธิภาพลดลงเล็กน้อยหรือไม่มีเลย นอกจากนี้เรายังมีเลเยอร์มิดเดิลแวร์ที่เก็บเอกสารที่เพิ่งโพสต์ไปยังระบบตู้เพลงแบบออพติคอลซึ่งแสดงให้เห็นว่าเป็นระบบไฟล์ NTFS มาตรฐาน
เราพอใจมากกับผลลัพธ์โดยเฉพาะอย่างยิ่งที่เกี่ยวกับ:
หากนี่เป็นแอปพลิเคชันบนเว็บอาจมีข้อได้เปรียบในการจัดเก็บภาพบนเครือข่ายการจัดส่งของบุคคลที่สามเช่น S3 ของ Amazon หรือแพลตฟอร์ม Nirvanix
ข้อสันนิษฐาน: แอปพลิเคชันเปิดใช้งานเว็บ / ใช้เว็บ
ฉันประหลาดใจที่ไม่มีใครได้กล่าวถึงจริงๆนี้ ... มอบหมายมันออกมาให้คนอื่น ๆ ที่เป็นผู้เชี่ยวชาญ -> ใช้ผู้ให้บริการภาพของบุคคลที่ 3 / ไฟล์โฮสติ้ง
จัดเก็บไฟล์ของคุณในบริการออนไลน์แบบเสียเงินเช่น
อีกหัวข้อ StackOverflow พูดคุยเกี่ยวกับเรื่องนี้ที่นี่
หัวข้อนี้อธิบายถึงสาเหตุที่คุณควรใช้ผู้ให้บริการโฮสต์ภายนอก
มันคุ้มค่ามาก พวกเขาเก็บไว้อย่างมีประสิทธิภาพ ไม่มีแบนด์วิดธ์ที่มีการอัปโหลดจากเซิร์ฟเวอร์ของคุณไปยังคำขอของลูกค้า ฯลฯ
หากคุณไม่ได้อยู่ใน SQL Server 2008 และคุณมีเหตุผลที่ชัดเจนในการวางไฟล์รูปภาพเฉพาะในฐานข้อมูลคุณสามารถใช้วิธี "ทั้ง" และใช้ระบบไฟล์เป็นแคชชั่วคราวและใช้ฐานข้อมูลเป็นแหล่งเก็บข้อมูลหลัก .
ตัวอย่างเช่นตรรกะทางธุรกิจของคุณสามารถตรวจสอบว่ามีไฟล์รูปภาพอยู่บนแผ่นดิสก์ก่อนที่จะแสดงผลหรือเรียกข้อมูลจากฐานข้อมูลเมื่อจำเป็น นี่เป็นการซื้อความสามารถของเว็บเซิร์ฟเวอร์หลายเครื่องและปัญหาการซิงค์น้อยลง
ฉันไม่แน่ใจว่านี่เป็นตัวอย่างของ "โลกแห่งความจริง" แต่ตอนนี้ฉันมีแอปพลิเคชันที่เก็บรายละเอียดสำหรับเกมการ์ดซื้อขายรวมถึงภาพสำหรับการ์ด ได้รับการนับระเบียนสำหรับฐานข้อมูลเป็นเพียง 2,851 บันทึกถึงวันที่ แต่เนื่องจากความจริงที่ว่าการ์ดบางอย่างได้รับการปล่อยตัวหลายครั้งและมีงานศิลปะทางเลือกมันเป็นจริงที่มีประสิทธิภาพมากขึ้นในการสแกน "จัตุรัสหลัก" ของงานศิลปะ สร้างเส้นขอบและเอฟเฟกต์เบ็ดเตล็ดสำหรับการ์ดเมื่อมีการร้องขอ
ผู้สร้างดั้งเดิมของไลบรารีรูปภาพนี้สร้างคลาสการเข้าถึงข้อมูลที่แสดงรูปภาพตามคำขอและมันค่อนข้างเร็วสำหรับการดูและการ์ดแต่ละใบ
สิ่งนี้ยังช่วยลดการใช้งาน / อัปเดตเมื่อมีการออกการ์ดใหม่แทนที่จะซิปทั้งโฟลเดอร์ของรูปภาพและส่งสิ่งเหล่านั้นลงไปในท่อและทำให้แน่ใจว่ามีการสร้างโครงสร้างโฟลเดอร์ที่เหมาะสมฉันเพียงอัปเดตฐานข้อมูลและให้ผู้ใช้ดาวน์โหลดอีกครั้ง ปัจจุบันนี้มีขนาดสูงถึง 56MB ซึ่งไม่ดี แต่ฉันกำลังพัฒนาฟีเจอร์การอัปเดตที่เพิ่มขึ้นสำหรับการเปิดตัวในอนาคต นอกจากนี้ยังมีแอปพลิเคชั่นรุ่น "no images" ที่อนุญาตให้ผู้ที่ผ่านการเรียกผ่านสายโทรศัพท์รับแอปพลิเคชันโดยไม่ล่าช้าในการดาวน์โหลด
โซลูชันนี้ใช้งานได้ดีจนถึงปัจจุบันเนื่องจากแอปพลิเคชันนั้นถูกกำหนดเป้าหมายเป็นอินสแตนซ์เดียวบนเดสก์ท็อป มีเว็บไซต์ที่ข้อมูลทั้งหมดนี้ถูกเก็บถาวรเพื่อการเข้าถึงออนไลน์ แต่ฉันจะไม่ใช้วิธีการแก้ปัญหาเดียวกันนี้ ฉันเห็นด้วยว่าการเข้าถึงไฟล์จะดีกว่าเพราะจะขยายขนาดได้ดีขึ้นตามความถี่และปริมาณการร้องขอสำหรับรูปภาพ
หวังว่านี่จะไม่พูดพล่ามเกินไป แต่ฉันเห็นหัวข้อและต้องการให้ข้อมูลเชิงลึกของฉันจากแอปพลิเคชันขนาดเล็ก / ขนาดกลางที่ประสบความสำเร็จ
SQL Server 2008 ข้อเสนอวิธีการแก้ปัญหาที่มีที่ดีที่สุดของโลกทั้งสองชนิดข้อมูล FILESTREAM
จัดการมันเหมือนตารางปกติและมีประสิทธิภาพของระบบไฟล์
ขึ้นอยู่กับจำนวนภาพที่คุณจะจัดเก็บและขนาดของมัน ฉันเคยใช้ฐานข้อมูลเพื่อเก็บภาพในอดีตและประสบการณ์ของฉันค่อนข้างดี
IMO, ข้อดีของการใช้ฐานข้อมูลเพื่อจัดเก็บภาพคือ
A. คุณไม่จำเป็นต้องมีโครงสร้าง FS เพื่อเก็บภาพของคุณ
B. ดัชนีฐานข้อมูลทำงานได้ดีกว่าต้นไม้ FS เมื่อมีรายการจำนวนมากถูกเก็บไว้
C. ฐานข้อมูลที่ได้รับการปรับอย่างชาญฉลาดทำงานได้ดีในการแคชผลลัพธ์แบบสอบถาม
D. การสำรองข้อมูลนั้นง่าย นอกจากนี้ยังใช้งานได้ดีหากคุณมีการตั้งค่าการจำลองแบบและเนื้อหาจะถูกส่งจากเซิร์ฟเวอร์ใกล้กับผู้ใช้ ในกรณีเช่นนี้ไม่จำเป็นต้องซิงโครไนซ์อย่างชัดเจน
หากรูปภาพของคุณมีขนาดเล็ก (พูดน้อยกว่า 64k) และเอ็นจิ้นการจัดเก็บของฐานข้อมูลของคุณรองรับ BLOB แบบอินไลน์ (เป็นบันทึก) มันจะปรับปรุงประสิทธิภาพการทำงานให้ดีขึ้นโดยไม่ต้องใช้การอ้อม
การจัดเก็บภาพอาจเป็นความคิดที่ไม่ดีเมื่อคุณจัดการกับภาพขนาดใหญ่จำนวนน้อย ปัญหาอีกประการหนึ่งของการจัดเก็บภาพในฐานข้อมูลคือเมทาดาทาเช่นการสร้างวันที่แก้ไขจะต้องได้รับการจัดการโดยแอปพลิเคชันของคุณ
ฉันเพิ่งสร้างแอพ PHP / MySQL ที่เก็บไฟล์ PDF / Word ไว้ในตาราง MySQL (ใหญ่เป็น 40MB ต่อไฟล์จนถึงตอนนี้)
ข้อดี:
จุดด้อย:
ฉันจะเรียกการใช้งานของฉันประสบความสำเร็จดูแลความต้องการการสำรองข้อมูลและทำให้เค้าโครงของโครงการง่ายขึ้น ประสิทธิภาพดีสำหรับผู้ใช้งานแอป 20-30 คน
ฉันประสบการณ์ของฉันฉันต้องจัดการทั้งสองสถานการณ์: ภาพที่เก็บไว้ในฐานข้อมูลและภาพในระบบไฟล์ที่มีเส้นทางที่เก็บไว้ในฐานข้อมูล
ทางออกแรก, รูปภาพในฐานข้อมูลค่อนข้าง "สะอาด" เนื่องจากเลเยอร์การเข้าถึงข้อมูลของคุณจะต้องจัดการกับวัตถุฐานข้อมูลเท่านั้น แต่จะดีเมื่อคุณต้องจัดการกับตัวเลขที่ต่ำ
เห็นได้ชัดว่าประสิทธิภาพการเข้าถึงฐานข้อมูลเมื่อคุณจัดการกับวัตถุขนาดใหญ่แบบไบนารีกำลังลดน้อยลงและขนาดฐานข้อมูลจะเพิ่มขึ้นอย่างมากทำให้เกิดการสูญเสียประสิทธิภาพอีกครั้ง ... และโดยปกติพื้นที่ฐานข้อมูลมีราคาแพงกว่าพื้นที่ระบบไฟล์
ในทางตรงกันข้ามการมีวัตถุไบนารีขนาดใหญ่เก็บไว้ในระบบไฟล์จะทำให้คุณมีแผนสำรองที่ต้องพิจารณาทั้งฐานข้อมูลและระบบไฟล์และอาจเป็นปัญหาสำหรับบางระบบ
อีกเหตุผลหนึ่งที่ทำให้ระบบไฟล์คือเมื่อคุณต้องแชร์ข้อมูลรูปภาพของคุณ (หรือเสียงวิดีโออะไรก็ตาม) กับการเข้าถึงของบุคคลที่สาม: ในวันนี้ฉันกำลังพัฒนาเว็บแอปที่ใช้รูปภาพที่ต้องเข้าถึงจากภายนอก "ฟาร์มเว็บของฉันในลักษณะที่การเข้าถึงฐานข้อมูลเพื่อดึงข้อมูลไบนารีนั้นเป็นไปไม่ได้ ดังนั้นบางครั้งก็มีข้อควรพิจารณาในการออกแบบที่จะนำคุณไปสู่ทางเลือก
พิจารณาด้วยเมื่อทำการเลือกนี้หากคุณต้องจัดการกับสิทธิ์และการพิสูจน์ตัวตนเมื่อเข้าถึงวัตถุไบนารี: สิ่งที่ต้องมีตามปกติเหล่านี้สามารถแก้ไขได้ด้วยวิธีที่ง่ายขึ้นเมื่อจัดเก็บข้อมูลในฐานข้อมูล
ฉันเคยทำงานกับโปรแกรมประมวลผลภาพ เราเก็บรูปภาพที่อัปโหลดไว้ในไดเรกทอรีที่มีลักษณะคล้าย / images / [วันที่วันนี้] / [หมายเลขประจำตัว] แต่เรายังดึงข้อมูลเมตา (ข้อมูล exif) จากรูปภาพและเก็บไว้ในฐานข้อมูลพร้อมกับเวลาประทับและเช่นกัน
ในโครงการก่อนหน้านี้ฉันเก็บรูปภาพไว้ในระบบไฟล์และทำให้เกิดอาการปวดหัวจำนวนมากด้วยการสำรองข้อมูลการจำลองแบบและระบบไฟล์ที่ไม่สอดคล้องกับฐานข้อมูล
ในโครงการล่าสุดของฉันฉันกำลังจัดเก็บภาพในฐานข้อมูลและแคชไว้ในระบบไฟล์และใช้งานได้ดีจริงๆ ฉันไม่มีปัญหาเลย
ข้อเสนอแนะที่สองเกี่ยวกับเส้นทางของไฟล์ ฉันทำงานหลายโครงการที่จำเป็นในการจัดการคอลเลกชันสินทรัพย์ขนาดใหญ่และความพยายามใด ๆ ในการจัดเก็บสิ่งต่าง ๆ โดยตรงในฐานข้อมูลทำให้เกิดความเจ็บปวดและความยุ่งยากในระยะยาว
"โปร" ตัวจริงเท่านั้นที่ฉันนึกถึงเกี่ยวกับการจัดเก็บไว้ในฐานข้อมูลคือศักยภาพในการทำให้ง่ายต่อการเก็บภาพแต่ละชิ้น หากไม่มีไฟล์พา ธ ที่จะใช้งานและรูปภาพทั้งหมดจะถูกสตรีมโดยตรงจากฐานข้อมูลจะไม่มีอันตรายที่ผู้ใช้จะพบไฟล์ที่ไม่ควรเข้าถึง
ดูเหมือนว่ามันจะถูกแก้ไขได้ดีขึ้นด้วยสคริปต์ตัวกลางดึงข้อมูลจากที่เก็บไฟล์บนเว็บที่เข้าถึงไม่ได้ ดังนั้นการจัดเก็บฐานข้อมูลจึงไม่จำเป็นจริงๆ
คำพูดบนท้องถนนคือถ้าคุณไม่ใช่ผู้จำหน่ายฐานข้อมูลที่พยายามพิสูจน์ว่าฐานข้อมูลของคุณสามารถทำได้ (เช่นสมมติว่า Microsoft อวดอ้างเกี่ยวกับ Terraserver เกี่ยวกับ Terraserver ที่เก็บรูปภาพขนาดยักษ์ใน SQL Server) ไม่ใช่ความคิดที่ดีมาก เมื่อทางเลือก - การจัดเก็บภาพบนไฟล์เซิร์ฟเวอร์และเส้นทางในฐานข้อมูลนั้นง่ายกว่ามากทำไมต้องกังวล เขตข้อมูล Blob นั้นเหมือนกับความสามารถในการขับขี่ออฟโรดของ SUV - คนส่วนใหญ่ไม่ได้ใช้พวกเขาคนที่มักจะมีปัญหาแล้วก็มีคนที่ทำ แต่เพื่อความสนุกเท่านั้น
การจัดเก็บรูปภาพในฐานข้อมูลยังหมายความว่าข้อมูลรูปภาพสิ้นสุดลงที่ใดที่หนึ่งในระบบไฟล์ แต่ถูกบดบังเพื่อให้คุณไม่สามารถเข้าถึงได้โดยตรง
+ Ves:
-ves:
ทั้งสองวิธีนี้เป็นเรื่องธรรมดาและได้รับการฝึกฝน ดูที่ข้อดีและข้อเสีย ไม่ว่าจะด้วยวิธีใดคุณจะต้องคิดถึงวิธีเอาชนะข้อเสีย การจัดเก็บในฐานข้อมูลมักหมายถึงการปรับแต่งพารามิเตอร์ของฐานข้อมูลและใช้การแคชบางประเภท การใช้ระบบไฟล์ต้องการให้คุณค้นหาวิธีที่ทำให้ระบบไฟล์ + ฐานข้อมูลซิงค์อยู่