نظم إدارة قواعد البيانات الموزعة للمؤسسات

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

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

الإجابة على هذا السؤال غير متوقعة إلى حد ما: لا يمكن تقسيم مجموعة CA.
ما هو نوع هذه الكتلة التي لا يمكن أن تنقسم؟

السمة التي لا غنى عنها لمثل هذه المجموعة هي نظام تخزين البيانات المشترك. في الغالبية العظمى من الحالات، يعني هذا الاتصال عبر شبكة SAN، مما يحد من استخدام حلول CA للمؤسسات الكبيرة القادرة على الحفاظ على البنية التحتية لشبكة SAN. لكي تعمل خوادم متعددة بنفس البيانات، يلزم وجود نظام ملفات مجمع. تتوفر أنظمة الملفات هذه في مجموعات HPE (CFS) وVeritas (VxCFS) وIBM (GPFS).

أوراكل راك

ظهر خيار Real Application Cluster لأول مرة في عام 2001 مع إصدار Oracle 9i. في مثل هذه المجموعة، تعمل العديد من مثيلات الخادم مع نفس قاعدة البيانات.
يمكن لشركة Oracle العمل مع كل من نظام الملفات المجمع والحل الخاص بها - ASM، إدارة التخزين التلقائية.

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

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

ولكن ماذا يحدث إذا احتاجت إحدى الحالات إلى تغيير البيانات؟

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

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

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

الاستخدام الصحيح لـ Oracle RAC هو تقسيم البيانات فعليًا (على سبيل المثال، باستخدام آلية جدول مقسم) والوصول إلى كل مجموعة من الأقسام من خلال عقدة مخصصة. لم يكن الغرض الرئيسي من RAC هو القياس الأفقي، ولكن ضمان تحمل الخطأ.

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

• "تجميد" كافة الصفحات التي كانت موجودة في ذاكرة التخزين المؤقت للعقدة المفقودة؛
• يقرأ سجلات (إعادة) العقدة المفقودة ويعيد تطبيق التغييرات المسجلة في هذه السجلات، ويتحقق في نفس الوقت مما إذا كانت العقد الأخرى تحتوي على إصدارات أحدث من الصفحات التي يتم تغييرها؛
• التراجع عن المعاملات المعلقة.

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

أنظمة IBM Pure Data للمعاملات

ظهر حل عنقودي لنظام إدارة قواعد البيانات (DBMS) في محفظة Blue Giant في عام 2009. من الناحية الأيديولوجية، فهي خليفة مجموعة Parallel Sysplex المبنية على معدات "عادية". في عام 2009، تم إصدار DB2 pureScale كمجموعة برامج، وفي عام 2012، عرضت شركة IBM جهازًا يسمى Pure Data Systems for Transactions. لا ينبغي الخلط بينه وبين Pure Data Systems for Analytics، والذي لا يعدو كونه مجرد Netezza المعاد تسميته.

للوهلة الأولى، تشبه بنية pureScale Oracle RAC: بنفس الطريقة، ترتبط عدة عقد بنظام تخزين بيانات مشترك، وتقوم كل عقدة بتشغيل مثيل DBMS الخاص بها مع مناطق الذاكرة الخاصة بها وسجلات المعاملات. ولكن، على عكس Oracle، فإن DB2 لديه خدمة قفل مخصصة ممثلة بمجموعة من عمليات db2LLM*. في تكوين المجموعة، يتم وضع هذه الخدمة على عقدة منفصلة، ​​تسمى مرفق الاقتران (CF) في Parallel Sysplex، وPowerHA في Pure Data.

تقدم PowerHA الخدمات التالية:

• مدير القفل؛
• ذاكرة التخزين المؤقت العالمية؛
• مجال الاتصالات بين العمليات.

لنقل البيانات من PowerHA إلى عقد قاعدة البيانات وإعادتها، يتم استخدام الوصول إلى الذاكرة عن بعد، لذا يجب أن يدعم الاتصال البيني للمجموعة بروتوكول RDMA. يمكن لـ PureScale استخدام كلاً من Infiniband وRDMA عبر Ethernet.

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

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

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

