Daniel Westermann 13. Dezember 2016

Breaking the deadlock: Migration von proprietären Datenbank-Systemen zu PostgreSQL

Ein Pluspunkt von PostgreSQL ist, dass es überall läuft und unterstützt wird. © jijomathai / Fotolia.com — © jijomathai / Fotolia.com

Haben Sie schon darüber nachgedacht, wie Ihre Datenbank-Infrastruktur in fünf oder zehn Jahren aussehen soll? Wollen Sie sich an den einen oder anderen Hersteller binden oder wagen Sie den Schritt zu einer wirklich offenen Infrastruktur? Wer es nicht schafft, seine Infrastruktur nach offenen Standards auszurichten, wird aller Voraussicht nach den Anschluss verpassen.

Über die letzten Jahre kamen alle bahnbrechenden Innovationen aus der Open Source-Community, z. B. Docker und Openstack, um nur zwei zu nennen. Die Entwicklung schreitet so schnell voran, dass es immer unwahrscheinlicher wird, dass bestehende Monoliten in sich stetig verändernde Landschaften integriert werden können.

Mit PostgreSQL gibt es seit 25 Jahren einen wirkliches Open Source-Datenbank-System, das sich nahtlos in bestehende Infrastrukturen integriert und mehr und mehr auch den alten Platzhirschen die Vorreiterschaft streitig macht. Das mag den einen oder anderen überraschen, wer sich jedoch die Entwicklung der letzten Jahre ansieht, den kann es nicht wirklich wundern, dass PostgreSQL eine echte Alternative geworden ist. Als einziges Open Source-Datenbank-System unterstützt PostgreSQL beispielsweise ab Version 9.6 das parallele Ausführen von SQL Anweisungen. Alle Features die im Enterprise-Umfeld unverzichtbar sind, sind vorhanden und werden stetig erweitert und verbessert:

Hochverfügbarkeit
Backup und Point-in-Time-Recovery (PITR)
Partitionierung
Row-Level Security (RLS)
Server side programming (Functions, Triggers)
Parallel SQL Execution
Foreign Data Wrappers (SQL/MED)
NoSQL-Datentypen (hstore,json,jsonb)
Volltextsuche
Logische Replikation (ab PostgreSQL 10, 2017)
Unzählige Erweiterungen für nahezu jeden Anwendungsfall
Unzählige Open Source-Projekte, die sich mit PostgreSQL integrieren lassen oder das Core-Produkt erweitern

Was liegt also näher, als eine Migration der bestehenden proprietären Datenbank-Systeme nach PostgreSQL zumindest anzudenken? Das spart nicht nur Kosten, sondern ist auch eine Investition in die Zukunft. Es gab und es wird auch nie eine Firma PostgreSQL geben. PostgreSQL ist ein wirkliches Community-Projekt, vergleichbar mit dem Linux-Kernel. Jeder kann mitmachen aber niemand kann es kaufen. Und genau hier liegt eine der Stärken: Kein Investor bestimmt die Richtung, sondern nur das, was gemeinschaftlich in der Community beschlossen wird.

Ein weiterer Pluspunkt von PostgreSQL ist, dass es nahezu überall läuft und auch unterstützt wird: Seien es die diversen Linux-Derivate, sei es Microsoft Windows, HPUX, AIX, eine des BSD-Variationen, Solaris oder OSX. Das was in Ihrem Haus bevorzugt verwendet wird, kann eingesetzt werden. Wenn also die Entscheidung gefallen ist, eine Migration nach PostgreSQL zu evaluieren, worauf ist zu achten?

Die Applikations-Hersteller

Sollen bestehende Applikationen migriert werden, hängt der Erfolg oder Misserfolg maßgeblich von den Herstellern der Applikationen ab. Sind diese mit einem bestimmten Produkt verheiratet und es gibt keinen Willen, ein anderes Datenbank-System zu unterstützen, gibt es nur zwei Möglichkeiten: Entweder man belässt alles so wie es ist oder man zieht eine andere Applikation in Betracht. Falls der Hersteller jedoch gewillt ist, an einer Migration mitzuarbeiten oder die Applikation sogar selbst zu entwickeln, dann sind die Erfolgsaussichten enorm hoch. Viele Hersteller sehen den Vorteil von Open Source-Datenbanken heute durchaus und sind dementsprechend gewillt, in diese Richtung zu investieren. Hierzu gab es in letzter Zeit einige prominente Beispiele:

Yandex [1]
Infor [2]
EMC Documentum [3]

Hat man diese erste Hürde genommen, wie geht es weiter?

Die Datenmigration

Wie holprig oder geschmeidig eine Migration nach PostgreSQL technisch abläuft, hängt sehr mit dem Datenbank-System zusammen, von dem migriert werden soll. Ein erster Schritt ist sicherlich die Migration der Daten an sich – ohne jegliche Geschäftslogik. Dieser Schritt läuft normalerweise problemlos und es gibt diverse Werkzeuge, die dabei unterstützen können.

