Porovnání a výběr systémů pro migraci dat
Datový model má tendenci se v průběhu vývoje měnit a v určitém okamžiku přestane odpovídat databázi. Databázi lze samozřejmě smazat a poté ORM vytvoří novou verzi, která bude odpovídat modelu, ale tento postup povede ke ztrátě stávajících dat. Funkcí migračního systému je tedy zajistit, aby v důsledku změny schématu došlo k jeho synchronizaci s datovým modelem v aplikaci bez ztráty existujících dat.
V tomto článku bychom se rádi zabývali různými nástroji pro správu migrací databází. Doufáme, že tato recenze bude užitečná pro vývojáře, kteří se potýkají s podobnou volbou.
Úkol
Naše společnost v současné době aktivně vyvíjí další generaci produktu - Docs Security Suite (DSS). Serverová část je napsána v .Net Core a jako DBMS je použito Entity Framework Core. Při návrhu aplikace používáme přístup Code First.
Model aplikační domény vytváří několik vývojářů současně - každý je zodpovědný za svou vlastní logickou část systému.
Předchozí generace DSS používala jako systém řízení migrace klasický Entity Framework Migrations (EF 6). Nahromadily se však proti němu nějaké stížnosti, z nichž hlavní byla ta, že EF postrádá rozumný přístup k řešení konfliktů verzí. Tato skutečnost nás stále rozčiluje při opravách chyb v rámci podpory, proto bylo rozhodnuto zvážit alternativní možnosti.
Výsledkem diskuse byly následující požadavky na systém řízení migrace:
- Podpora různých DBMS. Povinný MS SQL Server, PostgreSQL, Oracle, ale potenciálně je možné použít i jiné
- Práce s ORM Původně se předpokládalo použití EF Core, ale ve fázi návrhu byly připraveny ke zvážení další ORM
- Automatické generování migrací. Vzhledem k vývoji Code First bych se rád vyhnul nutnosti migrace „malovat perem“.
- Konflikty verzí. V distribuovaném vývojovém prostředí může při sloučení dojít ke konfliktům EF Core. To se stává významným problémem, protože různé části aplikace jsou vytvářeny různými vývojáři, takže na každé musíte strávit spoustu času.
- Vyvinutá dokumentace a podpora. Zde se nám zdá, že není potřeba žádné vysvětlení.
- Volný, uvolnit. Kritérium je podmíněné, protože ne příliš drahé systémy nebo drahé, ale ideální z hlediska pohodlí, byli jsme také připraveni zvážit
V důsledku malé studie byly nalezeny následující možnosti a považovány za vhodné ke zvážení:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Plynulý migrátor
A teď trochu víc
Přirozeně to byla první a hlavní možnost výběru. Nativní nástroj, který funguje po vybalení bez tance na tamburíně. Velké množství dokumentace, oficiální a ne tak, jednoduchost atd. Nároky vznesené proti klasickému EF jsou však docela relevantní i pro EF Core.
Pro EF Core jsou tedy zdůrazněny klady:
- Podpora společnosti Microsoft, dokumentace, včetně ruské, obrovská komunita
- Automatické generování migrací na základě CodeFirst
- Ve srovnání s EF 6 již EF Core neukládá snímek databáze. Při práci s EF Core v Code First již není potřeba nasazování databáze
- Protože tančíme z Code First, je možné provést jednu migraci ke všem požadovaným poskytovatelům přístupu k datům
- Co se týče poskytovatelů, podporuje PostgreSQL, Oracle atd. atd., a dokonce i MS SQL Server
A také nevýhody:
- Řešení konfliktů zůstává stejné. Je nutné sestavit sekvenci migrací a aktualizovat databázové snímky
- Závislost na modelech, na základě kterých se migrace generují
DbUp
DbUp je knihovna .NET, kterou instaluje NuGet a pomáhá prosazovat změny na SQL Server. Sleduje, které skripty změn již byly provedeny, a spouští ty potřebné k aktualizaci databáze. Knihovna vyrostla z projektu open source blogovacího enginu na ASP.NET a existuje pod licencí MIT a kód je na GitHubu. Migrace jsou popsány pomocí T-SQL.
Jaké jsou zde výhody:
- Podpora velkého počtu DBMS (MS SQL Server, PstgreSQL, MySQL)
- Vzhledem k tomu, že skripty jsou napsány v T-SQL, vypadají docela jednoduše.
- Konflikty jsou také řešeny pomocí SQL
A nevýhody:
- Se všemi různými podporovanými DBMS není Oracle jedním z nich
- Neinteraguje s ORM
- Psaní skriptů v T-SQL pomocí „handles“ není to, o co jsme usilovali
- Dokumentace a komunita je taková, i když z hlediska psaní SQL skriptů nemusí být potřeba.
RoundhouseE
Tento nástroj pro správu migrace, distribuovaný pod licencí Apache 2.0, stejně jako předchozí, běží na migračním jádru T-SQL. Vývojáři se zjevně zaměřili na řešení technických problémů z hlediska podpory DBMS, spíše než na vytvoření pohodlného vývojového procesu.
výhody:
- Podporuje požadované DBMS (včetně Oracle)
nevýhody:
- Oracle (stejně jako Access, který je pro nás irelevantní) není podporován na .NET Core, pouze na .NET Full Framework
- Nefunguje s ORM
- Ještě méně dokumentace než předchozí nástroj
- Opět - migrace jsou psány skripty
ThinkingHome.Migrator
Nástroj pro verzovanou migraci databázového schématu na platformu .NET Core, distribuovaný pod licencí MIT. .
výhody:
- Na míru pro .NET Core
- Implementována větvená sekvence migrací
- Implementováno protokolování migrace
nevýhody:
- Poslední aktualizace byla před rokem. Projekt zřejmě není podporován
- Nepodporováno Oracle (článek uvádí, že je to kvůli chybějící stabilní implementaci pro .NET Core - ale to je před rokem)
- Chybí automatické generování migrací
Obecně projekt vypadá slibně, zvláště pokud se rozvinul, ale potřebovali jsme se rozhodnout tady a teď.
Plynulý migrátor
Nejoblíbenější migrační nástroj s velkou základnou fanoušků. Distribuováno pod licencí Apache 2.0. Jak je uvedeno v popisu, jedná se o migrační rámec pro .NET, podobný Ruby on Rails Migrations. Změny schématu databáze jsou popsány ve třídách C#.
Tady jsou plusy:
- Podpora pro požadované DBMS
- Podpora .NET Core
- Velká rozvinutá komunita
- Konflikty migrace se řeší postupně - je určeno pořadí migrace. Pokud navíc vznikne konflikt kolem jedné entity, při slučování kódu se to řeší stejně jako ve zbytku kódu.
- Existují profily, které se spustí po úspěšné migraci. A mohou nést servisní funkce Poslední aktualizace proběhla před měsícem, tedy projekt žije
Pokud jde o nevýhody, pak zde:
- Chybí automatické generování migrací
- Chybí komunikace s modely EF
- Žádné snímky db
Jaká byla naše volba?
Nejžhavější debata se točila kolem dvou parametrů – automatického generování migrací a rozumného řešení konfliktů. Jiné faktory vyděsily mnohem méně. Na základě výsledků diskuse se tým rozhodl v novém projektu použít Fluent Migrator. Pro řešení konfliktů v budoucnu přinese mnohem větší počet plusů.
Závěry
Samozřejmě neexistují dokonalé nástroje. Takže jsme museli upřednostnit náš "Wishlist", abychom si mohli vybrat. Pro jiné týmy a jiné úkoly však mohou být rozhodující jiné faktory. Doufáme, že vám tento článek pomůže s výběrem.
Zdroj: www.habr.com