Andmemigratsioonisüsteemide võrdlus ja valik
Andmemudel kipub arendusprotsessi käigus muutuma ja mingil hetkel ei vasta enam andmebaasile. Loomulikult saab andmebaasi kustutada ja seejärel loob ORM uue versiooni, mis sobib mudeliga, kuid see protseduur toob kaasa olemasolevate andmete kadumise. Seega on migratsioonisüsteemi ülesanne tagada, et skeemi muutmise tulemusena sünkroniseeritakse see rakenduses oleva andmemudeliga ilma olemasolevaid andmeid kaotamata.
Selles artiklis tahaksime vaadata erinevaid tööriistu andmebaaside migratsiooni haldamiseks. Loodame, et see ülevaade on kasulik arendajatele, kes seisavad silmitsi sarnase valikuga.
Ülesanne
Meie ettevõte arendab praegu aktiivselt järgmise põlvkonna toodet – Docs Security Suite (DSS). Serveri osa on kirjutatud .Net Core'is ja DBMS-ina kasutatakse Entity Framework Core'i. Rakenduse kujundamisel kasutame Code First lähenemist.
Rakenduse domeeni mudeli loovad mitu arendajat korraga – igaüks vastutab oma süsteemi loogilise osa eest.
Eelmine põlvkond DSS-i kasutas migratsioonihaldussüsteemina klassikalist olemiraamistiku migratsiooni (EF 6). Selle peale on aga kogunenud mõned kaebused, millest peamine on see, et EF-l puudub mõistuspärane lähenemine versioonikonfliktide lahendamisele. See asjaolu häirib meid endiselt toe osana vigade parandamisel, mistõttu otsustasime kaaluda alternatiivseid võimalusi.
Arutelu tulemusena kujunesid migratsioonihaldussüsteemile järgmised nõuded:
- Erinevate DBMS-ide tugi. Vajalikud on MS SQL Server, PostgreSQL, Oracle, kuid potentsiaalselt on võimalik kasutada ka teisi
- Töö ORM-iga. Algselt oli plaanis kasutada EF Core'i, kuid projekteerimisetapis olime valmis kaaluma ka teisi ORM-e.
- Migratsioonide automaatne genereerimine. Võttes arvesse Code Firsti arengut, sooviksin vältida vajadust “käsitsi kirjutada” migratsioone
- Versioonide konfliktid. Hajutatud arenduskeskkonnas võib EF Core liitmisel konfliktide käes kannatada. See muutub oluliseks probleemiks, kuna rakenduse erinevad osad on loonud erinevad arendajad, mistõttu peate kulutama igaühele palju aega.
- Täiustatud dokumentatsioon ja tugi. Meile tundub, et siin pole selgitust vaja
- Tasuta. Kriteerium on tingimuslik, kuna süsteemid ei ole väga kallid ega kallid, kuid mugavuse poolest ideaalsed, olime ka valmis kaaluma
Väikese uurimistöö tulemusena leiti järgmised võimalused, mida soovitati kaaluda:
- EF põhimigratsioonid
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Ladus rändaja
Ja nüüd natuke täpsemalt
Loomulikult oli see esimene ja peamine valik. Omapärane pill, mis töötab karbist välja võttes, ilma tamburiiniga askeldamata. Suur hulk dokumentatsiooni, ametlik ja mitte nii, lihtsus jne. Kuid klassikalise EF-i kohta esitatud kaebused on ka EF Core'i jaoks üsna asjakohased.
Seega tuuakse esile EF Core'i eelised:
- Microsofti tugi, dokumentatsioon, sealhulgas vene keeles, tohutu kogukond
- CodeFirstil põhinevate migratsioonide automaatne genereerimine
- Võrreldes EF 6-ga ei salvesta EF Core enam andmebaasi hetktõmmist. Kui töötate EF Core'iga programmis Code First, ei ole enam vaja andmebaasi juurutada
- Kuna me tantsime Code First'ist, on võimalik läbi viia üks migratsioon kõikidele nõutavatele andmetele juurdepääsu pakkujatele
- Pakkujate osas on toetatud PostgreSQL, toetatud Oracle jne jne ja isegi MS SQL Server
Ja ka puudused:
- Konfliktide lahendamine jäi samale tasemele. On vaja järjestada migratsioone ja värskendada andmebaasi hetktõmmiseid
- Sõltuvus mudelitest, mille alusel migratsioonid genereeritakse
DbUp
DbUp on .NET-i teek, mille installib NuGet ja mis aitab SQL Serveri muudatusi edasi lükata. See jälgib, millised muudatusskriptid on juba käivitatud, ja käivitab need, mis on vajalikud andmebaasi värskendamiseks. Raamatukogu kasvas välja ASP.NET-i avatud lähtekoodiga ajaveebimootori projektist ja eksisteerib MIT-i litsentsi all ning kood on GitHubis. Migratsioone kirjeldatakse T-SQL-i abil.
Millised on eelised:
- Tugi paljudele DBMS-idele (MS SQL Server, PstgreSQL, MySQL)
- Kuna skriptid on kirjutatud T-SQL-is, näevad need üsna lihtsad välja
- Konfliktid lahendatakse ka SQL-i abil
Ja miinused:
- Erinevate toetatud DBMS-ide tõttu pole Oracle üks neist
- Ei suhtle ORM-iga
- T-SQL-i skriptide käsitsi kirjutamine ei ole see, mille eesmärk oli
- Dokumentatsioon ja kogukond on nii ja naa, kuigi SQL-i skriptide kirjutamise seisukohast ei pruugi need olla vajalikud.
RoundhouseE
See migratsioonihaldustööriist, mida levitatakse Apache 2.0 litsentsi all, nagu ka eelmine, töötab T-SQL-i migratsioonimootoris. Ilmselt eelistasid arendajad DBMS-i toega seotud tehniliste probleemide lahendamist, mitte mugava arendusprotsessi loomist.
plussid:
- Toetab vajalikku DBMS-i (sh Oracle)
miinuseid:
- Oracle (nagu ka meie jaoks ebaoluline Access) ei ole .NET Core'is toetatud, ainult .NET Full Frameworkis
- Ei tööta ORM-iga
- Dokumentatsiooni on veelgi vähem kui eelmisel tööriistal
- Jällegi – migratsioonid kirjutavad skriptid
ThinkingHome.Migrator
Tööriist versioonitud andmebaasi skeemi migreerimiseks .NET Core platvormile, mida levitatakse MIT litsentsi alusel. .
plussid:
- Mõeldud .NET Core'i jaoks
- Rakendatud on rände hargnev jada
- Rakendatud migratsiooni logimine
miinuseid:
- Viimati uuendatud aasta tagasi. Ilmselt projekti ei toetata
- Oracle ei toeta (artiklis öeldakse, et selle põhjuseks on .NET Core'i stabiilse juurutuse puudumine – aga see on aasta tagasi)
- Ei mingit automaatset migratsiooni genereerimist
Üldiselt tundub projekt paljulubav, eriti kui see peaks arenema, kuid me pidime tegema otsuse siin ja praegu.
Ladus rändaja
Kõige populaarsem rändetööriist suure fännide armeega. Levitatakse Apache 2.0 litsentsi alusel. Nagu kirjelduses öeldud, on see .NET-i migratsiooniraamistik, mis sarnaneb Ruby on Rails Migrationsiga. Andmebaasi skeemi muudatusi kirjeldatakse C# klassides.
Siin on eelised:
- Nõutava DBMS-i tugi
- .NET Core tugi
- Suur arenenud kogukond
- Konfliktid migratsioonide vahel lahendatakse järjestikku – täpsustatakse migratsioonide teostamise järjekord. Lisaks kui ühe olemi ümber tekib konflikt, siis koodi liitmisel lahendatakse see samamoodi nagu ülejäänud koodis
- On profiile, mis käivitatakse pärast edukat migreerimist. Ja need võivad kanda teenindusfunktsioone.Viimane uuendus oli kuu aega tagasi ehk projekt on elus
Mis puudutab miinuseid, siis siin on need:
- Ei mingit automaatset migratsiooni genereerimist
- Puudub ühendus EF mudelitega
- Andmebaasi hetktõmmised puuduvad
Mis oli meie valik?
Tulised vaidlused keerlesid kahe parameetri ümber – migratsioonide automaatne genereerimine ja konfliktide mõistlik lahendamine. Muud tegurid olid palju vähem hirmutavad. Selle tulemusena otsustas meeskond arutelu tulemuste põhjal uues projektis kasutada Fluent Migratorit. Sest konfliktide lahendamine tulevikus toob palju rohkem kasu.
Järeldused
Loomulikult pole ideaalseid tööriistu olemas. Seega pidime valiku tegemiseks seadma oma "soovid" esikohale. Teiste meeskondade ja muude ülesannete puhul võivad aga määravaks saada muud tegurid. Loodame, et see artikkel aitab teil valikut teha.
Allikas: www.habr.com