إدارة المخطط مع Skeema

ملاحظة: يأتي هذا المنشور من فريق الهندسة في SendGrid. لمزيد من منشورات الهندسة التقنية مثل هذه ، تحقق من المدونات الفنية الخاصة بنا.

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

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

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

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

كيف ندير المخطط

تستخدم عملية إدارة المخطط الحالية لدينا مستودع Git واحدًا لتخزين المخطط الأولي لجميع مجموعات قواعد البيانات لدينا وتحتوي على جميع التغييرات اللاحقة على هذا المخطط حيث يتم تطبيق التغييرات / الإنشاء والإفلات على الجدول الفردي:

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

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

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

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

أدخل سكيما (وعدد قليل من المساعدين)

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

قمنا بأتمتة تطبيق تغييرات المخطط من التطوير المحلي إلى الإنتاج باستخدام أدواتنا الحالية ، Git و Buildkite CI و pt-online-schema-change مع إضافة واحدة أخرى ، Skeema.

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

Skeema هي أداة CLI تدير مخطط MySQL بطريقة تعريفية باستخدام SQL.

يمكنه إنشاء لغة تعريف البيانات (DDL) لكل جدول في قاعدة البيانات وتصدير DDL إلى نظام ملفات محلي للتكامل مع مستودع تتبع عبر Git. يمكن لـ Skeema مقارنة ملفات SQL في مستودع Git بقاعدة بيانات MySQL الحية وإخراج تلك الاختلافات على هيئة جمل DDL.

يمكن أيضًا تهيئته لاستخدام أداة تغيير مخطط pt-online-schema الخاصة بـ Percona وتنسيق الأمر الضروري pt-online-schema-change لمطابقة مخطط قاعدة بيانات MySQL قيد التشغيل مع المخطط المحدد في مستودع Git.

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

سيؤدي إنشاء مستودعات مخطط قاعدة بيانات MySQL الفردية إلى تفكيك مستودع Git الحالي المتجانسة db-schema والسماح للمطورين في فرق منفصلة بإدارة مخطط MySQL لتطبيقهم في المستودع الخاص بهم بدلاً من المستودع المشترك (مخطط db).

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

عنصر حيوي لأتمتة هذه العملية هو خط أنابيب Buildkite's CI. أنشأنا خط أنابيب:

• يتحقق من وجود أخطاء في بناء جملة SQL
• ينشئ خادم MySQL اختباريًا باستخدام الفرع الرئيسي الحالي لمخطط قاعدة البيانات ويختبر تطبيق التغييرات في طلب السحب (PR)
• تحقق من الاختلافات وقم بتطبيق تغييرات العلاقات العامة على بيئة MySQL للاختبار الخاصة بنا
• تحقق من الاختلافات وقم بتطبيق تغييرات العلاقات العامة على بيئة التدريج الخاصة بنا وقم بإخراج بعض إحصائيات الجدول من بيئة الإنتاج

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

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

بقدر ما يتعلق الأمر بحواجز الحماية ، فقد قمنا بتكوين Skeema بحيث لا تسمح بتغييرات المخطط المدمرة في الإنتاج كإعداد افتراضي.

التغييرات المدمرة مسموح بها في بيئات الاختبار والتشغيل.

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

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

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

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

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

يؤدي الجمع بين Git و pt-online-schema-change و Skeema و Buildkite CI إلى عملية موثوقة وقابلة للتكرار وبرمجية لتغييرات مخطط قاعدة بيانات MySQL. إنه يمكّن المطورين من إدارة مخطط قواعد البيانات الخاصة بهم بأمان والتحكم في مدى سرعة طرح الميزات والإصلاحات في الإنتاج.

يوفر تضمين حواجز الحماية المناسبة في ملفات التكوين الخاصة بتغيير Skeema و pt-online-schema ، مقياسًا للثقة للمطورين الذين ينفذون تغييرات المخطط ويعطي ملاحظات قيمة حول الطرق الممكنة للمضي قدمًا في تغيير المخطط في حالة إصابة تلك الحواجز.

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