لقد فقد النموذج العلائقي تفرده
تخضع متطلبات وظائف وهيكل قواعد البيانات (DB) ، والتي يتم تنفيذها بشكل كامل في الأنظمة العلائقية ، الآن إلى ضغوط المتطلبات الجديدة.
المشكلة الأولى هي انخفاض كفاءة البيانات الكبيرة. مصادر البيانات الضخمة هي الشبكات الاجتماعية ، وأنظمة المراقبة بالفيديو ، وأجهزة الاستشعار المكانية ، والفواتير ، إلخ. تعمل قاعدة البيانات العلائقية (RDB) بشكل جيد إذا كان مخطط البيانات محددًا مسبقًا ، قبل بدء التطبيق. لكن البيانات الضخمة يصعب هيكلها في مرحلة تصميم قاعدة البيانات. فقط كما يتم جمع المعلومات ، تدريجيا ، هو هيكلها أكثر وضوحا.
الاستقصاء الثاني - استعلامات البحث والحوسبة في RDBs ذات الجداول الضخمة - هذه مهمة ذات تعقيد حسابي كبير. يعمل استخدام الفهرسة والتجزئة جيدًا في BDBs ثابتة أو أكثر ، والتي يتم ملؤها إلى حد كبير قبل تشغيل النظام. وفي ظروف الوصول السريع لمصفوفات البيانات الجديدة في الوقت الفعلي ، يتم تسوية مزايا هذه الطرق ، نظرًا لزيادة التكاليف العامة زيادة حادة.
يتبع العائق الثالث لـ RDB المتطلبات الصارمة لدارات البيانات في إطار "النماذج العادية" الكنسي. تتطلب الحاجة إلى عدد كبير من مجموعة واسعة من التطبيقات بذل جهود كبيرة لإنشاء نماذج للبيانات ، ومستوى المهارة غير المتكافئ للمبرمجين والمواعيد النهائية الضيقة تؤدي إلى أخطاء تتطلب تصحيحات وتعديلات. لكن أي تغيير "حي" بالفعل ، مليء DBD ("الترحيل") هو مهمة أكثر تعقيدًا وتستغرق وقتًا ، وفي بعض الحالات لا يوجد لديه حل آخر على الإطلاق ، مثل استبدال قاعدة البيانات القديمة بالكامل بحل جديد.
"الجمال" ودقة النموذج العلائقي المطبق في SQL ، لمدة 3 عقود ، أسعد المبرمجين. النماذج "القديمة": الشبكة أو الهرمية كادت أن تنسى. نعم ، لا توجد منتجات برمجيات من هذا القبيل تقريبًا ، باستثناء استثناء IDMS "شبه الخالد" [1].
في العقد الماضي ، يجري العمل النشط لإنشاء أنظمة بديلة لإدارة قواعد البيانات (DBMS) ، والتي تسمى ببساطة - NoSQL. في ظل هذا المفهوم ، أصبحت الأنظمة المختلفة جدًا الآن مختلفة تمامًا عن بعضها البعض. ومن المثير للاهتمام ، لا يتم تضمين الشبكة "القديمة" والنماذج الهرمية في مفهوم NoSQL! يمكن الاطلاع على تقييمات جيدة في هذا المجال في [2،3،4].
تتضمن فئة NoSQL قواعد بيانات "الرسم البياني" [5] ، والتي هي قريبة بشكل تجريبي من نموذج الشبكة الكودي CODASYL [6]. كما يوحي الاسم ، فإن هذه الأنظمة عبارة عن مجموعتين غير منظمتين - العقد (الرؤوس) والحواف (الأقواس). الميزة الرئيسية لقواعد بيانات الشبكة - يتم تحديد "التنقل" ليس في وقت معالجة الطلب ، كما هو الحال في RDB ، ولكن في وقت إضافة بيانات جديدة (للرسوم البيانية - الرؤوس والحواف) ، فإن هذا صحيح تمامًا بالنسبة لأنظمة الرسوم البيانية. لكن قاعدة بيانات الرسم البياني ليست منظمة قبل ملؤها ، على عكس قاعدة بيانات CODASYL.
فئات قاعدة بيانات NoSQL الأكثر شيوعًا هي "قيمة المفتاح" (مثال - Redis [7]) و "تخزين المستندات" (مثال - MongoDB [8]). نظرًا لأن المراجعة التفصيلية لهذه الأنظمة ليست غرض هذه المقالة ، فمن المهم الإشارة إلى ما يلي فقط.
تعمل أنظمة NoSQL ، كقاعدة عامة ، على أساس أنظمة الملفات الموزعة التي توفر قابلية التوسع والموثوقية [9]. لكن المشكلة التي يتم حلها رياضيا بدقة في إطار النموذج العلائقي هي سلامة وتناسق قاعدة البيانات (شريطة ، بالطبع ، التصميم المهني المختص للمخطط الطبيعي) لا يطرح على الإطلاق في معظم أنظمة NoSQL.
إجمالاً ، الموقف اليوم هو ما يلي تقريبًا: 75٪ من قواعد البيانات علائقية ، ويستخدم NoSQL في شكله النقي في أنظمة عالية التخصص ، وتستخدم مجموعات من نماذج قواعد البيانات المختلفة في مشاريع الشبكات العالمية المحملة للغاية: Google و Facebook و Instagram و WhatsApp وما شابه ذلك.
قواعد البيانات العلائقية دون مزود
بالإضافة إلى المشكلات العملية الموضحة أعلاه ، شهد استخدام RDBs مؤخرًا اتجاهات مهمة أخرى.
إلى جانب "الصلابة" المفرطة في بعض الأحيان للنموذج العلائقي ، فإن عيبه العملي الرئيسي (وليس النظري) هو صعوبة معالجة البيانات. الخيار الأول هو استخدام خط أنابيب العمليات على مجموعات - التوحيد ، التقاطع ، الترشيح ، إلخ. في الممارسة العملية ، لا يتم استخدامه مطلقًا تقريبًا ، لأنه يرتبط بإنفاق الموارد الهائلة ويتم تبريره فقط بمعالجة "مجموعة" مجموعات الطلبات من نفس النوع. الخيار الثاني - يتطلب مترجم SQL احترافية عالية ومعرفة جيدة بنظرية المجموعة ونظرية قاعدة البيانات وخبرة عملية كبيرة.
أصبحت البرمجة الموجهة للكائنات (OOP) هي المعيار ، لكن SQL هي لغة تعريفية لا تتوافق قواعدها مع لغات OOP الأكثر شيوعًا (C ++ ، Java ، JavaScript ، Python). نتيجةً لذلك ، اكتسب حل "تضمين" RDBs (العمل مع استعلامات SQL) استنادًا إلى مكتبات الفئات التي تسمى ORM (تعيين الكائنات - تعيين الكائنات - الارتباطية (التحول) [9]) شعبية.
يتيح استخدام فئات ORM للمبرمج الاستغناء عن SQL عند استخدام RDBs. يقوم ORM تلقائيًا بإنشاء استعلامات SQL إلى RDBs لإنشاء الجداول ومعالجة البيانات. معظم ORMs لها واجهات مع مختلف DBMSs الشعبية - سكليتي ، MySQL ، بوستجرس ، وغيرها ، مما يعطي خيارا دون تعديل رمز البرنامج.
هناك الكثير من تطبيقات ORM ، حتى العديد منها لكل لغة برمجة. كلها متشابهة ، لذلك ، من أجل الحتمية ، في المستقبل ، بواسطة ORM نعني المكتبة المقابلة (مجموعة) من نماذج الفئة النموذجية لإطار Django [10] في لغة بيثون [11].
يعد ORM "مناسبًا للغاية" ولا يعتقد المبرمجون حقًا أن استخدام واجهة برمجة التطبيقات هذه لا يحصلون على مزايا النموذج العلائقي فحسب ، بل وأيضاً عيوبه. على سبيل المثال ، في الكود نفسه ، لا يمكنك تجاوز نماذج الجدول - إضافة أو إزالة عمود ، إضافة جدول جديد ، إلخ. لإجراء ترحيل قاعدة البيانات ، يجب أولاً إعادة كتابة الكود ، ثم "رفع طابق واحد" ، ثم إعادة تشغيل البرنامج. نتيجة لذلك ، من المستحيل إنشاء تطبيق يوفر حتى أبسط التغييرات في نظام البيانات أثناء تشغيل البرنامج دون تغيير البرنامج نفسه.
يتم تنفيذ استعادة البيانات في ORM باستخدام سلاسل من الطرق ، على سبيل المثال ، "objects.all ()" ، "objects.get (...)" ، "objects.filter (...)" في جانغو. بسيطة وجميلة ومريحة ، ولكن ما التعقيد الخوارزمية لتنفيذ استعلامات SQL التي تم إنشاؤها بواسطة ORM سيؤدي إلى هذا غير مرئي للعين المجردة.
عندما يكتب شخص استعلام SQL ، فمن المفترض أنه يفهم ويفهم تكلفة موارد الحوسبة. حجاب ORM هذه المهمة.
Hypertable كقاعدة بيانات جيل جديد
قمنا بتطوير مفهوم جديد وأساليب وطرق عملية للجمع بين نماذج قواعد البيانات العلائقية والشبكات مع مزايا فكرة ORM - رفض استخدام لغات الاستعلام الخاصة ، مما سمح لنا بإنشاء نموذج وتقنية جديدة لقاعدة البيانات.
المفهوم الرئيسي هو hypertable (GT) - هذه هي قاعدة بيانات كمجموعة من العلاقات (الجداول) التي تستخدم:
- السمات "العلائقية" (مجالات البيانات) ، والقيم التي ، كما في RDB ، هي حقول الحقول مع البيانات المعرفة ذاتيا لأعمدة الجدول المقابل
- سمات "الشبكة" (مجالات الرابط). سوف نسميها ATS - سمة من النوع "رابط"
تعد قيم حقول PBX الموجودة في صفوف الجدول بمثابة مراجع صريحة لأي صفوف في أي جداول مضمنة في hypertable.
لا علاقة لمفهوم hypertable الذي قدمناه نحن بالمشروع [13] ، الذي تم تقليصه في عام 2016.
يوجد نموذج أولي عملي - مجموعة من الأدوات في Python - نظام Hyper Table Management (HTMS) ، والذي يتضمن المستويات التالية (من الأعلى إلى الأسفل):
- يعد HTed hypertable editor (client) خدمة دعم تقني يتم تنفيذها كموقع على شبكة الإنترنت في إطار عمل Django ، والذي يمكنه الاتصال بأي خادم بواسطة hypertable بغض النظر عن التطبيقات (إنه قريب وظيفيًا من الأداة المساعدة PgAdmin لـ PostgeSQL إلى حد ما) ؛
- مكتبة المرافق وفئات مستوى المنطق - واجهة برمجة التطبيقات لإنشاء قاعدة بيانات ومعالجة البيانات على مستوى برمجة التطبيق (استبدال ORM) ؛
- مكتبة المرافق وفئات المستوى الفعلي للعمل مع قاعدة البيانات ، والتي تستند إليها المرافق وفئات المستوى المنطقي (كيف يمكن استخدام API من قبل مبرمجي النظام ذوي الخبرة) ؛
- فئة قفص ، والتي تم تصميمها لإنشاء طبقة "افتراضية" من الوصول البعيد المخزنة مؤقتاً إلى ملفات قاعدة البيانات على الجانب العميل (التطبيق) ؛
- خادم ملفات CageServer - برنامج يعمل في وضع متعدد البرامج ومتعدد الخيوط ، وينفذ وظائف للوصول عن بعد متعدد المستخدمين إلى الملفات على خادم باستخدام بروتوكول TCP.
من حيث المبدأ ، بدلاً من Cage ، من الممكن استخدام النظام الفرعي المعتاد للملف المحلي لنظام التشغيل لإدارة الملفات ، وكذلك استخدام Cage API و CageServer كأداة مستقلة من HTMS لتنفيذ الوصول إلى الملفات الموزعة عن بُعد على أي أنظمة.
في المقالات المستقبلية ، من المخطط إدخال القراء على نظام HTMS بمزيد من التفصيل.