تصميم قاعدة البيانات غير العلائقية [مغلق]

Question

أنا مهتم بمعرفة استراتيجيات التصميم التي استخدمتها قواعد بيانات "nosql" غير العلائقية - أي فئة مخازن البيانات (الجديدة في الغالب) التي لا تستخدم التصميم العلائقي التقليدي أو SQL (مثل Hypertable وCouchDB وSimpleDB ومخزن بيانات Google App Engine وVoldemort وCassandra وSQL Data Services وما إلى ذلك).ويُشار إليها غالبًا أيضًا باسم "مخازن المفاتيح/القيمة"، وهي في الأساس تعمل مثل جداول التجزئة الثابتة الموزعة العملاقة.

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

• هل توصلت إلى تصميمات بديلة تعمل بشكل أفضل في العالم غير العلائقي؟

• هل ضربت رأسك بشيء يبدو مستحيلاً؟

• هل قمت بسد الفجوة باستخدام أي أنماط تصميم، على سبيل المثال؟للترجمة من واحدة إلى أخرى؟

• هل تقوم حتى بعمل نماذج بيانات صريحة على الإطلاق الآن (على سبيل المثال؟في UML) أم أنك تخلصت منها بالكامل لصالح نقاط البيانات شبه المنظمة/الموجهة نحو المستندات؟

• هل تفتقد أيًا من الخدمات الإضافية الرئيسية التي توفرها أنظمة RDBMS، مثل التكامل العلائقي، ودعم المعاملات المعقدة بشكل تعسفي، والمشغلات، وما إلى ذلك؟

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

لمعلوماتك، كانت هناك مناقشات حول StackOverflow حول مواضيع مماثلة هنا:

• الجيل القادم من قواعد البيانات
• تغيير المخططات للعمل مع Google App Engine
• اختيار قاعدة بيانات موجهة للمستندات

Answer 1

أعتقد أن عليك أن تنظر في أن DBMS غير العلائقية تختلف كثيرا فيما يتعلق بنموذج بياناتها وبالتالي فإن تصميم البيانات المفاهيمي سوف يختلف أيضا كثيرا. في الخيط تصميم البيانات في قواعد البيانات غير العلائقية التابع مجموعة جوجل nosql يتم تصنيف النماذج المختلفة مثل هذا:

1. أنظمة مثل BigTable (HBASE، ارتفاع ضغط الدم، إلخ)
2. مخازن القيمة الرئيسية (طوكيو، فولدمورت، إلخ)
3. قواعد بيانات المستندات (CouchDB، Mongodb، إلخ)
4. قواعد بيانات الرسم البياني (التسلية، NEO4J، السمسم، إلخ)

أنا في الغالب في قواعد البيانات الرسم البياني, وكانت أناقة تصميم البيانات باستخدام هذه النموذج كانت ما جلبتني هناك، تعبت من أوجه القصور RDBMS.. وبعد لقد وضعت بعض الأمثلة على تصميم البيانات باستخدام قاعدة بيانات الرسم البياني على هذا Wiki Page. وهناك مثال على كيفية النموذج الأساسية IMDB. فيلم / ممثل / بيانات الدور أيضا.

الشرائح العرض التقديمي (Slideshare) قواعد بيانات الرسم البياني ومستقبل إدارة المعرفة على نطاق واسع بواسطة ماركو رودريغيز يحتوي على مقدمة لطيفة للغاية لتصميم البيانات باستخدام قاعدة بيانات الرسم البياني أيضا.

الإجابة على الأسئلة المحددة من وجهة نظر Graphdb:

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

سد الفجوة: أميل إلى القيام بذلك يختلف عن كل حالة، بناء على المجال نفسه، لأنني لا أريد "رسم بياني موجه للجداول" وما شابه ذلك. ومع ذلك، هنا بعض المعلومات عن الترجمة الآلية من RDBMS إلى GraphDB.

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

ملكة جمال من عالم RDBMS: طرق سهلة لإنشاء تقارير. تحديث: ربما ليس كذلك الذي - التي من الصعب إنشاء تقارير من قاعدة بيانات الرسم البياني، انظر إنشاء تقرير لقاعدة بيانات عينة NEO4J.

Answer 2

لقد بدأت للتو مع قواعد البيانات غير العلائقية، وما زلت أحاول الالتفاف حولها ومعرفة النموذج الأفضل.ويمكنني التحدث فقط عن CouchDB.

ومع ذلك، لدي بعض الاستنتاجات الأولية:

هل توصلت إلى تصميمات بديلة تعمل بشكل أفضل في العالم غير العلائقي؟

يتحول تركيز التصميم:يصبح تصميم نموذج المستند (المتوافق مع جداول قاعدة البيانات) غير ذي صلة تقريبًا، بينما يتوقف كل شيء على تصميم طرق العرض (المتوافقة مع الاستعلامات).

