डेटा स्थलांतर प्रणालीची तुलना आणि निवड

डेटा स्थलांतर प्रणालीची तुलना आणि निवड

डेटा मॉडेल डेव्हलपमेंट प्रक्रियेदरम्यान बदलू शकतो आणि काही क्षणी ते डेटाबेसशी संबंधित नाही. अर्थात, डेटाबेस हटविला जाऊ शकतो आणि नंतर ORM मॉडेलशी जुळणारी नवीन आवृत्ती तयार करेल, परंतु या प्रक्रियेमुळे विद्यमान डेटा नष्ट होईल. अशा प्रकारे, स्थलांतरण प्रणालीचे कार्य हे सुनिश्चित करणे आहे की, स्कीमा बदलाच्या परिणामी, ते विद्यमान डेटा न गमावता अनुप्रयोगातील डेटा मॉडेलसह सिंक्रोनाइझ केले आहे.

या लेखात, आम्ही डेटाबेस स्थलांतर व्यवस्थापित करण्यासाठी विविध साधने पाहू इच्छितो. आम्हाला आशा आहे की हे पुनरावलोकन समान निवडीचा सामना करणार्‍या विकसकांसाठी उपयुक्त ठरेल.

उद्दिष्ट

आमची कंपनी सध्या उत्पादनाची पुढील पिढी सक्रियपणे विकसित करत आहे – Docs Security Suite (DSS). सर्व्हरचा भाग .Net Core मध्ये लिहिलेला आहे आणि Entity Framework Core हा DBMS म्हणून वापरला जातो. अनुप्रयोग डिझाइन करताना, आम्ही कोड फर्स्ट दृष्टिकोन वापरतो.

अनुप्रयोग डोमेन मॉडेल एकाच वेळी अनेक विकसकांद्वारे तयार केले जाते - प्रत्येक सिस्टमच्या त्यांच्या स्वतःच्या तार्किक भागासाठी जबाबदार आहे.

DSS च्या मागील पिढीने क्लासिक एंटिटी फ्रेमवर्क माइग्रेशन्स (EF 6) हे स्थलांतर व्यवस्थापन प्रणाली म्हणून वापरले. तथापि, त्याविरुद्ध काही तक्रारी जमा झाल्या आहेत, मुख्य म्हणजे EF कडे आवृत्तीतील विवादांचे निराकरण करण्यासाठी एक विवेकपूर्ण दृष्टीकोन नाही. समर्थनाचा एक भाग म्हणून बगचे निराकरण करताना ही वस्तुस्थिती आम्हाला अजूनही अस्वस्थ करते, म्हणून आम्ही पर्यायी पर्यायांचा विचार करण्याचा निर्णय घेतला.

चर्चेचा परिणाम म्हणून, स्थलांतर व्यवस्थापन प्रणालीसाठी खालील आवश्यकता तयार केल्या गेल्या:

1. विविध DBMS साठी समर्थन. एमएस एसक्यूएल सर्व्हर, पोस्टग्रेएसक्यूएल, ओरॅकल आवश्यक आहे, परंतु इतरांचा वापर करणे शक्य आहे
2. ORM सह कार्य करत आहे. सुरुवातीला, ईएफ कोर वापरण्याची योजना होती, परंतु डिझाइन स्टेजवर आम्ही इतर ओआरएमचा विचार करण्यास तयार होतो.
3. स्थलांतराची स्वयं-निर्मिती. कोड फर्स्टचा विकास लक्षात घेऊन, मी "हाताने लिहून" स्थलांतर करण्याची गरज टाळू इच्छितो
4. आवृत्ती विरोधाभास. वितरीत विकास वातावरणात, विलीनीकरण करताना, EF कोअरला संघर्षाचा त्रास होऊ शकतो. ही एक महत्त्वाची समस्या बनते कारण अनुप्रयोगाचे वेगवेगळे भाग वेगवेगळ्या विकसकांद्वारे तयार केले जातात, त्यामुळे तुम्हाला प्रत्येकावर बराच वेळ घालवावा लागतो.
5. प्रगत दस्तऐवज आणि समर्थन. येथे, आम्हाला असे दिसते की कोणत्याही स्पष्टीकरणाची आवश्यकता नाही
6. फुकट. निकष सशर्त आहे, कारण प्रणाली फार महाग किंवा महाग नाहीत, परंतु सोयीसाठी आदर्श आहेत, आम्ही विचार करण्यास देखील तयार होतो

