هل هناك أي مكتبات أو مكونات تتعامل مع التخزين واسترجاع المحتوى الذي تم إنشاؤه بواسطة المستخدم؟

Question

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

سيكون التنفيذ المرجعي هو Facebook البنية التحتية للصور.

الخصائص التالية مهمة

• يجب أن يتوسع متجر البيانات جيدًا: يجب أن تكون إضافة الموارد شفافة للتطبيق باستخدام المتجر (سؤال مماثل كان لديه إجابة تشير إلى LinkedIn's Voldemort).
• القدرة على إضافة بعض البيانات الوصفية إلى جانب البيانات التي يتم تخزينها.
• يمكن الاستعلام عن بيانات التعريف بأداء جيد (على سبيل المثال تخزين في فهرس قابل للتكوين مثل Lucene/SOLR).
• الوصول السريع القائم على المفاتيح وبعض طبقة التخزين المؤقت الوسيطة

نرحب بأي توصيات للمكتبات أو الأطر التي يمكن دمجها بسهولة في تطبيق Java Web.

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

Answer 1

لقد قمنا بتجارب جيدة مع مستودع وسائل الإعلام من Fedora Commons (http://www.fedora-commons.org/) ، مما يسمح لك بتخزين أصول الوسائط إلى جانب البيانات الوصفية المرتبطة بها. لم يكن لدينا أي مشاكل في قابلية التوسع أو التخصيص ، ولم يكن من الصعب تبادل طبقة التخزين الأساسية مع متجر ثلاثي (إذا كان ذلك مطلوبًا في حالتك). إذا كنت بحاجة إلى فهرسة بياناتك باستخدام SOLR ، فيمكنك استخدام حقل بيانات التعريف المحدد مسبقًا ("Rels-Ext") لتخزين البيانات المستندة إلى XML.

Answer 2

mogilefs هو ما يستخدمه LiveJournal. ليس بشكل خاص جافا رغم ذلك.

Answer 3

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

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

Answer 4

Apache Jackrabbit هو تطبيق مطابق تمامًا لمستودع المحتوى لـ Java Technology API (JCR ، المحدد في JSR 170 و 283). ولكن لديه بعض مشكلات الأداء (على الأقل في الإصدار الذي أستخدمه لمدة عامين) ، أفضل طريقة للتغلب عليها هي تكرار الصور الثابتة إلى خادم الويب. (باستخدام WebDav و Davfs و Rsync)

Answer 5

يعتمد ذلك على القياس الكمي لـ "قاعدة مستخدم كبيرة ونشطة" ...

80 ٪ من مواقع الويب يمكنها ببساطة استخدام نهج خالي من مخطط NOSQL مثل Y_Serial:

y_serial.py وحدة :: مستودع كائنات بيثون مع sqlite

"التسلسل + الثبات :: في عدد قليل من أسطر الكود ، ضغط وتوضيح كائنات Python في SQLite ؛ ثم استرجعها لاحقًا من الناحية الزمنية بواسطة الكلمات الرئيسية دون أي SQL." الوحدة القياسية "الأكثر فائدة لقاعدة بيانات لتخزين بيانات الخطر".

http://yserial.sourceforge.net

إذا كانت الصور والتحف لكل مستخدم أقل ضغطًا ، فيجب أن يكون الأداء جيدًا.

بالنسبة لاستخدام الحالات البالغ 20 ٪ المتبقية ، يستورد المرء بسهولة البيانات من Yserial إلى Cassandra - الذي تم تبنيه الآن بواسطة Facebook و Digg و Twitter.