database - تخزين الصور في DB-نعم أو ناي؟




image theory storage blob (25)

لذلك أنا أستخدم تطبيقًا يخزن الصور بكثافة في قاعدة البيانات. ما هي نظرتك في هذا؟ أنا أكثر من نوع لتخزين الموقع في نظام الملفات ، من تخزينه مباشرة في قاعدة البيانات.

ما رأيك في الايجابيات / السلبيات؟


Answers

كما هو الحال مع معظم القضايا ، ليست بسيطة كما يبدو. هناك حالات يكون فيها من المنطقي تخزين الصور في قاعدة البيانات.

  • أنت تقوم بتخزين الصور التي تتغير ديناميكيًا ، مثل الفواتير وأردت الحصول على فاتورة كما كانت في 1 يناير 2007؟
  • الحكومة تريد منك الحفاظ على 6 سنوات من التاريخ
  • لا تتطلب الصور المخزنة في قاعدة البيانات استراتيجية نسخ احتياطي مختلفة. الصور المخزنة على نظام الملفات تفعل
  • من الأسهل التحكم في الوصول إلى الصور إذا كانت موجودة في قاعدة بيانات. يمكن لمسؤولي الخمول الوصول إلى أي مجلد على القرص. يتطلب الأمر مشرفًا محددًا حقًا على التطفل في قاعدة بيانات لاستخراج الصور

من ناحية أخرى هناك مشاكل مرتبطة

  • يتطلب كود إضافي لاستخراج وتدفق الصور
  • قد يكون وقت الاستجابة بطيئًا أكثر من الوصول المباشر للملفات
  • تحميل أثقل على خادم قاعدة البيانات

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

يعد عرض الصور من قاعدة البيانات أمرًا سهلاً ، فقط قم بتطبيق معالج http الذي يخدم صفيف البايت الذي يتم إرجاعه من خادم DB كدفق ثنائي.


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

يحل FileStream معظم المشاكل حول تخزين الملفات في DB:

  1. يتم بالفعل تخزين النقطات كملفات في مجلد.
  2. يمكن الوصول إلى Blobs باستخدام إما اتصال قاعدة البيانات أو عبر نظام الملفات.
  3. يتم دمج النسخ الاحتياطية.
  4. الهجرة "يعمل فقط".

على الرغم من أن "تشفير البيانات الشفاف" الخاص بـ SQL لا يقوم بتشفير كائنات FileStream ، لذلك إذا كان هذا هو الاعتبار ، فقد يكون من الأفضل تخزينها فقط كدليل varbinary.

من مقالة MSDN:

يمكن لبيانات SQL للعمليات إدراج بيانات FILESTREAM وتحديثها والاستعلام عنها والبحث عنها. توفر واجهات نظام ملف Win32 دفق الوصول إلى البيانات.
يستخدم FILESTREAM ذاكرة التخزين المؤقت لنظام NT للتخزين المؤقت لبيانات الملف. يساعد هذا في تقليل أي تأثير قد يكون لدى بيانات FILESTREAM على أداء Database Engine. لا يتم استخدام تجمع المخزن المؤقت SQL Server؛ لذلك ، تتوفر هذه الذاكرة من أجل معالجة الاستعلام.


أنا المسؤول عن بعض التطبيقات التي تدير العديد من TB من الصور. لقد وجدنا أن تخزين مسارات الملفات في قاعدة البيانات هو الأفضل.

هناك مشكلتان:

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

عملت مرة واحدة على تطبيق معالجة الصور. قمنا بتخزين الصور التي تم تحميلها في دليل كان مثل / الصور / [تاريخ اليوم] / [رقم المعرف]. ولكننا أيضًا استخرجنا البيانات الوصفية (بيانات exif) من الصور وتخزينها في قاعدة البيانات ، إلى جانب طابع زمني.


إذا لم تكن على SQL Server 2008 ولديك بعض الأسباب القوية لوضع ملفات صور محددة في قاعدة البيانات ، فيمكنك اتباع منهج "كلاهما" واستخدام نظام الملفات كمخزن مؤقت مؤقت واستخدام قاعدة البيانات كمستودع رئيسي .

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


الحيلة هنا هي ألا تصبح متعصبًا.

شيء واحد أن نلاحظ هنا هو أن لا أحد في معسكر نظام الملفات الموالية قد سرد نظام ملفات معين. هل هذا يعني أن كل شيء من FAT16 إلى ZFS يدق بكل قاعدة بيانات؟

