it-swarm.asia

عرض الصور خارج خادم SQL مقابل نظام الملفات مقابل S3 ، إلخ

يشتمل تطبيقي (asp asp yay الكلاسيكي!) على حوالي 2.1 مليون صورة @ 25 جيجابايت ويمثل ذلك 90 يومًا فقط من البيانات وأرغب في استخدام 365 كحد أدنى. أحتاج إلى السيطرة على هذه الأمور وأبحث في جميع الخيارات. ما هي أفكارك حول إيجابيات وسلبيات الممارسات التالية:

  • مزود خدمة الايجابيات: من السهل إجراء نسخ احتياطي سلبيات: الأداء؟
  • إيجابيات نظام الملفات: سلبيات السرعة: التكرار ، النسخ الاحتياطي بطيئًا (تبحث حاليًا في القيام بنسخ احتياطية كاملة من Synthetic بدلاً من ذلك قد تجعل ذلك أفضل)
  • S3 وما شابه ذلك الايجابيات: يتم نقل النطاق الترددي من مركز البيانات الخاص بي إلى أمازون ، وتخزين غير محدود تقريبا. العيوب: تحليل التكلفة والتكلفة أمر صعب (تقدير 80٪ من عرض النطاق الترددي الخاص بي هو صور لأغراض العائد على الاستثمار) ، من الصعب/الذي سيوفر لمقدمي خدمات swtich إذا أصبح ذلك ضروريًا

هل يتعامل أي شخص آخر مع التحدي الذي يواجه ملايين الصور وكيف تتعامل معها؟

12
Webjedi

ليس لدينا ملايين الصور ، ولكن لدينا مئات الآلاف ، ونحن نستخدم الطريقة الهجينة - mysql للبيانات الوصفية ، والصور المخزنة على القرص المحلي للنسخ الاحتياطي ، ويتم نقلها إلى Amazon s3 حيث يتم تقديمها للمستخدمين. لم نواجه أي مشكلة مع Amazon وتوافرها. الانتقال إلى cloudfront هو في خططنا ، فقط بحاجة للعثور على الوقت.

قد تكون هذه المناقشة مفيدة لك في قرارك:
http://ask.metafilter.com/59635/Millions-of-images

أود الذهاب مع البيانات الوصفية في خادم SQL والملفات الموجودة على نظام الملفات (أو s3 أو cloudfront). لكن أفضل إجابة تعتمد على بعض أنماط الاستخدام الأخرى:

  • هل الصور تتغير في كثير من الأحيان
  • يمكنك عرض الصور مباشرة من نظام الملفات (أي ، img src="...") أو هل تحتاج إلى التحكم في الوصول إليها. إذا كان الأخير ، فإن حل قاعدة البيانات هو الأفضل
  • هل تقدم عددًا قليلاً من الصور في معظم الأوقات (الأحدث 10٪) أم أن التوزيع واسع الانتشار نسبيًا.

ستكون النسخ الاحتياطية لملايين الصور معقدة بغض النظر عن كيفية ترتيبها - إنها مجرد بيانات كثيرة. أرغب في العثور على دراسة حالة جيدة حول إجراء نسخ احتياطي للنقاط في خادم SQL قبل الالتزام بهذا الحل. (إليك مقالة قد تكون مفيدة: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part -4.htm )

6
mooreds

تجاهل الأشخاص الذين يقولون ، " لا تقم بتخزين الصور/البيانات الثنائية في قاعدة البيانات " لأنهم يبنون إجاباتهم على المعلومات القديمة (على افتراض أنك ستكون تخزين البيانات في عمود نوع VarBinary). يمكن الآن تخفيف المخاوف المتعلقة بالأداء باستخدام SQL Server لتخزين الصور باستخدام FILESTREAM نوع البيانات في SQL Server 2008. في جوهرها ، يتيح لك نوع بيانات FILESTREAM إمكانية الجمع بين سهولة تخزين البيانات في قاعدة البيانات ذات الأداء الذي تحصل عليه من تقديم الملفات من مخزن ملفات NTFS.

اقتباس SQL Mag :

"يجمع دعم FILESTREAM الجديد في SQL Server 2008 بين الاستفادة من الوصول إلى LOBs مباشرة من نظام ملفات NTFS مع التكامل المرجعي وسهولة الوصول التي يوفرها مشغل قاعدة بيانات SQL Server ذات الصلة."

لمزيد من المعلومات اقرأ هذا بلوق من قبل رافي S.Maniam على MSDN .

3
Dan Diplo

إذا قررت الاستمرار في تخزينها في نظام الملفات ، فقد ترغب في الاطلاع على سؤال ServerFault هذا فيما يتعلق ببعض المهام والقيام بما يلي: تخزين مليون صورة في نظام الملفات .

3
Mark Henderson

على الرغم من أنني لا أتعامل مع التحدي الذي يواجه ملايين الصور ، إلا أنني أستخدم Amazon CloudFront. يتم تخزين كل الملفات في دلو S3 ولكن يتم تخزينها من خلال نظام تسليم محتوى Amazon. لن أستخدم S3 وحده.

سيكون خياري الثاني هو نظام الملفات. المشكلة بسيطة وسهلة فقط هي أنه إذا انتهى كل هذه الملفات في دليل واحد ، فإن الأمر برمته سوف يتعطل.

SQL لي لن يكون خيارا لنظام مثل هذا. لا يقتصر الأمر على تحصيل رسوم نقل النطاق الترددي ، بل سيتم محاسبتك أيضًا على معالجة الاستعلام - هذا سيعتمد بشكل كبير على الاستضافة ، لكنني أفترض أنك تستخدم خادمًا مخصصًا أو على الأقل vps حيث سيتم محاسبتك للدورات. بعد ذلك سوف تبطئ موقعك بالكامل إذا كان يستخدم نفس قاعدة البيانات مثل خادم الصور. إذا لم يكن الأمر كذلك ، فأنت تقوم بإضافة كل هذا التعقيد المتمثل في الاضطرار إلى إدارة اتصالين لقاعدة البيانات.

2
Frank Robert Anderson

تم تصميم قواعد البيانات لبيانات المعاملات/الاتساق والأمن.

تميل ملفات الوسائط (الصور ، الصوت ، الفيديو) إلى الإنشاء وربما يتم حذفها ، ولكنها نادراً ما يتم تحديثها. لذلك ، عمومًا ، ليست هناك حاجة لإبقائها متوافقة مع المعاملات مع البيانات الأخرى ولن توفر لك قاعدة البيانات أي فائدة حقيقية هناك. محتوى النص ربما مسألة مختلفة.

طالما لم تكن لديك أي مشكلة في مفهوم قيام شخص ما بسحب الملف مباشرة إذا كان لديه عنوان URL للملف ، فسيكون نظام الملفات على ما يرام. إذا كنت تشغل مكتبة صور ، حيث تتوقع تحميلها قبل أن يقوم الأشخاص بتنزيل الملف ، فربما تكون هذه مسألة مختلفة. ويعني ذلك أنه بمجرد قيام المستخدم بالدفع ، فقد يحصل على عنوان URL خاص بذلك المستخدم أو صالح لفترة قصيرة فقط ، ويعالج التطبيق عناوين URL متعددة أو مؤقتة تشير إلى نفس الصورة. لا يزال من الممكن التعامل مع ذلك بواسطة التطبيق ونظام الملفات ، ولكن ينتهي بك الأمر تقديم الوسائط من خلال التطبيق بدلاً من تنزيل الملف مباشرة (والذي يستبعد في الغالب أي فوائد من S3) وهناك فرق أقل بين DB ونظام الملفات .

1
Gary