مقارنة واختيار أنظمة ترحيل البيانات

مقارنة واختيار أنظمة ترحيل البيانات

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

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

مهمة

تعمل شركتنا حاليًا بنشاط على تطوير الجيل التالي من المنتج - Docs Security Suite (DSS). جزء الخادم مكتوب في .Net Core ، ويستخدم Entity Framework Core باعتباره DBMS ، على التوالي. عند تصميم أحد التطبيقات ، نستخدم نهج Code First.

يتم إنشاء نموذج مجال التطبيق من قبل العديد من المطورين في نفس الوقت - كل منهم مسؤول عن الجزء المنطقي الخاص به من النظام.

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

نتيجة للمناقشة ، تم تشكيل المتطلبات التالية لنظام إدارة الترحيل:

1. دعم نظم إدارة قواعد البيانات المختلفة. إلزامي MS SQL Server ، PostgreSQL ، Oracle ، ولكن من المحتمل استخدام الآخرين
2. العمل مع ORM في البداية ، كان من المفترض استخدام EF Core ، ولكن في مرحلة التصميم ، كانت أدوات إدارة السجلات الأخرى جاهزة للنظر فيها
3. التوليد التلقائي للهجرات. نظرًا لتطور Code First ، أود تجنب الحاجة إلى "الرسم باستخدام الأقلام"
4. تعارضات الإصدار. في بيئة التطوير الموزعة ، عند الدمج ، يمكن أن تقع EF Core في النزاعات. تصبح هذه مشكلة كبيرة نظرًا لأن أجزاء مختلفة من التطبيق يتم إنشاؤها بواسطة مطورين مختلفين ، لذلك عليك قضاء الكثير من الوقت في كل منها
5. تطوير الوثائق والدعم. هنا ، يبدو لنا ، لا حاجة إلى تفسير.
6. حر. المعيار مشروط ، نظرًا لأن الأنظمة ليست باهظة الثمن أو باهظة الثمن ، ولكنها مثالية للراحة ، كنا أيضًا على استعداد للنظر فيها

نتيجة لدراسة صغيرة ، تم العثور على الخيارات التالية واعتبرت مرغوبة للنظر فيها:

1. هجرات EF الأساسية
2. DBup
3. RoundhouseE
4. التفكير في المنزل
5. المهاجر بطلاقة

والآن أكثر من ذلك بقليل

هجرات EntityFramework الأساسية

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

وبالتالي ، يتم تمييز المحترفين في EF Core:

• دعم Microsoft ، وثائق ، بما في ذلك باللغة الروسية ، مجتمع ضخم
• الإنشاء التلقائي لعمليات الترحيل استنادًا إلى CodeFirst
• مقارنةً بـ EF 6 ، لم يعد EF Core يخزن لقطة من قاعدة البيانات. لم يعد نشر قاعدة البيانات مطلوبًا عند العمل مع EF Core في Code First
• نظرًا لأننا نرقص من Code First ، فمن الممكن إجراء ترحيل واحد لجميع موفري الوصول إلى البيانات المطلوبين
• أما بالنسبة للموفرين ، فهو يدعم PostgreSQL و Oracle وما إلى ذلك وما إلى ذلك ، وحتى MS SQL Server 

وكذلك سلبيات:

• حل الصراع يبقى كما هو. من الضروري بناء سلسلة من عمليات الترحيل وتحديث لقطات قاعدة البيانات
• الاعتماد على النماذج التي يتم إنشاؤها بناءً على عمليات الترحيل

دبوب

dbup.github.io

DbUp هي مكتبة .NET يتم تثبيتها بواسطة NuGet وتساعد في دفع التغييرات إلى SQL Server. إنه يتتبع البرامج النصية للتغيير التي تم تنفيذها بالفعل ويقوم بتشغيل تلك البرامج اللازمة لتحديث قاعدة البيانات. نشأت المكتبة من مشروع محرك تدوين مفتوح المصدر على ASP.NET وموجود بموجب ترخيص MIT ، والشفرة موجودة على GitHub. يتم وصف عمليات الترحيل باستخدام T-SQL.

ما هي المزايا هنا:

• دعم عدد كبير من نظم إدارة قواعد البيانات (MS SQL Server ، PstgreSQL ، MySQL)
• نظرًا لأن البرامج النصية مكتوبة بلغة T-SQL ، فإنها تبدو بسيطة للغاية.
• يتم حل التعارضات أيضًا مع SQL

والعيوب:

• مع كل التنوع في نظم إدارة قواعد البيانات المدعومة ، فإن أوراكل ليست واحدة منها
• لا تتفاعل مع ORM
• كتابة النصوص في T-SQL مع "مقابض" ليست ما كنا نسعى جاهدين من أجله
• يعد التوثيق والمجتمع أمرًا رائعًا ، على الرغم من أنه من حيث كتابة نصوص SQL ، فقد لا تكون هناك حاجة إليها.

RoundhouseE

github.com/chucknorris/roundhouse

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

الايجابيات:

• يدعم DBMS المطلوبة (بما في ذلك Oracle)

سلبيات:

• لا يتم دعم Oracle (بالإضافة إلى Access ، الذي لا يهمنا) على .NET Core ، فقط على .NET Full Framework
• لا يعمل مع ORM
• توثيق أقل من الأداة السابقة
• مرة أخرى - تتم كتابة عمليات الترحيل بواسطة البرامج النصية

التفكير في المنزل

أداة لترحيل إصدار مخطط قاعدة البيانات إلى منصة .NET Core ، الموزعة بموجب ترخيص MIT. كتب المطور نفسه عن أحدث إصدار له منذ عام تقريبًا.

الايجابيات:

• مصمم خصيصًا لـ .NET Core
• نفذت سلسلة متفرعة من الهجرات
• تنفيذ تسجيل الترحيل

سلبيات:

• التحديث الأخير كان قبل عام. يبدو أن المشروع غير مدعوم
• غير مدعوم من Oracle (تنص المقالة على أن هذا يرجع إلى عدم وجود تطبيق مستقر لـ .NET Core - ولكن هذا منذ عام مضى)
• إنشاء تلقائي لعمليات الترحيل مفقود

بشكل عام ، يبدو المشروع واعدًا ، خاصة إذا تم تطويره ، لكننا كنا بحاجة لاتخاذ قرار هنا والآن.

المهاجر بطلاقة

github.com/fluentmigrator/fluentmigrator

أداة الترحيل الأكثر شيوعًا مع قاعدة جماهيرية كبيرة. يتم توزيعها بموجب ترخيص Apache 2.0. كما هو مذكور في الوصف ، هو إطار عمل ترحيل لـ .NET ، مشابه لـ Ruby on Rails Migrations. تم وصف تغييرات مخطط قاعدة البيانات في فئات C #.

هناك إيجابيات هنا:

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

أما السلبيات فهنا:

• إنشاء تلقائي لعمليات الترحيل مفقود
• الاتصال مفقود مع نماذج EF
• لا لقطات ديسيبل

ماذا كان خيارنا؟

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

النتائج

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

المصدر: www.habr.com