Vergleich und Auswahl von Datenmigrationssystemen

Vergleich und Auswahl von Datenmigrationssystemen

Vergleich und Auswahl von Datenmigrationssystemen

Das Datenmodell neigt dazu, sich während des Entwicklungsprozesses zu ändern, und irgendwann stimmt es nicht mehr mit der Datenbank überein. Natürlich kann die Datenbank gelöscht werden, und dann erstellt der ORM eine neue Version, die dem Modell entspricht, aber dieser Vorgang führt zum Verlust vorhandener Daten. Die Funktion des Migrationssystems besteht also darin, es infolge einer Schemaänderung mit dem Datenmodell in der Anwendung zu synchronisieren, ohne dass vorhandene Daten verloren gehen.

In diesem Artikel möchten wir verschiedene Tools zur Verwaltung von Datenbankmigrationen betrachten. Wir hoffen, dass dieser Testbericht für Entwickler hilfreich sein wird, die vor einer ähnlichen Entscheidung stehen.

Aufgabe

Unser Unternehmen entwickelt derzeit aktiv die nächste Generation des Produkts – Docs Security Suite (DSS). Der Serverteil ist in .Net Core geschrieben und der Entity Framework Core wird jeweils als DBMS verwendet. Beim Entwerfen einer Anwendung verwenden wir den Code First-Ansatz.

Das Anwendungsdomänenmodell wird von mehreren Entwicklern gleichzeitig erstellt – jeder ist für seinen eigenen logischen Teil des Systems verantwortlich.

Die vorherige DSS-Generation nutzte das klassische Entity Framework Migrations (EF 6) als Migrationsmanagementsystem. Allerdings häuften sich einige Beschwerden gegen ihn, von denen die wichtigste darin bestand, dass es EF an einem vernünftigen Ansatz zur Lösung von Versionskonflikten mangele. Diese Tatsache stört uns immer noch, wenn wir im Rahmen des Supports Fehler beheben, sodass wir uns entschieden haben, alternative Optionen in Betracht zu ziehen.

Als Ergebnis der Diskussion wurden folgende Anforderungen an das Migrationsmanagementsystem formuliert:

  1. Unterstützung für verschiedene DBMS. Obligatorisch MS SQL Server, PostgreSQL, Oracle, es ist jedoch möglicherweise möglich, andere zu verwenden
  2. Arbeiten mit ORM Ursprünglich sollte EF Core zum Einsatz kommen, doch in der Entwurfsphase standen andere ORMs bereit, in Betracht gezogen zu werden
  3. Automatische Generierung von Migrationen. Angesichts der Entwicklung von Code First möchte ich die Notwendigkeit vermeiden, Migrationen „mit Stiften zu malen“.
  4. Versionskonflikte. In einer verteilten Entwicklungsumgebung kann es beim Zusammenführen von EF Core zu Konflikten kommen. Dies stellt ein erhebliches Problem dar, da verschiedene Teile der Anwendung von verschiedenen Entwicklern erstellt werden und Sie daher jeweils viel Zeit aufwenden müssen
  5. Entwickelte Dokumentation und Support. Hier bedarf es unserer Meinung nach keiner Erklärung.
  6. Frei. Das Kriterium ist bedingt, da wir keine sehr teuren oder teuren Systeme, aber ideal im Komfort, berücksichtigen wollten

Als Ergebnis einer kleinen Studie wurden die folgenden Optionen gefunden und als wünschenswert erachtet:

  1. EF Core-Migrationen
  2. DBup
  3. RoundhouseE
  4. ThinkingHome.Migrator
  5. Fließender Migrant

Und jetzt noch ein bisschen mehr

Vergleich und Auswahl von Datenmigrationssystemen
EntityFramework-Kernmigrationen

Dies war natürlich die erste und wichtigste Wahlmöglichkeit. Ein natives Instrument, das ohne Tamburintanz sofort funktioniert. Eine große Menge an offizieller und nicht offizieller Dokumentation, Einfachheit usw. Die gegenüber dem klassischen EF erhobenen Behauptungen gelten jedoch auch für EF Core.

Daher werden die Vorteile von EF Core hervorgehoben:

  • Microsoft-Support, Dokumentation, auch auf Russisch, eine riesige Community
  • Automatische Generierung von Migrationen basierend auf CodeFirst
  • Im Vergleich zu EF 6 speichert EF Core keinen Snapshot der Datenbank mehr. Bei der Arbeit mit EF Core in Code First ist die Bereitstellung der Datenbank nicht mehr erforderlich
  • Da wir von Code First ausgehen, ist es möglich, eine Migration zu allen erforderlichen Datenzugriffsanbietern durchzuführen
  • Die Anbieter unterstützen PostgreSQL, Oracle usw. usw. und sogar MS SQL Server 

Und auch Nachteile:

  • Die Konfliktlösung bleibt gleich. Es ist notwendig, eine Abfolge von Migrationen zu erstellen und Datenbank-Snapshots zu aktualisieren
  • Abhängigkeit von Modellen, auf deren Grundlage Migrationen generiert werden

DbUp

Vergleich und Auswahl von Datenmigrationssystemen
dbup.github.io

