Srovnání a výběr systémů migrace dat
Model dat v procesu vývoje se má tendenci měnit a v určitém okamžiku přestává odpovídat databázi. Samozřejmě, že databázi lze odstranit, a pak ORM vytvoří novou verzi, která bude odpovídat modelu, ale takový postup povede ke ztrátě stávajících dat. Funkce systému migrace tedy spočívá v tom, aby podle změny schématu synchronizoval model dat v aplikaci bez ztráty existujících dat.
V rámci tohoto článku bychom rádi prozkoumali různé nástroje pro správu migrací databází. Doufáme, že tento přehled bude užitečný pro vývojáře, kteří se s takovým výběrem setkali.
Úkol
V naší společnosti se nyní aktivně vyvíjí následující generace produktu – Docs Security Suite (DSS). Serverová část je napsána v .Net Core a jako SGBD se používá Entity Framework Core. Při návrhu aplikace používáme přístup Code First.
Doménový model aplikace vytvářejí současně několika vývojáři – každý odpovídá za svou logickou část systému.
V předchozí generaci DSS byla jako systém správy migrací používána klasická Entity Framework Migrations (EF 6). Nicméně se k němu nahromadily určité výtky, z nichž hlavní spočívala v tom, že v EF chybí rozumný přístup k řešení konfliktů verzí. Tento fakt nás dodnes trápí při opravách chyb v rámci podpory, proto bylo rozhodnuto prozkoumat alternativní možnosti.
V důsledku diskuse se utvořily následující požadavky na systém správy migrací:
- Podpora různých SGBD. Povinně MS SQL Server, PostgreSQL, Oracle, ale potenciálně je možné použít i další.
- Práce s ORM. Původně se plánovalo použít EF Core, avšak v návrhové fázi jsme byli připraveni zvážit i jiné ORM.
- Autogenerace migrací. Vzhledem k vývoji Code First bychom se rádi vyhnuli potřebě "psát ručně" migrace.
- Konflikty verzí. V podmínkách distribuovaného vývoje může při mergování EF Core docházet ke konfliktům. To se stává významným problémem, protože různé části aplikace vyvíjejí různí vývojáři, což si vyžaduje značné množství času na každý
- Rozsáhlá dokumentace a podpora. Zde, zdá se, není třeba vysvětlovat
- Bezplatnost. Kritérium je nepodmíněné, protože i docela levné systémy nebo drahé, ale ideální v pohodlí, jsme také byli ochotni zvážit
V důsledku malého průzkumu byly nalezeny a uznány jako žádoucí k uvážení následující možnosti:
- EF Core Migrations
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
A teď podrobněji
Samozřejmě, to byla první a hlavní volba. Nativní nástroj, který funguje z krabice bez jakýchkoli komplikací. Velké množství dokumentace, oficiální i neoficiální, jednoduchost atd. Nicméně námitky vznesené vůči klasickému EF jsou zcela aktuální i pro EF Core.
Takže pro EF Core byly vyzdviženy následující výhody:
- Podpora Microsoftu, dokumentace, včetně v ruštině, obrovská komunita
- Automatické generování migrací na základě CodeFirst
- Ve srovnání s EF 6 v EF Core nyní není uchovávána snapshot databáze. Při práci s EF Core v Code First nyní není nutné obnovovat databázi
- Pokud vycházíme z Code First – je zde možnost vedení jedné migrace pro všechny požadované datové přístupové poskytovatele
- Co se týče poskytovatelů – podporováno je jak PostgreSQL, tak Oracle atd., a dokonce – MS SQL Server :)
A také nevýhody:
- Řešení konfliktů zůstalo na stejné úrovni. Je nutné vystavět sekvenci migrací a aktualizovat snapshoty databáze
- Závislost na modelech, na jejichž základě byly migrace vygenerovány
DbUp
DbUp je knihovna pro .NET, která se instalje pomocí NuGet a pomáhá aplikovat změny na SQL Server. Sleduje, které skripty změn již byly provedeny, a spouští ty, které jsou nezbytné pro aktualizaci databáze. Knihovna vyrostla z projektu open-source blogovacího motoru na ASP.NET a existuje pod licencí MIT, a kód je dostupný na GitHubu. Migrace jsou popsány pomocí T-SQL.
Jaké jsou výhody:
- Podpora velkého množství SDB (MS SQL Server, PstgreSQL, MySQL)
- Protože skripty jsou psány v T-SQL, vypadají docela jednoduše
- Konflikty se také řeší pomocí SQL
Ale nevýhody:
- Přestože existuje široká škála podporovaných DBMS, Oracle mezi nimi není
- Nepracuje s ORM
- Psát skripty v T-SQL „ručně“ – to není to, čemu jsme chtěli směřovat
- Dokumentace a komunita jsou průměrné, i když v podmínkách psaní SQL skriptů to možná ani není potřeba.
RoundhousE
Tento nástroj pro správu migrací, distribuovaný pod licencí Apache 2.0, stejně jako předchozí, pracuje na enginu migrací T-SQL. Zdá se, že vývojáři přednostně řešili technické problémy v oblasti podpory DBMS, a ne vytváření komfortního vývoje.
Plusy:
- Podporuje potřebné DBMS (včetně Oracle)
Nevýhody:
- Oracle (a také pro nás zastaralý Access) není podporován na .NET Core, pouze na .NET Full Framework
- Nepracuje s ORM
- Dokumentace je ještě méně než u předchozího nástroje
- Opět – migrace jsou psány skripty
ThinkingHome.Migrator
Nástroj pro verzionování schématu databáze pro platformu .NET Core, distribuovaný pod licencí MIT. .
Plusy:
- Zaměřeno na .NET Core
- Realizována větvená sekvence migrací
- Realizováno logování migrací
Nevýhody:
- Poslední aktualizace – před rokem. Zdá se, že projekt není podporován
- Nepodporuje Oracle (v článku je uvedeno, že je to kvůli absenci stabilní implementace pro .NET Core – ale to před rokem)
- Chybí automatická generace migrací
Celkově projekt vypadá perspektivně, zejména pokud by se vyvíjel, ale museli jsme se rozhodnout hned teď.
Fluent Migrator
Nejoblíbenější nástroj pro migrace, který má velkou armádu fanoušků. Distribuován pod licencí Apache 2.0. Jak je uvedeno v popisu, je platformou migrace pro .NET, podobně jako Ruby on Rails Migrations. Změny schématu DB jsou popsány ve třídách na C#.
Zde jsou výhody:
- Podpora potřebných DBMS
- Podpora .NET Core
- Velká vyvinutá komunita
- Konflikty migrací se řeší sekvenčně – migracím je uveden pořadí provádění. Kromě toho, pokud dojde ke konfliktu kolem jedné entity, při sloučení kódu se jeho řešení provádí stejně jako v ostatním kódu
- Existují profily, které se provádějí po úspěšném dokončení migrace. Mohou obsahovat služby funkce. Poslední aktualizace byla před měsícem, což znamená, že projekt stále žije.
Pokud jde o nevýhody, máme zde:
- Chybí automatická generace migrací
- Chybí spojení s modely EF.
- Není k dispozici žádný snímek databáze.
Jaká byla naše volba?
Největší debaty se točily kolem dvou parametrů – automatická generace migrací a rozumného řešení konfliktů. Ostatní faktory nás tolik nevyděsily. Nakonec, na základě diskuse, se tým rozhodl použít v novém projektu Fluent Migrator. Řešení konfliktů v budoucnu přinese mnohem více výhod.
Závěry
Samozřejmě, neexistují dokonalé nástroje. I my jsme museli při výběru stanovit priority v našich "přáních". Avšak pro jiné týmy a úkoly mohou být rozhodující jiné faktory. Doufáme, že tento článek vám pomůže učinit rozhodnutí.
Zdroj: habr.com
