تمت كتابة الكثير من المقالات حول تحديث الأنظمة بسرعة دون إيقافها (نشر بدون توقف) والعديد من جوانب هذا النهج واضحة إلى حد ما. في رأيي ، فإن أصعب جزء من النشر في هذه الحالة هو تحديث مستودعات البيانات إذا تغير عقدهم (مخططهم). هذا هو الجانب الذي أود أن أعتبره في هذه المقالة.
مهما كانت قاعدة البيانات - مع مخطط بيانات صريح كعلاقة أو مع مخطط تعسفي مثل NoSQL - لا يزال نظام البيانات موجودًا ، حتى على مستوى التطبيق. يجب أن تكون البيانات المقروءة من قاعدة البيانات مفهومة للعميل ، حتى لو لم يفرض المستودع نفسه أي قيود على هيكله.
افترض أن نظامًا بهيكل بيانات محدد و تيرابايت من البيانات في قاعدة البيانات قيد التشغيل بالفعل في الإنتاج. في الإصدار الجديد من النظام ، نحتاج إلى تغيير الهيكل بشكل طفيف لتطبيق ميزات جديدة أو تحسين الأداء. فكر في التغييرات التي قد تحدث في الدائرة:
- إضافة حقل جديد
- حذف الحقل
- إعادة تسمية الحقل
- تغييرات نوع الحقل
- نقل حقل إلى بنية بيانات أخرى (على سبيل المثال ، في حالة إلغاء التطبيع)
تعد إضافة حقل جديد بالإضافة إلى إضافة أي كائن قاعدة بيانات آخر تغييرًا متوافقًا مع الإصدارات السابقة ولا يتطلب أي خطوات إضافية من حيث تنفيذ النشر بوقت تعطل صفر (مع تحذير واحد - إذا كان هذا الحقل أو الكائن الجديد لا يعتمد وظيفياً على الحقول الأخرى المخزنة بالفعل في قاعدة البيانات البيانات). ببساطة تطبيق التغييرات على قاعدة البيانات على الطاير ، ثم نشر نسخة جديدة من التعليمات البرمجية التي تستخدم كائنات قاعدة البيانات الجديدة.
لا يعد حذف حقل أو أي كائن قاعدة بيانات آخر تغييرًا متوافقًا للخلف ، ولكن طريقة تنفيذه بسيطة للغاية - يجب حذف كائنات قاعدة البيانات غير الضرورية فقط بعد أن يصبح الإصدار الجديد من النظام في حالة توقف تام.
تعتبر الأنواع الثلاثة الأخرى من التغييرات أكثر تعقيدًا من حيث توفير نشر بدون توقف. بشكل عام ، يمكن تنفيذها جميعًا عن طريق نسخ البيانات إلى الحقول / الكيانات الأخرى ، وحذف الحقول "القديمة" بعد الترحيل الناجح للبيانات: لإعادة التسمية ، يمكنك نسخ البيانات من الحقل القديم إلى حقل باسم جديد ، ثم حذف الحقل القديم ، وتغيير نوع البيانات يمكن القيام به مع إعادة التسمية ، إلخ. بطريقة أو بأخرى ، على مدار فترة من الزمن ، يجب أن تدعم قاعدة البيانات العقود القديمة والجديدة. هناك طريقتان على الأقل لإجراء مثل هذه التغييرات بسرعة:
إذا كانت قاعدة البيانات تدعم المشغلات
- قم بإنشاء مشغلات تقوم بنسخ البيانات من المكان القديم إلى المكان الجديد عند أي تغيير / إضافة وتعيينها على الإنتاج.
- تطبيق أداة تحويل البيانات التي تفعل الشيء نفسه ، ولكن لجميع السجلات في قاعدة البيانات. نظرًا لأن المشغلات مثبتة بالفعل ، فقد لا تقوم الأداة المساعدة بأي شيء أكثر تعقيدًا من مجرد تحديث "وهمي" لكل سجل (UPDATE table SET field = field ...). نقطة مهمة جدًا هنا هي أن إجراء قراءة البيانات من المكان القديم والكتابة إلى الجديد يجب أن يكون ذريًا ومحميًا من التغييرات المفقودة. اعتمادًا على بنية قاعدة البيانات ، يمكنك استخدام إما تأمين متشائم عبر SELECT FOR UPDATE أو نظائرها ، أو متفائل إذا كان الجدول يحتوي على حقل يحتوي على إصدار سجل.
- بعد انتهاء الأداة من عملها (اعتمادًا على مقدار البيانات وتعقيد التحديث ، قد يستغرق وقت التنفيذ أيامًا) ، من الممكن بالفعل تثبيت إصدار جديد من النظام الذي يدعم نظام البيانات الجديد. عند هذه النقطة ، سيتم تحويل جميع السجلات الموجودة في قاعدة البيانات التي كانت موجودة في وقت تشغيل الأداة المساعدة بنجاح ، وسيتم أيضًا تحويل جميع السجلات الجديدة التي ظهرت أثناء تشغيلها بواسطة المشغلات.
- حذف المشغلات وجميع الحقول (أو كائنات قاعدة البيانات الأخرى) التي لم تعد هناك حاجة إليها.
إذا لم يكن من الممكن استخدام المشغلات (كما هو الحال مع العديد من حلول NoSQL)
- قم بإنشاء ونشر إصدار جديد من التطبيق (الإصدار المؤقت 1 في الشكل) ، والذي يقرأ دائمًا من الحقل القديم ، ولكن عند الكتابة إلى هذا الحقل ، فإنه يقوم بتحديث كل من القديم والمكان الجديد المقابل (في الشكل "C" - القديم ، "H" - جديد). Zadeplit هذا الإصدار لجميع العقد التي يتم تشغيل مثيلات التطبيق عليها.
- قم بتطبيق أداة تقوم بنسخ البيانات من الموقع القديم إلى الموقع الجديد. كما هو الحال مع المحفزات ، تحتاج إلى اتخاذ خطوات لمنع التغييرات المفقودة.
- قم بإنشاء إصدار آخر من التطبيق وتثبيته عند اكتمال الأداة (الإصدار المؤقت 2) ، والذي يقرأ البيانات من حقل جديد ، ولكنه لا يزال يكتب في مكانين. هذه الخطوة ضرورية ، لأنه أثناء التحديث المتسلسل لكل عقد ستظل هناك فجوة عندما تعمل مثيلات الإصدار السابق من التطبيق الذي يقرأ الحقل القديم في وقت واحد مع الإصدار الجديد.
- قم بإنشاء النسخة الكاملة من النسخة السابقة ونشرها في نهاية النسخة النهائية ، والتي لا تتفاعل بالفعل مع الحقل القديم.
- حذف الحقول القديمة.
يتطلب النهج الثاني إنشاء وتثبيت ثلاثة إصدارات مختلفة من التطبيق ، والتي يمكن أن تكون مزعجة للغاية ومرهقة. بدلاً من ذلك ، يمكنك استخدام تبديل الميزات - لوضع منطق جميع الإصدارات الثلاثة في إصدار واحد ، ولكن قم بتبديل الوضع وفقًا لمعلمة التكوين ، والتي يمكن بشكل مثالي تبديلها بسرعة. وبالتالي ، بدلاً من تثبيت كل إصدار لاحق ، سيكون كافياً لتغيير قيمة المعلمة (وإعادة تشغيل الخدمة إذا لم يتم توفير تحديث التكوين بسرعة). بعد الانتهاء بنجاح من تثبيت الإصدار النهائي ، يجب إزالة جميع التعليمات البرمجية المتعلقة بضمان ترحيل البيانات بالكامل من الفرع العامل ، حتى إذا كانت "مباشرة" عند الإنتاج حتى التحديث التالي للنظام.
من السهل ملاحظة أن ضمان عدم التوقف عن العمل عند تحديث النظام هو إجراء مرهق وهش ، لذلك من المنطقي أن تهتم به فقط إذا كان هناك متطلبات مقابلة من الشركة. ولكن حتى إذا كانت متطلبات توفر النظام منخفضة للغاية (على سبيل المثال ، 99٪ في السنة والنافذة لتحديث النظام المخطط هو 24 ساعة) ، فقد يستغرق تحويل البيانات المطلوبة لتثبيت الإصدار الجديد وقتًا أطول. لذلك ، يجب أن تكون مستعدًا مسبقًا لاستخدام هذه الحلول إذا كنت تخطط لتخزين كميات كبيرة من البيانات.
قد يكون النهج البديل هو الرفض المتعمد للتغييرات المتوافقة مع السابقة في مخطط قاعدة البيانات ، ولكن لسوء الحظ ، في الواقع ، لا يمكن تحقيقه دائمًا ، نظرًا لأن الطريقة الأكثر فاعلية لتحسين أداء الوصول إلى البيانات هي في الغالب إعادة هيكلة المخطط.