Andmete migratsioonisüsteemide võrdlemine ja valimine
Andmete mudel arendamise protsessis muutub ja mingil hetkel ei vasta see enam andmebaasile. Muidugi saab andmebaasi kustutada ning ORM loob uue versiooni, mis vastab mudelile, kuid selline protseduur toob endaga kaasa olemasolevate andmete kaotuse. Seetõttu seisneb süsteemi migreerimise funktsioon selles, et skeemi muutumise korral sünkroonida see rakenduse andmemudeliga ilma olemasolevaid andmeid kaotamata.
Käesolevas artiklis soovime tutvuda erinevate tööriistadega andmebaasi migreerimise haldamiseks. Loodame, et see ülevaade on kasulik arendajatele, kes seisavad silmitsi sellise valikuga.
Ülesanne
Meie ettevõttes käib aktiivne järgmise genereerimise toote arendamine – Docs Security Suite (DSS). Serveripool on kirjutatud .Net Core'is ja andmebaasina kasutatakse loomulikult Entity Framework Core'i. Rakenduse projekteerimisel kasutame lähenemist Code First.
Rakenduse domeenimudelit loovad mitmed arendajad üheaegselt – igaüks vastutab oma loogilise osa süsteemist.
Eelmises DSS-i põlvkonnas kasutati migratsioonide haldamiseks klassikalist Entity Framework Migrations (EF 6). Siiski on sellele kogunenud teatud etteheiteid, peamine neist on see, et EF-il puudub mõistlik lähenemisviis versioonikonfliktide lahendamisele. See fakt teeb meid endiselt kurvaks vigade parandamise käigus toe raames, seetõttu otsustati kaaluda alternatiivseid võimalusi.
Arutelu tulemusena kujunesid järgmised nõuded migratsioonihalduse süsteemile:
- Toetab erinevaid andmebaasihaldussüsteeme. Kohustuslikult MS SQL Server, PostgreSQL, Oracle, kuid potentsiaalselt on võimalik kasutada ka teisi.
- Töö ORM-iga. Algselt oli plaan kasutada EF Core'i, kuid projekteerimise etapis oldi valmis kaaluma ka teisi ORM-e.
- Migratsioonide automaatne genereerimine. Arvestades Code First arendust, sooviks vältida vajadust migratsioone "käega" kirja panna.
- Versioonide konfliktid. Jaotatud arenduse tingimustes võib EF Core merge'i käigus kokku puutuda konfliktidega. See muutub suureks probleemiks, kuna rakenduse erinevaid osi loovad erinevad arendajad, mistõttu kulub igaühega tegelemiseks palju aega.
- Arendatud dokumentatsioon ja tugi. Siin ei vaja me arvatavasti selgitusi.
- Tasuta. Kriteerium on tinglik, kuna oleme valmis kaaluma ka mitte liiga kalliseid süsteeme või väga kalliseid, kuid mugavuse poolest ideaalseid.
Väikese uuringu tulemuseks leiti ja tunnistati soovitavateks järgmised valikud:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Nüüd veidi põhjalikumalt
Muidugi oli see esimene ja peamine valik. Kohalik tööriist, mis töötab otse välja kastist ilma igasuguste keerutusteta. Palju dokumentatsiooni, nii ametlikku kui ka mitte, lihtsus jne. Siiski on klassikalistele EF-i puudustele esitatud pretensioonid täiesti asjakohased ka EF Core'i puhul.
Seega on EF Core'i jaoks välja toodud plusstid:
- Microsofti tugi, dokumentatsioon, sealhulgas vene keeles, tohutu kogukond.
- Koodist genereeritud migreerimised
- Kui EF 6-s salvestati andmebaasi hetkeseis, siis EF Core'is seda enam ei tehta. EF Core'iga töötades ei ole enam vajalik andmebaasi välja pakkuda, kui kasutatakse Code First'i.
- Kuna alustame Code First'ist, siis on võimalus hallata ühte migreerimist kõigi vajalike andmebaasi juurdepääsuteenuste jaoks.
- Toetatakse nii PostgreSQL-i kui Oracle'i jne. ning isegi – MS SQL Serverit 😊.
Samuti on puudused:
- Konfliktide lahendamine on sama tasemel. On vajalik migreerimiste järjestuse kehtestamine ja andmebaasi hetkeseisude uuendamine.
- Migratsioonide genereerimise mudelite sõltuvus.
DbUp
DbUp on .NET-i teek, mis installitakse NuGet'i kaudu ning aitab SQL Serveris muudatusi rakendada. See jälgib, millised muudatuste skriptid on juba täidetud, ja käivitab need, mis on vajalikud andmebaasi uuendamiseks. Teek on välja kasvanud avatud lähtekoodiga blogimootori projektist ASP.NET-is ja eksisteerib MIT litsentsi all, kood on saadaval GitHubis. Migratsioonid on kirjeldatud T-SQL-i abil.
Millised on eelised:
- Toetatakse suurt hulka andmebaasimootoreid (MS SQL Server, PostgreSQL, MySQL).
- Kuna skriptid on kirjutatud T-SQL-is, näevad need üsna lihtsad välja.
- Konflikte lahendatakse ka SQL abil
Aga miinused:
- Kuigi toetatakse suurt hulka andmebaase, ei kuulu Oracle nende hulka
- Ei tööta ORM-iga
- T-SQL skriptide kirjutamine käsitsi – ei ole see, mida me otsisime
- Dokumentatsioon ja kogukond on keskpärased, kuigi SQL-skriptide kirjutamise tingimustes võivad need olla mitte vajalikud.
RoundhousE
See migreerimise haldustööriist, mida levitatakse Apache 2.0 litsentsi all, töötab nagu eelmine T-SQL migratsiooni mootoril. Tundub, et arendajad keskendusid tehniliste probleemide lahendusele andmebaaside toetuse osas, mitte mugava arendusprotsessi loomisele.
Plussid:
- Toetab vajalikud andmebaasid (sealhulgas Oracle)
Miinused:
- Oracle (ja samuti meile mitteaktiivne Access) ei toimi .NET Core peal, ainult .NET Full Framework'il
- Ei tööta ORM-iga
- Dokumentatsioon on veel vähem kui eelmisel tööriistal
- Taaskord - migratsioonid kirjutatakse skriptidega
ThinkingHome.Migrator
Versioonide migreerimise tööriist andmebaasi skeemi jaoks .NET Core platvormile, mida levitatakse MIT litsentsi all. .
Plussid:
- Kohandatud .NET Core jaoks
- Olenematu migreerimise haruline jada on rakendatud
- Migrationide logimine on ellu viidud
Miinused:
- Viimane uuendus – aasta tagasi. Tundub, et projekt ei ole enam toetatud
- Oracle ei ole toetatud (artikkel märgib, et see on tingitud stabiilse rakenduse puudumisest .NET Core'i jaoks – kuid see oli aasta tagasi)
- Migratsioonide automaatne genereerimine puudub
Kokkuvõttes näeb projekt paljutõotav välja, eriti kui see oleks edasi arenenud, kuid meil tuli siin ja kohe otsus langetada.
Fluent Migrator
Kõige populaarsem migratsioonitööriist, millel on suur jälgijaskond. Levitatakse Apache 2.0 litsentsi alusel. Kirjelduses on märgitud, et see on migratsiooniplatvorm .NET-ile, sarnane Ruby on Railsi migratsioonidele. Andmebaasi skeemimuudatused on kirjeldatud C# klassides.
Siin on mõned eelised:
- Toetab vajalikke DBMS-e
- Toetab .NET Core'i
- Suure arenenud kogukond
- Migratsioonide konfliktid lahendatakse järjekindlalt – migratsioonidel on määratud teostamise järjekord. Lisaks, kui konflikt tekib ühe üksuse ümber, lahendatakse selle ühendamise käigus sama moodi nagu muus koodis.
- On olemas profiilid, mis täidetakse pärast migrationi edukat lõpetamist. Need võivad sisaldada teenusefunktsioone. Viimane värskendus oli kuu aega tagasi, mis tähendab, et projekt on aktiivne.
Mis puudutab miinuseid, siis siin need on:
- Migratsioonide automaatne genereerimine puudub
- Puudub seos EF mudelitega.
- Puuduvad andmebaasi pildid.
Kuidas meie valik välja nägi?
Kõige tulisemad vaidlused keerlesid kahe parameetri ümber – migratsioonide automaatne genereerimine ja mõistlik lahendus konfliktide lahendamiseks. Ülejäänud tegurid olid oluliselt vähem hirmutavad. Lõpuks otsustas meeskond arutelu tulemusena kasutada uues projektis Fluent Migratorit. Konfliktide lahendamine toob tulevikus palju rohkem eeliseid.
Järeldused
Loomulikult pole ideaalseid tööriistu. Ka meie valikul tuli seada prioriteete meie «soovides». Siiski võivad teiste meeskondade ja teiste ülesannete jaoks olla otsustavad ka teised tegurid. Loodame, et see artikkel aitab teil teha õige valiku.
Allikas: habr.com
