Die Migration relationaler Datenbanken In drei Schritten zu NoSQL- und Cloud-Databases

Anbieter zum Thema

Couchbase Germany GmbH

Vogel IT-Medien GmbH

Fujitsu Technology Solutions GmbH

Confluent Germany GmbH

Der Druck aus den Fachabteilungen zur Ablösung schwerfälliger relationaler Datenbanken durch flexiblere NoSQL- und Cloud-Datenbanken wächst. Ein einfaches Migrationsschema hilft beim Umstieg.

„Never change a running database”. Diese goldene Regel der Datenbank-Administration wird zunehmend obsolet. Neue Geschäftsmodelle fordern neue Anwendungen, und die brauchen agile, hochskalierbare und -verfügbare Datenbanken, die sich nahtlos in Cloud-Technologien mit Containern und Edge-Computing integrieren lassen.

Ein E-Commerce-Portal kann schwerlich mit einem rein relationalen Datenbank-Managementsystem (DBMS) betrieben werden. Der starre Tabellen-Aufbau der relationalen SQL-Datenbanken und die transaktionsorientierte Fixierung verhindern die dafür notwendige Flexibilität. Auch die zunehmende Nutzung von Microservices, mit denen SQL-Datenbanken unverträglich sind, spricht für die Nutzung moderner NoSQL-Datenbanken. Ganz zu schweigen von den vielen Automatisierungsfunktionen, die Installation und Betrieb vereinfachen.

Damit rückt für viele Unternehmen und deren IT-Abteilungen das ungeliebte Thema Migration auf die Tagesordnung. Sie haben dabei zwei Modernisierungsoptionen: NoSQL- und Cloud-Datenbanken. Wobei in Bezug auf Cloud-Datenbanken eine gewisse Begriffsverwirrung herrscht. Damit wird einerseits ein neuer Database-Typus bezeichnet, der typischerweise von Hyperscalern angeboten und gehostet wird. Anderseits bezeichnet er ein generelles Bereitstellungsmodell für Datenbanken, die in Form von Cloud-Services (DBaaS) genutzt werden.

Ähnlich wie NoSQL-Datenbanken verfügen auch Cloud-Datenbanken über Fähigkeiten zur horizontalen Skalierung und zur Unterstützung von Big Data und Microservices. Da sie in der Regel jedoch an einen bestimmten Anbieter gebunden sind, gehört Cloud-Agnostik grundsätzlich nicht zum Repertoire.

Der Einstieg in den Umstieg

NoSQL-Datenbanken dagegen können prinzipiell unabhängig in jeder beliebigen Private oder Public Cloud laufen und dort ihre Vorteile gegenüber herkömmlichen relationalen Datenbanken ausspielen. Voraussetzung dafür ist jedoch die Erfüllung des Automatisierungslevel 5 (Full Automation), wie er im Operator Framework als höchste Stufe definiert ist.

Zu den dort gelisteten Anforderungen zählt die Fähigkeit zur uni- und bidirektionalen Replikation über mehrere Rechenzentren beziehungsweise Regionen hinweg. Damit ist die Datenbank nicht nur Cloud-, sondern sogar Infrastruktur-agnostisch, und damit sowohl unabhängig von Cloud-Plattformen wie AWS, Google Cloud oder Microsoft Azure als auch von allen anderen Deployment-Modellen.

Die genannten Hyperscaler erleichtern die Migration von NoSQL-Datenbanken in ihre eigenen Clouds mit standardisierten Prozessen, eigenen Migrations-Tools und ausführlicher Dokumentation. Durch die bereits vorkonfigurierten Netzwerke und Firewalls einer Public Cloud entfallen zudem die häufig auftretenden Konflikte bei Private Clouds.

Unabhängig davon hat sich in der Umstiegsspraxis eine bestimmte Reihenfolge von Migrationsschritten in drei Schritten als zielführend erwiesen: Erstens die Migration der User, zweitens die Datenmigration und drittens die Migration der Indizes. Die Migration der User ist ein vorbereitender erster Schritt, bei dem die Zugangsberechtigungen und Berechtigungslevel der Nutzer für die neue Datenbank festgelegt werden. Damit ist sichergestellt, dass kein Unbefugter Zugriff auf Datenbankfunktionen und Datenbestände erhält.

In der Regel wird dabei differenziert in Administratoren (Admin), änderungsberechtigte Nutzer (Edit) und solche, die lediglich lesend darauf zugreifen dürfen (View). Die Übernahme der Berechtigungen in die neue Datenbank kann durch ein Script automatisiert werden.

Datentransfer: mal einfach, mal schwer

Der zweite, kritischste und meist aufwändigste Schritt ist die Migration des kompletten Datenbestands von der alten SQL- in die neue NoSQL-Database, bei der nichts schiefgehen darf. Datenbank-Verantwortliche haben dabei die Wahl zwischen zwei unterschiedlichen Methoden: der Offline- und der Online-Migration.

Meist wird dabei die Option zur Online-Migration genutzt. Besonders schnell und bequem ist dieser Prozess bei einer Datenbank mit der Fähigkeit zur Cross-Datacenter-Replication (XDCR) erledigt, denn der Datenbestand kann einfach asynchron in die neue Datenbank repliziert werden. Ein Vorgang, der auf Knopfdruck in wenigen Sekunden erledigt ist, und bei dem der Datenbestand in der alten Datenbank nach wie vor konsistent bleibt.

Bei der Offline-Data-Migration dagegen müssen die Daten manuell aus der alten Datenbank extrahiert, und dann – beispielsweise in Form eines CSV-Files – in die neue Datenbank geladen werden. In diesem Export/Import-Zeitraum, der schon einmal mehr als eine Stunde dauern kann, ist die Datenbank im Downtime-Modus, also nicht verfügbar. Eine angeschlossene Applikation, wie etwa ein Produktionssteuerungs-Programm, kann in dieser Zeit nicht genutzt werden, die Produktion steht still. Die Offline-Migration ist daher nur in wenigen Fällen sinnvoll, etwa dann, wenn interne Policies die bei der Online-Migration notwendige Öffnung der Firewalls für den Datenexport in die Cloud verbieten.

Mit dem Transfer des Datenbestands ist die wichtigste Migrationsstufe abgeschlossen. Abschließend werden dann die Indizes migriert. Das betrifft auch den Sonderfall der N1QL-Index-Migration. N1QL ist eine exklusive Query-Sprache, mit der JSON-Datensätze mittels SQL-Statements abgefragt werden können, und so das weit verbreitete SQL-Know-how weiterhin genutzt wird. Durch die Nutzung dieses Migrationsschemas verliert der Wechsel des Datenbank-Managementsystems seinen Schrecken. Insbesondere die Automatisierungsfunktionen und die Optionen zur Migration im laufenden Betrieb verkürzen und vereinfachen den Umstieg auf eine moderne NoSQL-Datenbank enorm.

* Der Autor Gregor Bauer ist Senior Solutions Engineer Central Europe bei Couchbase.

(ID:47957380)