थोड्या संशोधनाच्या परिणामी, खालील पर्याय सापडले आणि ते विचारात घेण्यासारखे आहेत:

1. EF कोर स्थलांतर
2. DBup
3. RoundhouseE
4. ThinkingHome.Migrator
5. अस्खलित स्थलांतर करणारा

आणि आता थोडे अधिक तपशील

EntityFramework कोर स्थलांतर

स्वाभाविकच, निवडण्यासाठी हा पहिला आणि मुख्य पर्याय होता. एक देशी वाद्य जे डफ वाजवल्याशिवाय बॉक्सच्या बाहेर काम करते. मोठ्या प्रमाणात कागदपत्रे, अधिकृत आणि तसे नाही, साधेपणा इ. तथापि, क्लासिक EF बद्दल केलेल्या तक्रारी EF Core साठी देखील समर्पक आहेत.

अशा प्रकारे, ईएफ कोरचे फायदे हायलाइट केले आहेत:

• मायक्रोसॉफ्ट समर्थन, दस्तऐवजीकरण, रशियन, प्रचंड समुदाय समावेश
• CodeFirst वर आधारित स्थलांतरांची स्वयं-निर्मिती
• EF 6 च्या तुलनेत, EF Core यापुढे डेटाबेसचा स्नॅपशॉट संचयित करत नाही. कोड फर्स्ट मध्ये EF Core सह काम करताना, यापुढे डेटाबेस तैनात करणे आवश्यक नाही
• आम्ही कोड फर्स्ट वरून नाचत असल्याने, सर्व आवश्यक डेटा ऍक्सेस प्रदात्यांकडे एक स्थलांतर करणे शक्य आहे
• प्रदात्यांबाबत, PostgreSQL समर्थित आहे, ओरॅकल समर्थित आहे, इ. इ. आणि अगदी MS SQL सर्व्हर 

आणि तोटे देखील:

• संघर्षाचे निराकरण समान पातळीवर राहिले. स्थलांतराचा क्रम आणि डेटाबेस स्नॅपशॉट अद्यतनित करणे आवश्यक आहे
• ज्या मॉडेल्सवर मायग्रेशन व्युत्पन्न केले जाते त्यावर अवलंबित्व

DbUp

dbup.github.io

DbUp ही .NET लायब्ररी आहे जी NuGet द्वारे स्थापित केली जाते आणि SQL सर्व्हरमध्ये बदल करण्यास मदत करते. कोणत्या बदल स्क्रिप्ट्स आधीच कार्यान्वित केल्या गेल्या आहेत याचा मागोवा ठेवते आणि डेटाबेस अपडेट करण्यासाठी आवश्यक असलेल्या स्क्रिप्ट चालवते. लायब्ररी ASP.NET वरील ओपन सोर्स ब्लॉगिंग इंजिनच्या प्रकल्पातून विकसित झाली आहे आणि MIT परवान्याअंतर्गत अस्तित्वात आहे आणि कोड GitHub वर आहे. स्थलांतराचे वर्णन T-SQL वापरून केले आहे.

फायदे काय आहेत:

• मोठ्या संख्येने DBMS (MS SQL Server, PstgreSQL, MySQL) साठी समर्थन
• स्क्रिप्ट T-SQL मध्ये लिहिलेल्या असल्याने, त्या अगदी सोप्या दिसतात
• एसक्यूएल वापरून विवादांचे निराकरण देखील केले जाते

आणि तोटे:

• सर्व प्रकारच्या समर्थित DBMS सह, Oracle त्यापैकी एक नाही
• ORM शी संवाद साधत नाही
• हाताने T-SQL स्क्रिप्ट लिहिणे हे आमचे ध्येय नव्हते
• दस्तऐवज आणि समुदाय इतकेच आहेत, जरी SQL स्क्रिप्ट लिहिण्याच्या दृष्टीने ते आवश्यक नसतील.

RoundhouseE

github.com/chucknorris/roundhouse

हे माइग्रेशन मॅनेजमेंट टूल, Apache 2.0 लायसन्स अंतर्गत वितरित केलेले, मागील प्रमाणे, T-SQL माइग्रेशन इंजिनवर चालते. वरवर पाहता, विकासकांनी आरामदायी विकास प्रक्रिया तयार करण्याऐवजी DBMS समर्थनाशी संबंधित तांत्रिक समस्या सोडविण्यास प्राधान्य दिले.

साधक:

• आवश्यक DBMS चे समर्थन करते (Oracle सह)

