نظرية CAP

menu icon

نظرية CAP

في هذا الدليل، نقوم باستعراض نظرية CAP وأهميتها عند تصميم التطبيقات الموزعة واختيار NoSQL أو ملف تخزين البيانات العلاقية.

ما هي نظرية CAP؟

هل شاهدت من قبل إعلانا لمنسق حدائق أو عامل طلاء المنازل أو أحد التجار الآخرين يبدأ بالعنوان الرئيسي "رخيص وسريع وجيد: اختر اثنين"؟

تطبق نظرية CAP نوعا مماثلا من المنطق على الأنظمة الموزعة — على وجه التحديد، النظام الموزع يمكنه فقط تحقيق اثنين من ثلاث خصائص مرغوب فيها: الاتساق والإتاحة والتسامح مع خطأ التقسيم ('C' و'A' و'P' في CAP).

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

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

شرح 'CAP' في نظرية CAP

دعونا نلقي نظرة مفصلة على خصائص النظام الموزع الثلاثة التي تشير إليها نظرية CAP.

الاتساق

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

الاتاحة

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

التسامح مع خطأ التقسيم

التقسيم هو انقطاع الاتصالات في نظام موزع — اتصال تم فقده أو تم تأجيله مؤقتا بين عقدتين. ويعني التسامح مع خطأ التقسيم أن نظام المجموعة يجب أن يستمر في العمل على الرغم من أي عدد من انقطاعات الاتصال بين العقد في النظام.

أنواع قواعد بيانات NoSQL لنظرية CAP

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

اليوم، يتم تصنيف قواعد بيانات NoSQL بناء على اثنين من خصائص CAP التي تقوم بدعمها:

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

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

MongoDB ونظرية CAP ‏(CP)

MongoDB هو نظام إدارة قواعد بيانات NoSQL شائع يقوم بتخزين البيانات كوثائق BSON ‏(JSON ثنائي). يتم استخدامه بشكل متكرر للبيانات الضخمة وتطبيقات الوقت الفعلي التي يتم تشغيلها في عدة أماكن مختلفة. بالنسبة إلى نظرية CAP، يعد MongoDB ملف تخزين بيانات CP — فهو يقوم بحل تقسيمات شبكة الاتصال عن طريق الحفاظ على الاتساق، مع المساومة على الإتاحة.

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

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

Cassandra ونظرية CAP ‏(AP)

Apache Cassandra هي قاعدة بيانات NoSQL مفتوحة المصدر تتولي Apache Software Foundation تشغيلها. وهي قاعدة بيانات عريضة العمود تتيح لك تخزين البيانات على شبكة موزعة. ومع ذلك، على عكس MongoDB، تتمتع Cassandra ببنية لا مثيل لها، ونتيجة لذلك، يكون لديها العديد من نقاط الفشل، بدلا من نقطة واحدة.

بالنسبة إلى نظرية CAP، فإن Cassandra هي قاعدة بيانات AP — فهي توفر الإتاحة والتسامح مع خطأ التقسيم ولكن لا يمكنها تحقيق الاتساق طوال الوقت. نظرا لأن Cassandra لا تحتوي على عقدة رئيسية، يجب أن تكون جميع العقد متاحة باستمرار. ومع ذلك، توفر Cassandra الاتساق النهائي من خلال السماح للعملاء بالكتابة على أي عقد في أي وقت والتسوية بين أوجه عدم الاتساق بأسرع ما يمكن.

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

التعامل مع الخدمات المصغرة

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

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

نظرية CAP وIBM Cloud

تقدم شركة IBM مجموعة كاملة من خدمات قواعد البيانات التي يتم إدارتها بالكامل. وإلى جانب أنظمة إدارة قواعد البيانات العلاقية، يمكنك أيضا تشغيل MongoDB وCloudant (ملف تخزين بيانات AP موزع آخر) وElasticsearch وetcd، وحلول قواعد البيانات الأخرى على IBM Cloud.

لإلقاء نظرة على اختيار قاعدة البيانات بالكامل (بدون أي التزام)، قم بالتسجيل للحصول على IBMid وتكوين حساب IBM Cloud الخاص بك.