Migration von MSSQL nach PostgreSQL

Im Rahmen eines Studentenprojektes im Datenbankbereich war die Entwicklung einer Migrationsmöglichkeit von Microsoft-SQL-Server-Datenbanken zu PostgreSQL das Ziel. Folgende Aspekte erläutern, warum PostgreSQL immer attraktiver und ansprechender für die Kunden wird.

Auf der einen Seite ist MSSQL mit hohen Lizenzkosten verbunden und wird nur von Microsoft intern weiterentwickelt. Es gibt zwar eine Community, diese kann jedoch nur auf eventuelle Probleme hinweisen und Ideen einbringen. Auf der anderen Seite ist PostgreSQL das aktuellste und qualifizierteste Open-Source Relationale-Datenbankmanagementsystem (RDBMS). Die Entwickler, welche auf der ganzen Welt verteilt sind und zu denen unter anderem die Community zählt, legen Wert auf Zuverlässigkeit und Sicherheit, sodass die Verbesserung von PostgreSQL noch lange nicht abgeschlossen ist und es darum immer weiterentwickelt und optimiert wird. Dabei wird besonders auf fortschrittliche Technik geachtet und auf Nachfragen bzw. Probleme der User eingegangen. Deshalb ist PostgreSQL auch für Mac, Solaris und FreeBSD verfügbar. Außerdem verwaltet PostgreSQL über 300 Erweiterungen, welche nach Bedarf eingefügt und genutzt werden können. Aber der größte Faktor für dieses RDBMS, sind die geringen Supportkosten und die lizenzfreie Nutzung. Aufgrund dieser Vorteile nimmt PostgreSQL einen immer größer werdenden Anteil am Markt ein.

Abbildung 1 verdeutlicht das Interesse an PostgreSQL, indem dessen Popularität mit der von MSSQL verglichen wird. Obwohl beide RDBMS 1989 entwickelt wurden, setzte sich das kommerzielle System stark durch und gehörte zu den vorherrschenden Datenbanksystemen. Im Diagramm wird deutlich, dass MSSQL jahrelang über der 1000-Punkte-Grenze lag. Dennoch sank der Punktestand von MSSQL seit 2014 immer weiter. Im Gegensatz dazu gewann das Open-Source System, seit Ende des Jahres 2013 sehr stark an Punkten hinzu und nahm in den weiteren acht Jahren, um mehr als das Doppelte zu. Hier wird deutlich, dass PostgreSQL immer populärer wird und voraussichtlich in ein paar Jahren MSSQL überholt haben wird. Folglich möchten Kunden gerne zu PostgreSQL wechseln.

Deswegen wurde im Projekt ein passendes Tool gesucht und weiterentwickelt, welches Datenbanken von MSSQL nach PostgreSQL überträgt, damit die Möglichkeit besteht, die Kundenwünsche bezüglich des gewünschten RDBMS zu erreichen und so die Kundenzufriedenheit zu wahren.

Am Anfang wurde eine manuelle Migration durchgeführt, welche aufgrund von einigen Problemen bezüglich der Dauer der Migration und den unterschiedlichen, nicht direkt übertragbaren, datenspezifischen Objekten, nicht weiter in Betracht gezogen wurde.

Danach wurden einige bestehende Migrationsverfahren evaluiert und getestet, wobei auf die Funktionsweise, Dauer und Verständlichkeit des Tools geachtet wurde.

Anschließend wurde ein Tool von Yogi Mehla benutzt, welches folgende Vorteile hat. Durch ein Video und ein passendes Repository, ist das Verfahren sehr verständlich und leicht anzuwenden. Während der Migration wird jeweils ein Schritt in MSSQL oder PostgreSQL eingefügt und ausgeführt. Im ersten Schritt werden ein Skript für Schemata und Tabellen erstellt und dabei die Datentypen entsprechend für PostgreSQL angepasst. Um die Daten zu übertragen, werden diese in CSV-Dateien exportiert und im nächsten Schritt in PostgreSQL importiert. Zum Schluss werden die Primär- & Fremdschlüssel, Indizes und Constraints mit einem passenden Skript übertragen. Trotz dieser Vorteile gab es einige Probleme, welche im Rahmen des Projektes zum Teil behoben werden konnten. Dafür wurden zum Beispiel Datentypen angepasst und einige Skripte entwickelt, welche Spalten- und Tabellennamen umbenennen. Jedoch konnten einige Datenbanken trotzdem nicht migriert werden oder ihre Migration hat sehr viel Zeit in Anspruch genommen. Des Weiteren wird die Migration von Views, Funktionen, Usern und Prozeduren nicht unterstützt, da sich diese im Aufbau und in der Syntax unterscheiden.

Durch die vielen Kompromisse wurde innerhalb des Projektes eine bessere Lösung gesucht und in dem kostenlosen Migrationsverfahren von Igal Sapir gefunden. Das Tool überträgt alle Schemata, Tabellen und Daten mit dem Java Database Connectivity Treiber in die PostgreSQL Datenbank, ohne Probleme und größeren Aufwand. Mit wenigen Befehlen und einigen Anpassungen in der Konfigurations-Datei kann das Tool einfach verwendet werden. Jedoch kann dieses Migrationsverfahren keine Primär- & Fremdschlüssel, Constraints, sowie Indizes übertragen, sodass diese mittels des Skripts von Yogi Mehla nachträglich exportiert werden müssen. So verläuft die Migration einfacher und problemloser. Dennoch bleibt das Problem der Übertragung von Views, Funktionen, Usern und Prozeduren.

Grundsätzlich ist die Migration von MSSQL nach PostgreSQL möglich, obwohl einige Kompromisse eingegangen werden müssen. PostgreSQL ist ein Open-Source RDBMS, welches trotz der lizenzfreien Nutzung, einige versteckte Kosten birgt. Zuerst wird ein Server oder ein Rechenzentrum mit Servern benötigt, auf welchem die PostgreSQL-Datenbanken laufen. Um diese einzurichten und zu migrieren, werden neue Mitarbeiter mit der passenden Spezialisierung oder ein externer Dienstleister benötigt. Bei der Migration muss auf bestimmte Elemente, wie z.B. Trigger, spezielle Views und Funktionen verzichtet werden. Diese müssen durch erfahrene Fachkräfte "übersetzt", also neu entwickelt werden, was einen großen Aufwand und Kostenfaktor mit sich bringen kann. Nach der Datenübertragung gibt es noch viele Möglichkeiten Support zu erhalten. Nichtsdestotrotz gibt es zwei große Vorteile eines Open-Source RDBMS, nämlich die geringen Lizenzkosten und die vielen Entwickler, welche neue Erweiterungen und Lösungen für häufige Fehler entwickeln. Die Migration kann auch zu Problemen führen, da sich PostgreSQL in einigen Elementen, im Aufbau und in der Syntax von MSSQL unterscheidet. Somit können viele Funktionen wegfallen und die Applikation stören. Daher ist die Migration abhängig vom Migrationsbudget und der Datenbank, da je nach Kompatibilität der datenspezifischen Objekte und der internen Funktionen, ebendiese meist neu entwickelt werden müssen und so hohe Kosten entstehen können.

Seminarempfehlungen