"قذرة"، أي تم تغييرها، يمكن كتابة الصفحات على القرص من عقدة عادية ومن PowerHA (castout).

إذا فشلت إحدى عقد pureScale، فإن الاسترداد يقتصر فقط على تلك المعاملات التي لم تكتمل بعد في وقت الفشل: الصفحات التي تم تعديلها بواسطة تلك العقدة في المعاملات المكتملة موجودة في ذاكرة التخزين المؤقت العامة على PowerHA. تتم إعادة تشغيل العقدة بتكوين مخفض على أحد الخوادم الموجودة في المجموعة، وتتراجع عن المعاملات المعلقة وتحرر الأقفال.

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

تظهر اختبارات IBM الداخلية على عبء عمل بنسبة 90% للقراءة و10% للكتابة، وهو ما يشبه إلى حد كبير أعباء عمل الإنتاج في العالم الحقيقي، توسعًا خطيًا تقريبًا يصل إلى 128 عقدة. شروط الاختبار، للأسف، لم يتم الكشف عنها.

HPE NonStop SQL

تتمتع مجموعة Hewlett-Packard Enterprise أيضًا بمنصة خاصة بها متاحة للغاية. هذه هي منصة NonStop، التي تم طرحها في السوق عام 1976 بواسطة شركة Tandem Computers. وفي عام 1997، استحوذت شركة كومباك على الشركة، والتي اندمجت بدورها مع شركة هيوليت باكارد في عام 2002.

يتم استخدام NonStop لإنشاء تطبيقات مهمة - على سبيل المثال، HLR أو معالجة البطاقة المصرفية. يتم تسليم النظام الأساسي في شكل مجمع برمجيات وأجهزة (جهاز)، والذي يتضمن عقد الحوسبة ونظام تخزين البيانات ومعدات الاتصالات. تعمل شبكة ServerNet (في الأنظمة الحديثة - Infiniband) على التبادل بين العقد والوصول إلى نظام تخزين البيانات.

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

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

منذ عام 1987، تم تشغيل نظام إدارة قواعد البيانات العلائقية على منصة NonStop - أولاً SQL/MP، ثم SQL/MX لاحقًا.

تنقسم قاعدة البيانات بأكملها إلى أجزاء، وكل جزء مسؤول عن عملية إدارة الوصول إلى البيانات (DAM) الخاصة به. يوفر آليات تسجيل البيانات والتخزين المؤقت والقفل. تتم معالجة البيانات من خلال عمليات خادم Executor التي تعمل على نفس العقد مثل مديري البيانات المقابلين. يقوم برنامج جدولة SQL/MX بتقسيم المهام بين المنفذين وتجميع النتائج. عندما يكون من الضروري إجراء تغييرات متفق عليها، يتم استخدام بروتوكول الالتزام على مرحلتين الذي توفره مكتبة TMF (مرفق إدارة المعاملات).

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

ساب هانا

تم إطلاق أول إصدار مستقر لنظام HANA DBMS (1.0) في نوفمبر 2010، وتحولت حزمة SAP ERP إلى HANA في مايو 2013. تعتمد المنصة على التقنيات المشتراة: محرك بحث TREX (البحث في التخزين العمودي)، P*TIME DBMS وMAX DB.

كلمة "HANA" في حد ذاتها هي اختصار لـ High Performance ANalytical Appliance. يتم توفير نظام إدارة قواعد البيانات هذا في شكل تعليمات برمجية يمكن تشغيلها على أي خوادم x86، ومع ذلك، لا يُسمح بالتركيبات الصناعية إلا على المعدات المعتمدة. الحلول المتاحة من HP وLenovo وCisco وDell وFujitsu وHitachi وNEC. حتى أن بعض تكوينات Lenovo تسمح بالتشغيل بدون شبكة SAN - يتم لعب دور نظام التخزين المشترك بواسطة مجموعة GPFS على الأقراص المحلية.

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

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

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

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

المصدر: www.habr.com