DbUp ist eine .NET-Bibliothek, die von NuGet installiert wird und dabei hilft, Änderungen an SQL Server zu übertragen. Es verfolgt, welche Änderungsskripte bereits ausgeführt wurden, und führt diejenigen aus, die zur Aktualisierung der Datenbank erforderlich sind. Die Bibliothek ist aus einem Open-Source-Blogging-Engine-Projekt auf ASP.NET hervorgegangen und steht unter der MIT-Lizenz. Der Code befindet sich auf GitHub. Migrationen werden mit T-SQL beschrieben.

Welche Vorteile gibt es hier:

  • Unterstützung für eine große Anzahl von DBMS (MS SQL Server, PstgreSQL, MySQL)
  • Da die Skripte in T-SQL geschrieben sind, sehen sie recht einfach aus.
  • Konflikte werden auch mit SQL gelöst

Und die Nachteile:

  • Bei all der Vielfalt der unterstützten DBMS gehört Oracle nicht dazu
  • Interagiert nicht mit ORM
  • Das Schreiben von Skripten in T-SQL mit „Handles“ ist nicht unser Ziel
  • Dokumentation und Community sind mittelmäßig, obwohl sie für das Schreiben von SQL-Skripten möglicherweise nicht erforderlich sind.

RoundhouseE

Vergleich und Auswahl von Datenmigrationssystemen
github.com/chucknorris/roundhouse

Dieses Migrationsverwaltungstool, das wie das vorherige unter der Apache 2.0-Lizenz vertrieben wird, läuft auf der T-SQL-Migrations-Engine. Anscheinend konzentrierten sich die Entwickler auf die Lösung technischer Probleme im Hinblick auf die Unterstützung des DBMS und nicht auf die Schaffung eines komfortablen Entwicklungsprozesses.

Profis:

  • Unterstützt das erforderliche DBMS (einschließlich Oracle)

Nachteile:

  • Oracle (sowie Access, was für uns irrelevant ist) wird auf .NET Core nicht unterstützt, sondern nur auf .NET Full Framework
  • Funktioniert nicht mit ORM
  • Noch weniger Dokumentation als das vorherige Tool
  • Noch einmal: Migrationen werden durch Skripte geschrieben

ThinkingHome.Migrator

Vergleich und Auswahl von Datenmigrationssystemen

Tool zur versionierten Migration des Datenbankschemas auf die .NET Core-Plattform, vertrieben unter der MIT-Lizenz. Der Entwickler selbst hat vor fast einem Jahr über seine neueste Version geschrieben.

Profis:

  • Maßgeschneidert für .NET Core
  • Eine verzweigte Migrationssequenz wurde implementiert
  • Migrationsprotokollierung implementiert

Nachteile:

  • Das letzte Update war vor einem Jahr. Offenbar wird das Projekt nicht unterstützt
  • Wird von Oracle nicht unterstützt (im Artikel heißt es, dass dies am Fehlen einer stabilen Implementierung für .NET Core liegt – das ist aber schon ein Jahr her)
  • Fehlende automatische Generierung von Migrationen

Im Allgemeinen sieht das Projekt vielversprechend aus, insbesondere wenn es sich entwickelt, aber wir mussten hier und jetzt eine Entscheidung treffen.

Fließender Migrant

Vergleich und Auswahl von Datenmigrationssystemen
github.com/fluentmigrator/fluentmigrator

Das beliebteste Migrationstool mit einer großen Fangemeinde. Verteilt unter der Apache 2.0-Lizenz. Wie in der Beschreibung angegeben, handelt es sich um ein Migrationsframework für .NET, ähnlich wie Ruby on Rails Migrations. Änderungen des Datenbankschemas werden in C#-Klassen beschrieben.

Hier gibt es Pluspunkte:

  • Unterstützung für das erforderliche DBMS
  • .NET Core-Unterstützung
  • Große entwickelte Gemeinschaft
  • Migrationskonflikte werden nacheinander gelöst – die Migrationsreihenfolge wird angegeben. Wenn außerdem beim Zusammenführen des Codes ein Konflikt um eine Entität auftritt, wird dieser auf die gleiche Weise gelöst wie im Rest des Codes.
  • Es gibt Profile, die nach einer erfolgreichen Migration ausgeführt werden. Und sie können Servicefunktionen tragen. Das letzte Update war vor einem Monat, das heißt, das Projekt lebt

Was die Nachteile betrifft, dann hier:

  • Fehlende automatische Generierung von Migrationen
  • Fehlende Kommunikation mit EF-Modellen
  • Keine DB-Snapshots

Was war unsere Wahl?

Vergleich und Auswahl von Datenmigrationssystemen

Die heißeste Debatte drehte sich um zwei Parameter – die automatische Generierung von Migrationen und eine vernünftige Konfliktlösung. Andere Faktoren machten uns viel weniger Angst. Aufgrund der Ergebnisse der Diskussion entschied sich das Team daher für den Einsatz von Fluent Migrator im neuen Projekt. Denn die Lösung von Konflikten wird in Zukunft noch viel mehr Vorteile mit sich bringen.

Befund

Natürlich gibt es keine perfekten Werkzeuge. Also mussten wir unsere „Wunschliste“ priorisieren, um eine Wahl zu treffen. Für andere Teams und andere Aufgaben können jedoch andere Faktoren ausschlaggebend sein. Wir hoffen, dass dieser Artikel Ihnen bei Ihrer Wahl hilft.

Source: habr.com

Kommentar hinzufügen