لا.

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

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


افتراض: التطبيق هو تمكين شبكة الإنترنت / على شبكة الإنترنت

أنا مندهش لا أحد قد ذكر بالفعل هذا ... تفويضه للآخرين الذين هم من المتخصصين -> استخدم موفر استضافة / ملف جهة خارجية .

قم بتخزين الملفات الخاصة بك على خدمة مدفوعة عبر الإنترنت مثل

مواضيع أخرى تتحدث عن هذا here .

يوضح هذا الموضوع لماذا يجب عليك استخدام مزود استضافة طرف ثالث.

إنه يستحق ذلك. تخزنها بكفاءة. لا يتم تحميل عرض النطاق الترددي من الخوادم إلى طلبات العميل ، وما إلى ذلك.


كما قال آخرون أن مزود 2008 يأتي بنوع Filestream الذي يسمح لك بتخزين اسم الملف أو المعرف كمؤشر في ديسيبل ويقوم بتخزين الصورة تلقائيًا على نظام الملفات الخاص بك وهو سيناريو رائع.

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

بهذه الطريقة ستوفر أيضًا مساحة على نظام الملفات الخاص بك ، لأنك ستقوم فقط بحفظ المساحة الصحيحة ، أو حتى ضغط مساحة على نظام الملفات.

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

على الأرجح ، سيسمح لك أيضًا بإلقاء بعض عناصر التخزين المؤقت ، استنادًا إلى عناوين url للصور الأكثر شيوعًا في محرك الويب الخاص بك / برنامجك ، لذلك أنت تنقذ نفسك أيضًا.


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


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

+ فيس:

  • تكامل قاعدة البيانات
  • من السهل إدارتها لأنه لا داعي للقلق بشأن الحفاظ على مزامنة نظام الملفات عند إضافة أو حذف صورة

-ves:

  • عقوبة الأداء - عادةً ما يكون البحث في قاعدة البيانات أبطأ من بحث نظام الملفات
  • لا يمكنك تحرير الصورة مباشرة (الاقتصاص ، تغيير الحجم)

كلتا الطريقتين شائعتان وتمارسان. إلقاء نظرة على مزايا وعيوب. في كلتا الحالتين ، سيكون عليك التفكير في كيفية التغلب على العيوب. عادةً ما يعني التخزين في قاعدة البيانات تعديل معلمات قاعدة البيانات وتطبيق نوع من التخزين المؤقت. يتطلب استخدام نظام الملفات العثور على طريقة لحفظ نظام الملفات + قاعدة البيانات بشكل متزامن.


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

في أحدث مشروع لدي أنا تخزين الصور في قاعدة البيانات ، والتخزين المؤقت لها على نظام الملفات ، وأنه يعمل بشكل جيد. لم يكن لدي أي مشاكل حتى الآن.


إليكم ورقة بيضاء مثيرة للاهتمام حول هذا الموضوع.

إلى BLOB أو لا إلى BLOB: تخزين كائن كبير في قاعدة بيانات أو نظام ملفات

الجواب هو، فإنه يعتمد." بالتأكيد سيعتمد على خادم قاعدة البيانات ونهجها للتخزين blob. كما يعتمد على نوع البيانات المخزنة في النقط ، وكذلك كيفية الوصول إلى تلك البيانات.

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

إليك نقطة إضافية يجب وضعها في الاعتبار. أحد أسباب دعم استخدام قاعدة بيانات لتخزين النقاط هو توافق ACID. ومع ذلك ، فإن الأسلوب الذي استخدمه المختبرون في الورقة البيضاء ، (خيار Bulk Logged من SQL Server ،) والذي أدى إلى تضاعف سرعة نقل SQL Server ، أدى فعليًا إلى تغيير "D" في ACID إلى "d" ، حيث لم يتم تسجيل بيانات blob الكتابة الأولية لهذه الصفقة. لذلك ، إذا كان التوافق الكامل لـ ACID هو أحد المتطلبات الهامة للنظام الخاص بك ، فقم بتخفيض أرقام بيانات SQL Server في كتابة قاعدة البيانات عند مقارنة ملف الإدخال / الإخراج إلى I / O blob لقاعدة البيانات.


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

مثل معظم الأشياء الأخرى ، يعتمد ذلك على الحجم والميزانية المتوقعين.


