تحتاج إلى تخزين الكثير من البيانات على جهاز Android ، والتفكير في الذهاب إلى OODB

Question

أنا أعمل حاليًا على مشروع يعتمد على Android. دون الدخول في العديد من التفاصيل ، سيتم تشغيل البرنامج على جهاز مدمج مخصص. لن تتغير الأجهزة أبدًا وستكون هي نفسها دائمًا. هذه زائد محدد :)

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

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

هل يتمتع أي شخص بأي خبرة مع oodbs على Android و/أو بتخزين هذه البيانات الكبيرة والوصول إليها؟ إذا كان الأمر كذلك ، فستكون أي نصيحة يمكنك تقديمها موضع تقدير كبير.

-- يحرر

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

تخيل أننا نبني طلبًا لمراقبة كل مركبة تقود على New Jersey Turnpike في أي وقت. بالنسبة لأي سيارة معينة ، نحتاج إلى تتبع صنع السيارة ونموذجها ، وعدد الأشخاص الموجودين في السيارة وما هو الديموغرافي للأشخاص في السيارة. لذلك ينتهي بك الأمر بالبيانات التي تبدو مثل -

جمل

معرف | اللون | make_id | in_toll_lane | model_id

صنع

معرف | اسم

نموذج

معرف | الاسم | make_id

car_person

معرف | العمر | الجنس | is_driver | car_id

toll_lanes

معرف | cars_in_line | Ideal_Cars_in_line | Ideal_Occupants

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

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

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

هذا مثال بسيط للغاية ، على الرغم من أنه تمثل مشكلتنا.

- نهاية التحرير

شكرا مقدما!

Answer 1

فيما يلي بعض الملاحظات ، على الرغم من أنني أظن أنها لن تساعدك مباشرة.

أعتقد أن الأسئلة الرئيسية هي: هل ستكتشف علاقاتك المعقدة عبر منطق وقت تشغيل التطبيق حيث تنشئ الأحداث أو تغيير البيانات أم أنك ستضطر إلى تفريغ البيانات في متجر ثم اكتشاف العلاقات غير المتوقعة عبر الاستعلام؟

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

الآن يصبح السؤال ، ما الذي سيتم تشغيله على Android ويتعامل مع بيانات ضخمة؟ هذا هو المكان الذي أعتقد أنني لا أستطيع المساعدة. أنا أعمل في Versant Who لديه (DB4O و Versant) ODB. الآن سيتم تشغيل DB4O على Android ، ولكن في الحقيقة هو الخيار الصحيح للبيانات الضخمة ... لا. الموقف. قاعدة البيانات الأخرى الخاصة بنا ، Versant لا تعني التعامل مع البيانات الضخمة في الوقت الفعلي القريب ، ولكن فقط العميل هو جافا بنسبة 100 ٪ ، والخادم مكتوب في C ، لذلك لن يتم تشغيله على Android.

أعتقد أنك ستحتاج إلى إجراء بعض الأبحاث لمعرفة من لديه ODB الذي يمكنه التعامل مع بيانات ضخمة عن Android.

أفضل ، -Robert

Answer 2

لا تقول الكثير عن احتياجات الوصول إلى البيانات أو تحميل البيانات حقًا.

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

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

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

Answer 3

في حديثه عن DB4O: نقوم بتشغيل جميع اختبارات الانحدار لدينا على Android لأننا نعتقد أنها ستصبح منصة مهمة للغاية لـ DB4O.

يعمل DB4O بشكل جيد جدًا لترتيب حجم 3 ملايين كائن.

نحن نقوم باختبار قياسي ضد قواعد البيانات الأخرى على http://www.polepos.org/ وسنصدر قريبًا إصدارًا جديدًا من المعيار حيث ندير إعدادًا معقدًا ، أيضًا ضد SQLLITE. يعد نقل المعيار إلى Android أيضًا اعتبارًا.

إذا كانت توصيلات تقتل أدائك وكان لديك بيانات غير متجانسة للغاية ، فقد تعمل DB4O بشكل أفضل من قاعدة بيانات علائقية.

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

Answer 4

جيسون: للوصول إلى أي عضو DB4O ، يجب عليك استخدام هذا النمط: FirstName @ db4o.com الأفضل!