बाधक

• ओरॅकल (तसेच ऍक्सेस, जो आमच्यासाठी अप्रासंगिक आहे) .NET Core वर समर्थित नाही, फक्त .NET फुल फ्रेमवर्कवर
• ORM सह कार्य करत नाही
• मागील साधनापेक्षा कमी दस्तऐवजीकरण आहे
• पुन्हा - स्थलांतर स्क्रिप्टद्वारे लिहिलेले आहे

ThinkingHome.Migrator

MIT लायसन्स अंतर्गत वितरीत .NET Core प्लॅटफॉर्मवर आवृत्तीकृत डेटाबेस स्कीमा स्थलांतरासाठी एक साधन. विकसकाने स्वतः त्याच्या नवीनतम आवृत्तीबद्दल जवळजवळ एक वर्षापूर्वी लिहिले होते.

साधक:

• .NET Core साठी डिझाइन केलेले
• स्थलांतराचा शाखात्मक क्रम लागू केला
• स्थलांतर लॉगिंग लागू केले

बाधक

• एक वर्षापूर्वी शेवटचे अपडेट केले. वरवर पाहता प्रकल्प समर्थित नाही
• Oracle द्वारे समर्थित नाही (लेखात असे म्हटले आहे की हे .NET Core साठी स्थिर अंमलबजावणीच्या अभावामुळे आहे - परंतु हे एक वर्षापूर्वीचे आहे)
• स्थलांतराची स्वयंचलित निर्मिती नाही

एकंदरीत, प्रकल्प आशादायक दिसत आहे, विशेषत: जर तो विकसित करायचा असेल, परंतु आम्हाला येथे आणि आत्ताच निर्णय घेणे आवश्यक आहे.

अस्खलित स्थलांतर करणारा

github.com/fluentmigrator/fluentmigrator

चाहत्यांच्या मोठ्या सैन्यासह सर्वात लोकप्रिय स्थलांतर साधन. Apache 2.0 परवान्याअंतर्गत वितरीत केले. वर्णनात म्हटल्याप्रमाणे, हे .NET साठी एक स्थलांतर फ्रेमवर्क आहे, रुबी ऑन रेल माइग्रेशन्स प्रमाणेच. डेटाबेस स्कीमातील बदल C# वर्गांमध्ये वर्णन केले आहेत.

येथे फायदे आहेत:

• आवश्यक DBMS साठी समर्थन
• .NET कोर सपोर्ट
• मोठा विकसित समुदाय
• स्थलांतरांमधले मतभेद क्रमशः सोडवले जातात—स्थलांतराच्या अंमलबजावणीचा क्रम निर्दिष्ट केला जातो. याव्यतिरिक्त, जर एखाद्या घटकाभोवती संघर्ष उद्भवला तर, कोड विलीन करताना, त्याचे निराकरण उर्वरित कोडप्रमाणेच केले जाते.
• अशी प्रोफाइल आहेत जी यशस्वी स्थलांतरानंतर अंमलात आणली जातात. आणि ते सेवा कार्ये वाहून घेऊ शकतात शेवटचे अद्यतन एक महिन्यापूर्वी होते, म्हणजे, प्रकल्प जिवंत आहे

वजांबद्दल, ते येथे आहेत:

• स्थलांतराची स्वयंचलित निर्मिती नाही
• EF मॉडेलशी कोणतेही कनेक्शन नाही
• कोणतेही डेटाबेस स्नॅपशॉट नाहीत

आमची निवड काय होती?

गरमागरम वादविवाद दोन पॅरामीटर्सभोवती फिरले - स्थलांतराची स्वयंचलित निर्मिती आणि संघर्षांचे विवेकी निराकरण. इतर घटक खूपच कमी भयावह होते. परिणामी, चर्चेच्या निकालांच्या आधारे, टीमने नवीन प्रकल्पात Fluent Migrator वापरण्याचा निर्णय घेतला. कारण भविष्यात संघर्ष सोडवल्याने बरेच फायदे होतील.

निष्कर्ष

अर्थात, कोणतीही परिपूर्ण साधने नाहीत. म्हणून आम्हाला निवड करण्यासाठी आमच्या "इच्छा" ला प्राधान्य द्यावे लागले. तथापि, इतर संघ आणि इतर कार्यांसाठी, इतर घटक निर्णायक असू शकतात. आम्हाला आशा आहे की हा लेख आपल्याला निवड करण्यात मदत करेल.

स्त्रोत: www.habr.com