Foreign Data Wrappers

PostgreSQL bietet seit PostgreSQL 9.1 (2011) ein Framework, um Fremdsysteme anzubinden. Diese sogenannten Foreign Data Wrappers gibt es für zahlreiche Systeme:

Oracle, MS SQL Server, MariaDB/MySQL, Sybase, Informix, Firebird, SQLite
MongoDB, Cassandra, CouchDB, Neo4j, Redis
… und viele mehr [4]

Hat man PostgreSQL mit einem dieser Foreign Data Wrapper an ein Fremdsystem angedockt, können die Daten mittels standard SQL-Befehlen nach PostgreSQL übernommen werden. Inwieweit die Datentypen dabei kompatibel sind, hängt von der jeweiligen Implementation des Foreign Data Wrappers ab. Zumindest für Daten-Migrationen von den gängingen proprietären Produkten sollte das ohne größeren Aufwand möglich sein.

ora2pg

Für Migrationen von Oracle/MySQL nach PostgreSQL bietet sich ora2pg an [5]. Dies ist ein Open Source-Projekt, das sowohl die Daten an sich aber auch Applikations-Logik (PL/SQL) teilweise nach PostgreSQL migrieren kann. Implementiert ist das Ganze in Perl, es sollte also auf allen gängigen Betriebssystemen laufen. Als Vorbedingung muss allerdings ein funktionsfähiger Oracle Client vorhanden sein, entweder ein voller Client oder aber auch der Oracle Instant Client.

ora2pg zeigt die Migrations-Schritte und deren Resultate während eines Laufs an:

[========================>] 12/12 tables (100.0%) end of scanning.     
[========================>] 10/10 objects types (100.0%) end of objects auditing.          
Running: ora2pg -p -t TABLE -o table.sql -b ./schema/tables -c ./config/ora2pg.conf
[========================>] 12/12 tables (100.0%) end of scanning. 
[========================>] 12/12 tables (100.0%) end of table export.

Details der nicht erfolgreich mirgrierten Objekte finden sich in den Log-Dateien.

edbmtk

EnterpriseDB [6] bietet mit dem EDB Migration Toolkit (edbmtk) ein Werkzeug, das sowohl die Daten als auch Applikationslogik in der Datenbank (abhängig vom Hersteller der Quell-Datenbank) nach PostgreSQL migrieren kann. Allerdings braucht es hierfür eine Subscription da die EnterpriseDB-Werkzeuge nicht als Open Source-Produkte verfügbar sind. edbmtk ist in Java implementiert, es sollte also auch auf den meisten Windows- und Linux-Distributionen laufen. edbmtk kann Daten von folgenden Systemen migrieren:

Oracle
Sybase
MS SQL Server
MySQL/MariaDB

Am Ende eines Migrationslaufs steht immer eine Zusammenfassung der erfolgreich und nicht erfolgreich migrierten Objekte:

******************** Migration Summary ********************
Tables: 12 out of 12
Constraints: 14 out of 14
Indexes: 13 out of 13
Views: 1 out of 3
Procedures: 1 out of 1
Profiles: 0 out of 1
Total objects: 44
Successful count: 41
Failed count: 3
Invalid count: 0
...

Details der nicht erfolgreich migrierten Objekte finden sich in den Log-Dateien.

Migration der Geschäftslogik

Generell gilt: Je weniger herstellerspezifische Features eine Applikation verwendet, desto einfacher wird die Migration nach PostgreSQL. Ist Geschäftslogik in der Datenbank implementiert (Funktionen, Trigger, Packages), sollte genau geprüft werden, wie am besten migriert werden kann. Mehrere Möglichkeiten bieten sich hier an.

Neu-Implementation

Ist die Anzahl der Zeilen Programm-Code in der Datenbank gering, lohnt sich eventuell eine Neu-Implementation in einer Sprache, die in PostgreSQL in der Datenbank verwendet werden kann (pl/pgsql, pl/java, pl/python, pl/tcl, pl/perl, ...). Neu-Implementationen öffnen immer auch den Raum, Altlasten zu entfernen und zu optimieren. Eine Neu-Implementation ist allerdings auch meistens mit höheren Kosten verbunden.

Migration/Übersetzung der Geschäftslogik

Bei Migrationen von Oracle nach PostgreSQL können sowohl ora2pg als auch das edbmtk PL/SQL Code automatisch nach pl/pgsql übersetzen bzw. mit PL/SQL umgehen. Die Postgres Plus Enterprise Edition von EnterpriseDB bietet eine Oracle-Kompatibilitäts-Schicht, die ca. 80 Prozent des PL/SQL-Codes ohne Änderungen abdecken kann. Auch hier muss man aber wissen, dass dafür eine Subscription notwendig ist.