يقوم نوع مستند DB بمبادلة التعقيدات:تحتوي لغة SQL على بيانات غير مرنة واستعلامات مرنة، أما قواعد بيانات المستندات فهي على العكس من ذلك.

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

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

أقرب تشبيه في عالم SQL هو أنه يمكنك فقط الاستعلام عن قاعدة البيانات باستخدام الإجراءات المخزنة - يجب أن يكون كل استعلام تريد دعمه محددًا مسبقًا.

تصميم الوثائق مرن للغاية.ولم أجد سوى قيدين:

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

ولكن كل شيء يتوقف على تصميم وجهات النظر.

لقد وجدت التصميمات البديلة أن أوامر العمل ذات الحجم الأفضل مع CouchDB مقارنة بأي قاعدة بيانات SQL تكون على مستوى النظام بدلاً من مستوى التخزين.إذا كان لديك بعض البيانات وترغب في تقديمها إلى صفحة ويب، فسيتم تقليل تعقيد النظام الإجمالي بنسبة 50٪ على الأقل:

• لا يوجد تصميم جداول قاعدة البيانات (مسألة ثانوية)
• لا توجد طبقة وسيطة لـ ODBC/JDBC، وجميع الاستعلامات والمعاملات عبر http (مسألة معتدلة)
• تعيين بسيط من قاعدة البيانات إلى الكائن من JSON، وهو أمر تافه تقريبًا مقارنة بنفس الشيء في SQL (مهم!)
• يمكنك تخطي خادم التطبيق بأكمله، حيث يمكنك تصميم مستنداتك ليتم استرجاعها مباشرة بواسطة المتصفح باستخدام AJAX وإضافة القليل من تلميع JavaScript قبل عرضها بتنسيق HTML. (ضخم!!)

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

هل ضربت رأسك بشيء يبدو مستحيلاً؟

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

هناك قيود تتمثل في أن الاستعلامات لا يمكنها النظر في مستندين أو أكثر في نفس الوقت - لا توجد عمليات انضمام أو أنواع أخرى من العلاقات متعددة المستندات، ولكن لا شيء حتى الآن لا يمكن التغلب عليه.

على سبيل المثال، تعتبر الأعداد والمجاميع سهلة ولكن لا يمكن حساب المتوسطات من خلال عرض/استعلام CouchDB.يصلح:قم بإرجاع المبلغ والعد بشكل منفصل وحساب المتوسط ​​على العميل.

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

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

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

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

هل تقوم حتى بعمل نماذج بيانات صريحة على الإطلاق الآن (على سبيل المثال؟في UML)؟

عذرًا، لم أقم أبدًا بالكثير من لغة UML قبل مستند قواعد البيانات أيضًا :)

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

هل تفتقد أيًا من الخدمات الإضافية الرئيسية التي توفرها أنظمة RDBMSes؟

لا.لكن خلفيتي هي مطور تطبيقات الويب، فنحن نتعامل مع قواعد البيانات فقط بالقدر الذي يجب علينا :)

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

لذا فإن كل ما أتخلى عنه هو شيء لم أملكه أبدًا في المقام الأول.من الواضح أن تجربتك قد تختلف.

---

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

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

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

أتوقع أن هناك مجموعات بيانات تتوافق بشكل أفضل مع SQL بدلاً من نموذج المستند، لذلك أتخيل أن SQL ستبقى على قيد الحياة.

ولكن بالنسبة لأولئك منا الذين يريدون فقط طريقة بسيطة لتخزين البيانات واسترجاعها - وأظن أن هناك الكثير منا - فإن قواعد بيانات المستندات (كما هو الحال في CouchDB) هي هبة من السماء.

Answer 3

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

أصعب:

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

أسهل:

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

يجب أن يكون النمذجة نفس الشيء ولكن عليك أن تكون حريصا على ما تضعه في مستند واحد: يمكن أيضا استخدام UML لكلا النمذجة OO وكذلك نمذجة DB، والتي هي وحوش مختلفة بالفعل.

كنت أرغب في رؤية قاعدة بيانات جيدة مفتوحة OO متكاملة بشكل جيد مع C # / Silverlight. فقط لجعل الخيار أكثر صعوبة. :)

Answer 4

منذ فترة طويلة تعتبر الملفات المسطحة أروما وغير عملي لمجموعة بيانات من أي حجم. ومع ذلك، فإن أجهزة كمبيوتر أسرع تحتوي على المزيد من الذاكرة تجعل من الممكن تحميل ملف في الذاكرة وفرزها في الوقت الفعلي، على الأقل لتطبيقات مستخدم N و Local المحلي المعقولة.

على سبيل المثال، يمكنك عادة قراءة ملف 10000 سجل وفرزه في حقل في أقل من نصف ثانية، وقت استجابة مقبول.

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

Answer 5

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

نقطة أخرى حيث توجد RDBMS مشاكل في التعامل مع المفاتيح التي تعتمد على التاريخ / الوقت.