تم اختراع قواعد البيانات العلائقية و SQL في السبعينيات ، لكنها لا تزال تهيمن على عالم البيانات اليوم. لماذا ا؟ حسابات التفاضل والتكامل ، والبيانات المتسقة ، وتمثيل البيانات المنطقية كلها أسباب تجعل مناصرة قاعدة البيانات العلائقية الفضل في نجاحها. ومع ذلك ، يمكن تلخيص نجاح قواعد البيانات العلائقية في اعتبارين عمليين: الزخم وقوة لغة استعلام SQL.
يبدو أن ما يسمى بتكنولوجيا "NoSQL" تتعارض مع نقاط القوة تلك. ولكن في الواقع ، تقوم NoSQL ببناء الزخم الخاص بها ، وتوفير معرفة وقوة SQL هو كيفية القيام بذلك.
قوة SQL
دعنا نراجع قوة SQL بافتراض عدم وجودها: لا توجد لغة تعريفية للعمل مع البيانات. بدلا من ذلك ، علينا أن نعمل بشكل إلزامي. بدلاً من تحديد البيانات التي نريدها ، يتعين علينا تحديد كيفية الحصول عليها.
باستخدام هذه الإستراتيجية ، يتم إعطاء كل خطوة من خطوات استعلام قاعدة البيانات إرشادات مطولة: المطابقة والتجميع والتوقع والفرز. بعضها يعالج من قبل العميل ، والبعض الآخر بواسطة الخادم. يتم ترك مقارنة هذه الإستراتيجية باستعلام SQL تعريفي ، وكيفية المشروع ، وكيفية الفرز ، وجميع عمليات المعالجة المحددة لقاعدة البيانات. ما تبقى لنا هو لغة أسهل في القراءة والكتابة تزودنا بالبيانات التي نريدها. وهي لغة قياسية يمكن لأي شخص يعمل بالبيانات التقاطها واستخدامها مع أي قاعدة بيانات ارتباطية أخرى. لا عجب أن العلائقية وهيمنة SQL.
حدود العلائقية (relational database)
إذن ، لماذا توجد NoSQL؟ وجدت Gartner أن سوق نظم إدارة قواعد البيانات غير العلائقية كان القطاع الأسرع نموًا في عام 2020 ، حيث توسع بنسبة 34.5 ٪ (أكثر من ضعف نمو العلاقات). لم يتم تصميم قواعد البيانات العلائقية للتعامل مع حجم الإنترنت. هل تريد خادمًا علاقيًا للتعامل مع المزيد من العمل؟ تحتاج إلى قياسها عموديًا (vertically scale) . مما يعني أنك بحاجة إلى خادم أكبر وأسرع.
ماذا يحدث عندما يصبح ذلك مستحيلاً أو مكلفاً للغاية؟ إذا كنت من مستخدمي Amazon أو Google ، فعليك الخروج من النموذج العلائقي. يجب عليك التوسع أفقيًا ، مما يعني أنه يجب عليك الانضمام إلى خوادم متعددة معًا عبر شبكة. هذا يقدم عالمًا جديدًا تمامًا من التحديات التي يجب حلها. كان لدى أمازون وجوجل الموارد اللازمة لمعالجة هذه المشكلات ، وإجراء البحوث ، وإصدار الأوراق التقنية ، مما أدى إلى جيل جديد كامل من قواعد البيانات مفتوحة المصدر والموردين الذين يركزون على قواعد البيانات ، في حركة أطلق عليها اسم "NoSQL".
هل يجب أن أستخدم NoSQL أم لا؟
مع انطلاق NoSQL ، بدأت أيضًا الخدمات المصغرة (نهج موزع للقياس الأفقي للتطبيقات). يمكن لكل خدمة مصغرة استخدام قاعدة البيانات الخاصة بها ، وهذا يعني في كثير من الحالات أن النظام الكامل يمكن أن يستخدم خليطًا من قواعد البيانات المتعددة.
يبدو أنه نهج جيد ، ولكن هناك تحديات. لكل خدمة مصغرة مجالها الخاص من البيانات ، وهو تصميم جيد ومُغلف. لكن البيانات الآن منتشرة ، ليس فقط بين قواعد البيانات المختلفة ، ولكن في تقنيات مختلفة. في هذا المشهد الجديد ، يحتاج فريقك إلى صيانة وترقية وشراء وترخيص وتصحيح ( log4j ، أي شخص؟) ، وتعلم تقنيات قواعد بيانات مختلفة ، ولكن يتعين عليهم أيضًا شراء وترخيص وبناء وصيانة وتصحيح (log4j مرة أخرى؟) ، وتعلم خطوط البيانات والتكامل بين تلك التقنيات. يُعرف هذا باسم "امتداد قاعدة البيانات".
الحلول: نموذج واحد ، وسحابة ، ونموذج متعدد
يمكن أن تساعد ثلاث طرق في تقليل توسع قاعدة البيانات:
- التوحيد في قاعدة بيانات واحدة
- قفل في مزود السحابة
- استخدم نهج متعدد النماذج
التوحيد في قاعدة بيانات واحدة (Standardize on a single database)
يعني هذا النهج أن تملي على مؤسستك ما يلي: "استخدم قاعدة البيانات هذه لكل شيء". إن زخم قاعدة البيانات العلائقية يجعلها خيارًا شائعًا: قد لا تكون الخيار الأفضل للبحث أو التخزين المؤقت أو الرسم البياني .
- الإيجابيات : يمكن لمجموعة المواهب الضخمة أن "تجعلها تعمل" مع الوقت أو المال الكافي
- السلبيات : غالي الثمن ، أقل رشاقة
بالنسبة للمؤسسات التي تعمل في مجال موحد لا يتغير كثيرًا ولا تحتاج إلى التعامل مع نطاق واسع ، فإن هذا النهج المكلف هو أحد الأساليب التي يجب مراعاتها.
قفل في مزود السحابة (Lock into a cloud provider)
قام موفرو السحابة المشهورون Azure و AWS و GCP بجمع قواعد بيانات مفتوحة المصدر وواجهات برمجة التطبيقات وتقنيات قواعد البيانات الخاصة بهم "كخدمة". يمكنهم تقديم مجموعة واسعة من قواعد البيانات التي تتوافق مع الخدمات المصغرة. نظرًا لأنهم يتحكمون في السحابة ، يمكنهم تقديم عمليات التكامل والتصحيح والصيانة بينهم جميعًا. لا يزال امتداد قاعدة البيانات ، لكنه عمل أقل.
- الإيجابيات : متجر شامل ، بوفيه من خيارات قاعدة البيانات
- السلبيات : يمكن أن يكون مكلفًا للغاية ، والتوافق مع المصدر المفتوح متخلفًا ، ولا يزال مترامي الأطراف
هذا النهج شائع ، لكنه ينطوي على مخاطر. إذا كانت تطبيقاتك مبنية فقط على AWS ، على سبيل المثال ، ماذا يحدث عندما يرتفع السعر أو تتم إزالة الميزة؟ يمكن أن تكون تكاليف التبديل الخاصة بك هائلة (ليس فقط بالدولار ، ولكن تكاليف الفرصة البديلة).
استخدم نهج متعدد النماذج
كيف يمكن لقاعدة بيانات NoSQL أن تتنافس مع الأنظمة البيئية العملاقة لـ Azure و AWS و GCP ولا تزال تساعدك على تجنب توسع قاعدة البيانات؟ الجواب هو قواعد البيانات "متعددة النماذج". هذه قواعد بيانات مبنية على تقنية تخزين بيانات واحدة ، ولكنها تقدم طرقًا متعددة لقراءة البيانات نفسها وكتابتها والوصول إليها.
- الإيجابيات : متجر شامل ، بوفيه من خيارات تفاعل البيانات ، يمكن استخدامه في السحب المتعددة
- السلبيات : جديد نسبيًا
انتظر لحظة ، هل قلت SQL؟
نعم ، SQL. إنه موجود في قواعد بيانات NoSQL الآن. تتحول قواعد البيانات غير العلائقية إلى لغة قواعد البيانات الأكثر نجاحًا والأكثر شهرة لوضعها في العمل على البيانات غير العلائقية (مثل JSON). يُعرف باسم SQL ++ ، وهو معيار ناشئ يتم دعمه بواسطة Couchbase و Amazon (PartiQL) و Microsoft (CosmosDB SQL).
نحن نشهد اندماجًا بين أفضل ما في العلائقية وأفضل ما في NoSQL يبدأ في الظهور. سريع ومرن مثل NoSQL ، مألوف مثل العلائقية ، نهج متعدد النماذج مقاوم للمستقبل ، ينضم معًا لجعل قصة قاعدة البيانات الخاصة بك ميسورة التكلفة.