การแสดงรูปภาพจากเซิร์ฟเวอร์ SQL เทียบกับระบบไฟล์เทียบกับ S3 ฯลฯ

แอปพลิเคชันของฉัน (คลาสสิก asp yay!) มีประมาณ 2.1 ล้านภาพ @ 25GB และนั่นหมายถึง 90 วันของข้อมูลและฉันต้องการ 365 ขั้นต่ำ ฉันต้องได้รับสิ่งเหล่านี้ภายใต้การควบคุมและกำลังพิจารณาตัวเลือกทั้งหมด คุณคิดอย่างไรเกี่ยวกับข้อดีข้อเสียของการปฏิบัติดังต่อไปนี้:

• ข้อดีของ SQL Server: ง่ายต่อการสำรองจุดด้อย: ประสิทธิภาพ?
• ข้อดีของระบบไฟล์: ข้อเสียความเร็ว: ความซ้ำซ้อน, แบ็คอัพช้า (ขณะนี้กำลังทำการสังเคราะห์แบ็คอัพสังเคราะห์แบบเต็มซึ่งอาจทำให้ดีขึ้นได้)
• S3 และข้อดีเช่น: แบนด์วิดธ์ถูกเปลี่ยนจากดาต้าเซ็นเตอร์ของฉันเป็นอเมซอนซึ่งเป็นพื้นที่จัดเก็บที่ไม่ จำกัด ข้อด้อย: ค่าใช้จ่ายการวิเคราะห์ต้นทุนนั้นยุ่งยาก (ประมาณ 80% ของแบนด์วิดท์ของฉันคือรูปภาพสำหรับจุดประสงค์เพื่อการลงทุน) ยาก / มีค่าใช้จ่ายสูงสำหรับผู้ให้บริการ swtich หากจำเป็น

มีใครจัดการกับความท้าทายภาพหลายล้านหรือไม่และคุณจัดการปัญหานี้อย่างไร?

เราไม่มีภาพนับล้าน แต่มีหลายแสนภาพและเราใช้วิธีไฮบริด - mysql สำหรับข้อมูลเมตารูปภาพที่เก็บไว้ในดิสก์ภายในเครื่องสำหรับการสำรองข้อมูลและส่งไปยัง Amazon s3 ที่มีการให้บริการแก่ผู้ใช้ เราไม่มีปัญหากับ Amazon และความพร้อมใช้งาน การย้ายไปยัง Cloudfront นั้นอยู่ในแผนของเราเพียงแค่ต้องหาเวลา

การสนทนานี้อาจเป็นประโยชน์กับคุณในการตัดสินใจของคุณ:
http://ask.metafilter.com/59635/Millions-of-images

ฉันจะไปกับเมตาดาต้าในเซิร์ฟเวอร์ SQL และไฟล์บนระบบไฟล์ (หรือ s3 หรือ cloudfront) แต่คำตอบที่ดีที่สุดขึ้นอยู่กับรูปแบบการใช้งานอื่น:

• ภาพเปลี่ยนแปลงบ่อยไหม
• คุณสามารถให้บริการภาพโดยตรงจากระบบแฟ้ม (นั่นคือimg src="...") หรือคุณต้องการให้พวกเขาจะควบคุมการเข้าถึง หากหลังแล้วโซลูชันฐานข้อมูลจะดีที่สุด
• คุณให้บริการภาพจำนวนเล็กน้อยในเวลาส่วนใหญ่ (ล่าสุด 10%) หรือมีการกระจายค่อนข้างแพร่หลาย

การสำรองข้อมูลสำหรับรูปภาพนับล้านภาพจะมีความซับซ้อนไม่ว่าคุณจะจัดเรียงภาพเหล่านั้นอย่างไรมันเป็นเพียงข้อมูลจำนวนมาก ฉันต้องการค้นหากรณีศึกษาที่ดีเกี่ยวกับการสำรองข้อมูล blobs ในเซิร์ฟเวอร์ SQL ก่อนที่จะตกลงแก้ไขปัญหานั้น (นี่คือบทความที่อาจมีประโยชน์: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

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

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

ในการอ้างอิงSQL Mag :

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

สำหรับข้อมูลเพิ่มเติมอ่านบล็อกนี้โดยราวี S.Maniam ใน MSDN

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

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

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

ฐานข้อมูลได้รับการออกแบบสำหรับการทำธุรกรรมข้อมูล / ความสอดคล้องและความปลอดภัย

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

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