Für Migrationen von DB2 empfiehlt es sich, mittels db2topg [7] zu starten, um sich einen groben Überlick zu verschaffen, wo die Hürden liegen. Migrationen von anderen Systemen (MySQL/MariaDB, MS SQL Server, DB2, ...) erfordern eine Neu-Implementation der Geschäftslogik.

Einige Fallstricke bei Migrationen von Oracle

Am häufigsten werden wohl Oracle-Datenbanken nach PostgreSQL migriert. Hierbei gibt es einige Fallstricke, die man beachten sollte.

Implizite und explizite Datentyp-Konvertierungen

Oracle erledigt viele Datentyp-Konvertierungen im Hintergrund ohne, dass der Benutzer oder der DBA sich dessen bewusst sind, z. B.:

SQL> select to_char(to_date('24.06.2016','dd.mm.yyyy')) mydate 
     from dual;

Was hier stattfindet ist eine implizite Konvertierung eines Date-Datentyps in einen Character-Datentyp. PostgreSQL wird das nicht zulassen:

postgres=# select to_char(to_date('24.06.2016','dd.mm.yyyy'));
ERROR:  function to_char(date) does not exist
HINT:  No function matches the given name and argument types. You might need to add explicit type casts

PostgreSQL erwartet von den Applikationen oder vom Anwender, dass explizit spezifiziert wird, wohin denn konvertiert werden soll:

postgres=# select cast(to_date('24.06.2016','dd.mm.yyyy') as varchar);
  to_date   
------------
 2016-06-24

Ein weiteres Bespiel: In Oracle geht Folgendes problemlos:

SQL> create table t ( a number );
Table created.
SQL> insert into t values ( 20160624 );
1 row created.
SQL> select to_date(a,'yyyymmdd') mydate from t;
MYDATE
---------
24-JUN-16

Das Gleiche wird in PostgreSQL aus den gleichen Gründen wie oben nicht funktionieren:

postgres=# create table t ( a int );
CREATE TABLE
postgres=# insert into t values ( 20160624 );
INSERT 0 1
postgres=# select to_date(a,'yyyymmdd') from t;
ERROR:  function to_date(integer, unknown) does not exist at character 8
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

PL/SQL Packages

PostgreSQL hat mit PL/pgsql eine PL/SQL ziemlich ähnliche Sprache, die es erlaubt, Funktionen und Trigger in der Datenbank zu schreiben. Was PostgreSQL allerdings nicht kennt, ist das Konzept eines Packages, wie es PL/SQL bietet [8]. Möchte man seine Funtionen/Prozeduren in PostgreSQL logisch gruppieren, kann man das allerdings über Schemata erreichen. Dazu muss man wissen, dass PostgreSQL im Gegensatz zu Oracle nicht nur Benutzer und Rollen, sondern auch Schemata kennt. Das heißt, dass es immer ein Schema ist, das die Datenbankobjekte berherbergt. Ein Benutzer kann dann mehrere Schemata besitzen und seine Objekte darin verteilen bzw. gruppieren:

postgres=# create schema schema1;
CREATE SCHEMA
postgres=# create schema schema2;
CREATE SCHEMA
postgres=# CREATE FUNCTION schema1.add(integer, integer) RETURNS integer
    AS 'select $1 + $2;'
    LANGUAGE SQL;
CREATE FUNCTION
postgres=# CREATE FUNCTION schema2.add(integer, integer) RETURNS integer
    AS 'select $1 + $2;'
    LANGUAGE SQL;
CREATE FUNCTION

NULL und NOT NULL

Oracle implementiert NULL als einen leeren String, d. h. folgendes Statement gibt ein Resultat:

SQL> select 'AAA' || null NNNN from dual;
NNN
---
AAA

Führt man das gleiche Statement in PostgreSQL aus, gibt das kein Resultat:

postgres=# select 'AAA' || null NNNN;
 nnnn 
------
 
(1 row)

NULL-Behandlungen in der bestehenden Code-Basis müssen also genau analysiert werden.

Datentypen

Im Vergleich zu Oracle bietet PostgreSQL sehr viel mehr Datentypen für die unerschiedlichsten Anforderungen. Je nachdem, welchen Typ man wählt, hat das allerdings Konsequenzen bei der Geschwindigkeit:

postgres=# create table t1 ( a smallint, b numeric );
CREATE TABLE
postgres=# insert into t1 values ( generate_series ( 1,1000000)
                                 , generate_series ( 1,1000000) );
INSERT 0 1000000
postgres=# select sum(a) from t1;
     sum      
--------------
 500000500000
Time: 70.650 ms
postgres=# select sum(b) from t1;
     sum      
