الصور في قاعدة البيانات مقابل نظام الملفات

Question

لدينا مشروع قادم حيث سنقوم ببناء نظام CMS خلفي كامل يعمل على تشغيل الشبكة الخارجية والإنترانت بالكامل بحزمة واحدة.السؤال الذي كنت أحاول العثور على إجابة له هو أيهما أفضل:تخزين الصور في قاعدة البيانات (SQL Server 2005) بحيث يكون لدينا التكامل وخطة النسخ المتماثل الفردية وما إلى ذلك أو تخزينها على نظام الملفات؟

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

اهتماماتنا تتمحور حول ما يلي:

• تكامل البيانات
• النسخ المتماثل للبيانات
• قرارات متعددة
• سرعة قاعدة البيانات مقابل نظام الملفات
• التحميل الزائد لقاعدة البيانات مقابل نظام الملفات
• إدارة البيانات والنسخ الاحتياطي

هل لدى أي شخص موقف مماثل أو لديه أي مساهمة بشأن ما يمكن التوصية به؟شكرا مقدما للمساعدة!

Answer 1

كانت هناك ورقة بحث لطيفة نشرتها Microsoft Research تسمى إلى blob أو عدم النقطة حيث نظروا إلى جميع أنواع المتغيرات والآثار.

نتائجهم في النهاية:

• ما يصل إلى 256 كيلو بايت في الحجم ، يتم تخزين النقط في قاعدة البيانات بشكل أكثر كفاءة من نظام الملفات
• مقابل 1 ميغابايت وأكبر ، يكون نظام الملفات أكثر كفاءة
• بينه

منذ نشر تلك الورقة ، أضاف SQL Server 2008 أيضًا سمة Filestream التي تجعل تخزين الأشياء في نظام الملفات ، ولكن تحت التحكم في المعاملات ، حقيقة واقعة. أوصىك بشدة بالتحقق من ذلك!

Answer 2

يأتي هذا السؤال كثيرًا - انظر هذه لذلك نتيجة البحث.

لا يوجد إجابة صحيحة واحدة - يعتمد على الظروف.

شخصيا - احتفظ بمسار ملف في DB والملف على نظام الملفات. كل لديه نقاط قوته الخاصة. يمكنك النسخ الاحتياطي للملفات وكذلك قواعد البيانات. هذا هو أيضا استنتاج هذا الشخص, من يدير TBS من البيانات.

Answer 3

قد يكون من الصعب إدارة نسخ الملفات الثابتة ، وخاصة عبر عدد من الخوادم. يتعلق الأمر حقًا بموجب مفاضلة بين إدارة ومراقبة وتصحيح مشاكل النسخ المتماثل مقابل حجم قاعدة البيانات وتحميله.

أعتقد أنني ربما أختار نهج قاعدة البيانات ، وإذا أصبح التحميل مشكلة في طرح نوع من طبقة ذاكرة التخزين المؤقت حول مكالمات الصور.

تفقد الاقتراحات لتخزين مسار في DB المشكلة الحقيقية ، والتي تكرر هذا عبر آلات متعددة.

Answer 4

مخاوفك تنقسم إلى معسكرين. تفضل المخاوف التالية تخزين المستندات في قاعدة البيانات:

• تكامل البيانات
• تكرار البيانات
• قرارات متعددة
• إدارة البيانات والنسخ الاحتياطي

هذه المخاوف (ربما) تفضل تخزين المستندات على نظام الملفات:

• سرعة قاعدة البيانات مقابل نظام الملفات
• تحميل النفقات العامة لقاعدة البيانات مقابل نظام الملفات

لذلك ، قرر ما يهم أكثر واختيار وفقًا لذلك.

Answer 5

حسنًا ، إذا كانت احتياجاتك الأولى هما النزاهة والنسخ المتماثل ، فإن الإجابة هي بالتأكيد DB.

أنت نقاط أخرى على الرغم من:

• النزاهة - DB ، لهذا السبب توجد قواعد البيانات مقابل أنظمة الملفات المسطحة.

• النسخ المتماثل - لست متأكدًا مما إذا كنت تعني النسخ المتماثل للصورة ، ولكن إذا كان الأمر كذلك ، فمن الواضح أن DB لأنك لن تتحمل موازنة هذا ، بالتأكيد.

• يمكن تنفيذ قرارات متعددة من صورة DB ، ولكن هذا يضيف تكاليف المعالجة. وأيضًا ، كلما زاد الدقة ، زاد الحجم ، كلما انتظر الشبكة. تتداول قرارات متعددة مساحة للسرعة.

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

