ما المقصود بنظرية CAP؟

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

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

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

تُسمى نظرية CAP أيضًا نظرية Brewer، لأنه تم تطويرها لأول مرة بواسطة البروفيسور Eric A. Brewer خلال حديث ألقاه عن الحوسبة الموزعة في عام 2000. وبعد ذلك بعامين، نشر الأستاذان في معهد ماساتشوستس للتكنولوجيا Seth Gilbert وNancy Lynch دليلًا على تخمين Brewer (Brewer’s Conjecture).

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

الاتساق

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

التوفر

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

تحمّل التقسيم

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

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

اليوم، يتم تصنيف قواعد بيانات NoSQL على أساس خاصيتَي CAP اللتين تدعمهما:

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

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

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

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

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

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

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

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

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

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