قواعد البيانات في السحابة

مشكلة الساعة 2 فجراً التي تحلّها قاعدة بيانات مُدارة

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

ماذا تتولى "المُدارة" فعلياً

Amazon RDS هي النموذج المرجعي لقاعدة بيانات علائقية مُدارة، ووثائقها الرسمية دقيقة في تحديد التوزيع. قارن تشغيل قاعدة بيانات محلياً، وعلى نسخة EC2 عادية، وعلى RDS:

الانتقال من محلي إلى EC2 يسلّم العتاد المادي للمزوّد. الانتقال من EC2 إلى RDS يسلّم تقريباً كل شيء عن تشغيل محرّك قاعدة البيانات نفسه، تصحيح ونسخ احتياطي وتوسّع وكشف أعطال واستعادة. ما يبقى معك في كل عمود هو ضبط الاستعلامات، لأنه يعتمد كلياً على تطبيقك تحديداً واستعلاماتك وبياناتك، عمل لا تستطيع أي خدمة مُدارة أداءه نيابة عنك.

قواعد البيانات العلائقية: صفوف ترتبط بصفوف أخرى

تخيل جدول Orders لمتجر إلكتروني. يحتاج كل صف عمود customer_id يشير إلى صف حقيقي في جدول Customers منفصل، وعمود product_id يشير إلى صف في Inventory. تلك العلاقة المُلزَمة، طلب لا يمكن أن يوجد بلا عميل ومنتج مطابقَين، هي السمة الأساسية لقاعدة بيانات علائقية: بيانات منظَّمة في جداول بصفوف وأعمدة، تُستعلَم بـ SQL، ومرتبطة عبر الجداول بمفاتيح. تدعم Amazon RDS 6 محركات بهذا النموذج: MySQL وPostgreSQL وMariaDB وMicrosoft SQL Server وOracle Database وIBM Db2، جميعها قابلة للاستعلام بالنموذج العلائقي نفسه رغم اختلاف المحركات تحته.

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

قواعد بيانات NoSQL: استرجاع سريع بلا علاقات

تخيل الآن لوحة صدارة للعبة بـ10 ملايين لاعب متزامن، أو سلة تسوق تُقرأ وتُعاد كتابتها مع كل نقرة. لا يحتاج أي منهما ربطاً بجدول آخر، ولا يستفيد من عبء فرض علاقات الجداول. تتخلّى قواعد بيانات NoSQL، المبنية على نموذج Amazon DynamoDB، عن نموذج الجداول والربط لصالح عناصر تُسترجَع مباشرة بمفتاح، ببنية مرنة قد تختلف من عنصر لآخر. تعلن DynamoDB أداءً بأجزاء أحادية من الميلي ثانية سواء خدم التطبيق عشرات الآلاف أو مئات الملايين من المستخدمين المتزامنين، لأن التصميم بأكمله يتنازل عن العلاقات بين العناصر مقابل هذا النطاق.

الحد الفاصل: طابق النموذج مع نمط الوصول

مثال محلول: منصة واحدة، قاعدتا بيانات

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

تشغيل النموذجين جنباً إلى جنب، بدل إجبار كل نوع بيانات عبر نموذج واحد، بنية معتادة، لا حلّاً وسطاً.

الالتباس: الأحدث لا يعني الأفضل مطلقاً

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

إلى أين يقودك هذا

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