--------------
 500000500000
Time: 142.335 ms

Bei Oracle wählt man für numerische Werte den NUMBER-Datentyp, egal ob es sich hierbei um Werte mit Nachkommastellen handelt oder nicht. In PostgreSQL kann es gravierende Unterschiede machen, je nach dem ob man ganzzahlige Werte (INTEGER) speichern will oder Werte mit Nachkommastellen (NUMERIC).

PostgreSQL HA Architektur

Hat man es geschafft und erfolgreich nach PostgreSQL migriert, stellt sich sofort die Frage nach einer PostgreSQL-Architektur, die den Geschäftsanforderungen gerecht wird. Für unkritische Anwendungen kann das eine Single-Instanz sein, die im Falle eines Ausfalls an einem anderen Ort wiederhergestellt werden kann. Gehen die Anforderungen allerdings in Richtung Hochverfügbarkeit, müssen bei PostgreSQL wie auch bei allen anderen Systemen die Anforderungen klar formuliert werden.

Eine Architektur, die den meisten Hochverfügbarkeits-Anforderungen gerecht wird, ist sicherlich eine Konfiguration mit mehreren aktiven Standby-Datenbanken, die auch geographisch getrennt sind. PostgreSQL bietet mit der "hot standby"-Konfiguration hierfür genau das Richtige. Eine (oder mehrere) Standby-Datenbanken sind lesend geöffnet und können Abfragen in Echtzeit beantworten.

Eine solche Konfiguration kann mit dem Einsatz diverser Open Source-Produkte erreicht werden, s. Abb.1.

Abb.1: Konfiguration mit Open Source-Produkten. © Daniel Westermann

Im obigen Beispiel kommen nur Open Source-Produkte zum Einsatz:

Barman: Backup und Recovery
repmgr: Replication Manager
pgpool-II: Load balancer und Connection Pooler

pgpool-II übernimmt hierbei die Aufgabe, Lese-Operationen über alle Knoten zu verteilen und Schreibanfrangen immer auf den Master zu schicken. Dies erlaubt eine vertikale Skalierbarkeit der Lese-Operationen. Möchte man, z. B. aus regulatorischen Gründen, alles aus einer Hand, kann das Gleiche auch mit den Werkzeugen von EnterpriseDB erreicht werden (was allerdings wieder eine oder mehrere Subscriptions erfordert):

Abb.2: Alles aus einer Hand mit Werkzeugen von EnterpriseDB. © Daniel Westermann

Folgende EDB-Werkzeuge kommen hierbei zum Einsatz:

EDB Bart: Backup und Recovery
EDB EFM: Failover Manager (kann auch mit pgpool-II kombiniert werden)
EDB PEM: Postgres Enterprise Manager

Wer seine Infrastruktur sicher für die Zukunft machen will, kommt an Open Source-Produkten nicht mehr vorbei.

Der EDB EFM (Failober Manager) kann wahlweise dafür sorgen, dass eine VIP (virtuelle IP-Adresse) bei einem Ausfall des Master-Knotens automatisch auf eine verfügbare Standby-Datenbank migriert wird. Das hat den Vorteil, dass keine Konfigurations-Anpassungen der Applikation notwendig sind: Die Verbindungsparameter bleiben immer die Gleichen.

Fazit

Migrationen nach PostgreSQL werden in der heutigen Zeit immer interessanter. Das hat allerdings nicht nur damit zu tun, dass man Kosten sparen will, sondern auch damit, dass PostgreSQL extrem flexibel und performant ist. Die PostgreSQL-Community gibt in der Regel jedes Jahr ein Major Release frei, das für fünf Jahre unterstützt wird. Auch große Applikationshersteller nehmen PostgreSQL mehr und mehr in ihr Portfolio der unterstützten Datenbanken auf.

Wer seine Infrastruktur sicher für die Zukunft machen will, kommt an Open Source-Produkten schon heute nicht mehr vorbei. Das hat vor 20 Jahren mit Linux angefangen und setzt sich heute mit Docker, OpenStack und eben auch PostgreSQL fort. Treiber für Innovationen sind nicht mehr die alten Dinosaurier, sondern es sind die Communities.

Nicht jede Applikation lässt sich nach PostgreSQL migrieren, aber wenn es eine Chance dafür gibt, sollte man sie ergreifen. Man verringert nicht nur die Abhängigkeit von einzelnen Herstellern, sondern öffnet sich auch gegenüber anderen Open Source-Produkten, die sich nahtlos in die bestehende Landschaft integrieren. Wie bei allen Migrationen müssen jedoch die verschiedenen Möglichkeiten sorgfältig gegeneinander abgewogen werden. Hat man jedoch die erste Applikation migriert, werden weitere bestimmt folgen und zwar mit immer weniger Aufwand.

Quellen