• بصراحة - بصراحة ، يعتمد ذلك على تعريفك للنفقات العامة وكيفية الوصول إلى الصور.

• الإدارة ، DB ، اليدين لأسفل. التخزين المفرد = واحد أقل قلقًا ، ويجب أن تقوم دائمًا بتشغيل النسخ الاحتياطية على قاعدة البيانات في أي حال. النسخ الاحتياطية لنظام الملفات عبر خوادم متعددة مكلفة بعدة طرق.

Answer 6

هناك مخاوف مشروعة على جانبي المناقشة، لذا قم دائمًا بتقديم متطلباتك.ما مقدار البيانات، كم عدد الصور، ما حجمها؟

تخزين مضمن / BLOB

رأسًا على عقب:يبسط البنية والتنفيذ، ويبسط النسخ الاحتياطي والاسترداد أو ترحيل النظام؛ما عليك سوى إجراء عملية تفريغ ونسخ احتياطي وتصدير (مهما كان المصطلح الخاص بنكهة قاعدة البيانات الخاصة بك) ونقلها إلى قاعدة البيانات الجديدة.يتم التعامل مع التحكم في الإصدار/التناسق بواسطة قاعدة البيانات، لذلك يسمح بالاسترداد في الوقت المناسب.يعد الأمان / التحكم في الوصول أيضًا أكثر نظافة، نظرًا لأن الوصول إلى صورة BLOB يعد أمرًا جوهريًا للوصول إلى الصف العام.إن نقل الصورة خارج قاعدة البيانات والسماح لخادم HTTP بإحضارها، على الرغم من كونه أفضل للتزامن وقابلية التوسع، إلا أنه يمكن أن يواجه مشكلات في ضمان عدم تمكن الأشخاص من اختراق عناوين URL وطلب صور لا يملكونها.إذا قمت بإيوائها خارج قاعدة البيانات، فتأكد من أن سياسة الأمان الخاصة بك تغطي التحكم في الوصول إلى الصور بين المستخدمين.إما أن تتكامل مصادقة خادم HTTP مع مصادقة النظام بشكل عام، أو أن برنامج خادم HTTP الذي يقدم الصور يستخدم نوعًا ما من آلية الجلسة لضمان صلاحية طلب HTTP.يعد هذا مصدر قلق كبير جدًا في قواعد البيانات متعددة المستأجرين.أقل أهمية في الأنظمة ذات الغرض الواحد والمستأجر الواحد مع المصادقة البسيطة.

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

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

Answer 7

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

النظر في المعالجة النفقات العامة المرتبطة باسترداد الصورة في كل مرة تريد العمل معها.

بضع نقاط لماذا يجب أن تفكر في نظام الملفات

1. يقوم المتصفح بكل العمل ، وتستفيد من التخزين المؤقت للوكيل للصور وما إلى ذلك
2. كفرع مما سبق ، يمكنك استخدام شبكات توصيل المحتوى بسهولة (CDN)
3. إن تكرار بيانات الصورة سهلة مع أدوات مثل RSYNC وما إلى ذلك
4. يتم تحسين وقت المعالجة (IE CPU) بشكل كبير

Answer 8

على افتراض أنك في بيئة Windows لا يوجد سبب كبير لاستخدام نظام الملفات. قد ترغب في توخي الحذر في كيفية تخزين الصور في الجداول لتجنب انقسامات الصفحة غير المرغوب فيها ، ولكن هذا قرص أداء ، وليس مشكلة كبيرة.

سلالة إلى نظام الملفات

-لم يتم تكرارها تلقائيًا

-قد يعقد تكرارك من خلال وجود مواقع مادية مختلفة لكل حالة

-لاو مع أعداد كبيرة جدا من الملفات

الاتجاه الصعودي إلى نظام الملفات

-إذا كنت تقوم بتخزين بعض الملفات الكبيرة جدًا ، فسيؤدي ذلك بشكل أفضل قليلاً.

Answer 9

أود؛

1) تعيين معرف فريد (GUID) لكل صورة 2) علامة/اسم الصورة بهذا GUID 3) تخزين GUID في نظام التشغيل (نظام الملفات) 4) تخزين مؤشر اسم الملف المؤهل بالكامل (FQN) في قاعدة البيانات.

يعد تخزين الصور في قاعدة البيانات مكلفة للغاية من حيث التخزين والصيانة. تخزين مؤشر FQN فقط سيوفر حلًا أفضل. يمكنك أيضًا إنشاء فحص النزاهة الخلفية من خلال المشغلات وبعض الإجراءات المخزنة.

Answer 10

لن أقوم بتخزين الصور في قاعدة البيانات لسبب واحد (إجابتي تأتي من SQL Server):

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