Porovnanie a výber systémov migrácie dát
Dátový model má tendenciu sa počas procesu vývoja meniť a v určitom bode už nezodpovedá databáze. Databázu je samozrejme možné vymazať a potom ORM vytvorí novú verziu, ktorá bude zodpovedať modelu, ale tento postup povedie k strate existujúcich údajov. Funkciou migračného systému je teda zabezpečiť, aby sa v dôsledku zmeny schémy synchronizoval s dátovým modelom v aplikácii bez straty existujúcich dát.
V tomto článku by sme sa chceli pozrieť na rôzne nástroje na správu migrácií databáz. Dúfame, že táto recenzia bude užitočná pre vývojárov, ktorí čelia podobnej voľbe.
Úloha
Naša spoločnosť v súčasnosti aktívne vyvíja novú generáciu produktu – Docs Security Suite (DSS). Serverová časť je napísaná v .Net Core a ako DBMS sa používa Entity Framework Core. Pri návrhu aplikácie používame prístup Code First.
Model aplikačnej domény vytvára niekoľko vývojárov súčasne – každý je zodpovedný za svoju logickú časť systému.
Predchádzajúca generácia DSS používala ako systém riadenia migrácie klasický Entity Framework Migrations (EF 6). Nahromadili sa však proti nej nejaké sťažnosti, z ktorých hlavnou je, že EF nemá rozumný prístup k riešeniu konfliktov verzií. Tento fakt nás stále rozčuľuje pri oprave chýb v rámci podpory, preto sme sa rozhodli zvážiť alternatívne možnosti.
Výsledkom diskusie boli nasledujúce požiadavky na systém riadenia migrácie:
- Podpora pre rôzne DBMS. Vyžaduje sa MS SQL Server, PostgreSQL, Oracle, ale potenciálne je možné použiť aj iné
- Práca s ORM. Pôvodne sa plánovalo použiť EF Core, ale vo fáze návrhu sme boli pripravení zvážiť iné ORM
- Automatické generovanie migrácií. Berúc do úvahy vývoj Code First, rád by som sa vyhol potrebe „ručného písania“ migrácií
- Konflikty verzií. V distribuovanom vývojovom prostredí môže pri zlučovaní EF Core trpieť konfliktmi. To sa stáva závažným problémom, pretože rôzne časti aplikácie vytvárajú rôzni vývojári, takže na každej musíte stráviť veľa času
- Pokročilá dokumentácia a podpora. Zdá sa nám, že tu nie je potrebné žiadne vysvetlenie
- Zadarmo. Kritérium je podmienené, pretože systémy nie sú veľmi drahé alebo drahé, ale ideálne z hľadiska pohodlia, boli sme tiež pripravení zvážiť
Ako výsledok malého výskumu boli nájdené a považované za vhodné na zváženie nasledujúce možnosti:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Plynulý migrátor
A teraz trochu podrobnejšie
Prirodzene, toto bola prvá a hlavná možnosť výberu. Natívny nástroj, ktorý funguje po vybalení bez akéhokoľvek hrania s tamburínou. Veľké množstvo dokumentácie, oficiálna a nie taká, jednoduchosť atď. Sťažnosti na klasický EF sú však celkom relevantné aj pre EF Core.
Výhody EF Core sú teda zdôraznené:
- Podpora spoločnosti Microsoft, dokumentácia vrátane ruštiny, obrovská komunita
- Automatické generovanie migrácií na základe CodeFirst
- V porovnaní s EF 6 už EF Core neukladá snímku databázy. Pri práci s EF Core v Code First už nie je potrebné nasadzovať databázu
- Keďže tancujeme od Code First, je možné vykonať jednu migráciu ku všetkým požadovaným poskytovateľom prístupu k dátam
- Čo sa týka poskytovateľov, je podporovaný PostgreSQL, podporovaný Oracle atď., atď., a dokonca aj MS SQL Server
A tiež nevýhody:
- Riešenie konfliktov zostalo na rovnakej úrovni. Je potrebné sekvenovať migrácie a aktualizovať snímky databázy
- Závislosť od modelov, na ktorých sú migrácie generované
DbUp
DbUp je knižnica .NET, ktorú inštaluje NuGet a pomáha prenášať zmeny na SQL Server. Sleduje, ktoré skripty zmien už boli spustené a spúšťa tie, ktoré sú potrebné na aktualizáciu databázy. Knižnica vyrástla z projektu pre open source blogovací nástroj na ASP.NET a existuje pod licenciou MIT a kód je na GitHub. Migrácie sú popísané pomocou T-SQL.
Aké sú výhody:
- Podpora veľkého množstva DBMS (MS SQL Server, PstgreSQL, MySQL)
- Keďže skripty sú napísané v T-SQL, vyzerajú celkom jednoducho
- Konflikty sa riešia aj pomocou SQL
A nevýhody:
- So všetkými rôznymi podporovanými DBMS, Oracle nie je jedným z nich
- Neinteraguje s ORM
- Ručné písanie T-SQL skriptov nie je to, o čo sme sa snažili
- Dokumentácia a komunita sú také, hoci z hľadiska písania SQL skriptov nemusia byť potrebné.
RoundhouseE
Tento nástroj na správu migrácie, distribuovaný pod licenciou Apache 2.0, rovnako ako predchádzajúci, beží na migračnom motore T-SQL. Zdá sa, že vývojári uprednostnili riešenie technických problémov týkajúcich sa podpory DBMS pred vytvorením pohodlného procesu vývoja.
Pros:
- Podporuje potrebné DBMS (vrátane Oracle)
Nevýhody:
- Oracle (ako aj Access, ktorý je pre nás nepodstatný) nie je podporovaný na .NET Core, iba na .NET Full Framework
- Nefunguje s ORM
- Dokumentácie je ešte menej ako predchádzajúci nástroj
- Opäť – migrácie sú písané skriptami
ThinkingHome.Migrator
Nástroj na migráciu schémy verzií databázy na platformu .NET Core, distribuovaný pod licenciou MIT.
Pros:
- Navrhnuté pre .NET Core
- Implementovaná vetviaca sekvencia migrácií
- Implementované protokolovanie migrácie
Nevýhody:
- Naposledy aktualizované pred rokom. Projekt zrejme nie je podporovaný
- Nepodporuje Oracle (v článku sa uvádza, že je to kvôli nedostatku stabilnej implementácie pre .NET Core - ale to je pred rokom)
- Žiadne automatické generovanie migrácií
Celkovo projekt vyzerá sľubne, najmä ak by sa mal rozvíjať, ale potrebovali sme sa rozhodnúť tu a teraz.
Plynulý migrátor
Najpopulárnejší migračný nástroj s veľkou armádou fanúšikov. Distribuované pod licenciou Apache 2.0. Ako je uvedené v popise, ide o migračný rámec pre .NET, podobný Ruby on Rails Migrations. Zmeny v schéme databázy sú popísané v triedach C#.
Tu sú výhody:
- Podpora pre požadované DBMS
- Podpora .NET Core
- Veľká rozvinutá komunita
- Konflikty medzi migráciami sa riešia postupne – je určené poradie vykonávania migrácií. Okrem toho, ak dôjde ku konfliktu okolo jednej entity, pri zlučovaní kódu sa to rieši rovnako ako vo zvyšku kódu
- Existujú profily, ktoré sa spustia po úspešnej migrácii. A môžu niesť servisné funkcie Posledná aktualizácia bola pred mesiacom, čiže projekt žije
Čo sa týka mínusov, tu sú:
- Žiadne automatické generovanie migrácií
- Žiadne spojenie s modelmi EF
- Žiadne snímky databázy
Aký bol náš výber?
Búrlivé debaty sa točili okolo dvoch parametrov – automatického generovania migrácií a rozumného riešenia konfliktov. Ostatné faktory boli oveľa menej desivé. V dôsledku toho sa tím na základe výsledkov diskusie rozhodol použiť v novom projekte Fluent Migrator. Pretože riešenie konfliktov v budúcnosti prinesie oveľa viac výhod.
Závery
Samozrejme, neexistujú žiadne dokonalé nástroje. Takže sme museli uprednostniť naše „chcenia“, aby sme sa mohli rozhodnúť. Pre iné tímy a iné úlohy však môžu byť rozhodujúce iné faktory. Dúfame, že vám tento článok pomôže pri výbere.
Zdroj: hab.com