إذا كان هذا تطبيقًا يستند إلى الويب ، فيمكن أن تكون هناك مزايا لتخزين الصور على شبكة تسليم طرف ثالث ، مثل Amazon S3 أو Nirvanix.


من المؤكد أن مسارات الملفات في قاعدة البيانات هي الطريقة المثلى - لقد سمعت قصة بعد قصة من العملاء الذين لديهم TB من الصور التي تحولت إلى كابوس يحاول تخزين أي كمية كبيرة من الصور في DB - إن الأداء الذي يصيب وحده أكثر من اللازم.


شيء لم يذكر أحد هو أن DB يضمن الإجراءات الذرية ، وسلامة المعاملات ، ويتعامل مع التزامن. حتى النزاهة المرجعية هي خارج النافذة بنظام ملفات - لذا كيف تعرف أن أسماء ملفاتك لا تزال صحيحة؟

إذا كان لديك صورك في نظام ملفات و شخص ما يقرأ الملف أثناء كتابة إصدار جديد أو حتى حذف الملف - ماذا يحدث؟

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


الكلمة في الشارع هي أنه ما لم تكن بائع قاعدة بيانات يحاول أن يثبت أن قاعدة البيانات الخاصة بك يمكن أن تفعلها (مثل ، لنفترض أن Microsoft تتفاخر حول Terraserver بتخزين صور bajillion في SQL Server) فهي ليست فكرة جيدة. عندما يكون البديل - تخزين الصور على خوادم الملفات والمسارات في قاعدة البيانات أسهل بكثير ، لماذا تهتم؟ تعتبر حقول Blob نوعًا ما مثل قدرات سيارات الدفع الرباعي على الطرق الوعرة - معظم الناس لا يستخدمونها ، وأولئك الذين عادة ما يواجهون المشاكل ، ومن ثم هناك من يفعلون ذلك ، ولكن فقط للمتعة منه.


في الأماكن التي يجب عليك فيها ضمان التكامل المرجعي والتوافق مع ACID ، يلزم تخزين الصور في قاعدة البيانات.

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


في شركة كنت أعمل فيها ، قمنا بتخزين 155 مليون صورة في قاعدة بيانات Oracle 8i (ثم 9i). يستحق 7.5 تيرابايت.



يقدم SQL Server 2008 حلاً يحتوي على أفضل ما في العالمين: نوع بيانات filestream .

أدرها كجدول عادي وأداء نظام الملفات.


أنا تجربتي واضطررت إلى إدارة كلتا الحالتين: الصور المخزنة في قاعدة البيانات والصور على نظام الملفات مع المسار المخزن في ديسيبل.

الحل الأول ، الصور في قاعدة البيانات ، هو "أنظف" إلى حد ما لأن طبقة الوصول إلى البيانات الخاصة بك سيكون عليها التعامل فقط مع كائنات قاعدة البيانات ؛ لكن هذا جيد فقط عندما يكون عليك التعامل مع أعداد صغيرة.

من الواضح أن أداء الوصول إلى قاعدة البيانات عندما تتعامل مع كائنات كبيرة ثنائية أمر مهين ، وأبعاد قاعدة البيانات ستنمو كثيرًا ، مما يؤدي مرة أخرى إلى فقدان الأداء ... وعادة ما تكون مساحة قاعدة البيانات أكثر تكلفة من مساحة نظام الملفات.

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

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

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


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

مرة واحدة الحل المشترك لهذا هو تجزئتها إلى شجرة متوازنة من الدلائل الفرعية.


لا تعمل الإجابة المقبولة من Thorn007 عندما تكون الصورة صغيرة جدًا .
لحل هذه المشكلة ، أضفت عامل قياس . بهذه الطريقة ، فإنه يجعل الصورة أكبر ويملأ حاوية div.

مثال:

<div style="width:400px; height:200px;">
  <img src="pix.jpg" style="max-width:100px; height:50px; transform:scale(4); transform-origin:left top;" />
</div>

ملاحظات:
1 / من أجل webkit يجب إضافة -webkit-transform: scale (4)؛ -webkit-transform-origin: left top؛ في الاسلوب.
2 / مع معامل المقياس 4 ، لديك max-width = 400/4 = 100 و max-height = 200/4 = 50
3 / حل بديل هو تعيين أقصى عرض و max-height بنسبة 25٪ ، بل هو أبسط





database image theory storage blob