Warum wählen, wenn man beides haben kann? Hybride Datenbanken vereinen SQL und NoSQL

Von Gregor Bauer *

Warum soll man sich eigentlich zwischen SQL und NoSQL entscheiden müssen, wenn man beides haben kann? Eine hybride Datenbank erspart die Qual der Wahl, denn sie verbindet die Vorteile von SQL- und NoSQL-Datenbanken.

Anbieter zum Thema

Eine strikte Trennung zwischen relationaler und unstrukturierter Datenhaltung ist heute nicht mehr zwingend notwendig.
Eine strikte Trennung zwischen relationaler und unstrukturierter Datenhaltung ist heute nicht mehr zwingend notwendig.
(© monsitj - stock.adobe.com)

Im Pro und Contra um das richtige Datenbankmanagement-System (DBMS) haben sowohl SQL-, als auch NoSQL-Datenbanken glühende Verfechter und skeptische Ablehner. Unter ganz pragmatischen Gesichtspunkten erscheint es jedoch sinnvoller, die jeweiligen Vor- und Nachteile im Kontext der geplanten Einsatzszenarien kühl und sachlich gegeneinander abzuwägen.

Für das relationale Datenbankmodell (RDBMS) von SQL sprechen die lange Tradition, die enorme Verbreitung und das entsprechend breit gestreute Expertenwissen bei Entwicklern und Administratoren. Die wichtigsten Argumente pro NoSQL sind die horizontale Skalierbarkeit und die niedrigen Latenzzeiten durch die verteilte Architektur, die Eignung für unstrukturierte Daten durch das flexible Datenmodell mit JSON-Dokumenten (JavaScript Object Notation), sowie die Fähigkeit zur Cross-Datacenter-Replikation für die uni- und bidirektionale Replikation über mehrere Rechenzentren.

Was liegt also näher, als die Wahl zwischen beiden überflüssig zu machen, SQL und NoSQL in einem einzigen DBMS verfügbar zu machen und dabei von den Stärken beider Formate zu profitieren?

NoSQL als Basis moderner Datenbankarchitekturen

Voraussetzung dafür ist das NoSQL-Datenbankmodell als Basisarchitektur. SQL-Datenbanken sind aufgrund der starren Tabellen-Schemata und deren Relationen für typische moderne Anwendungen, wie etwa auf hochfrequenten E-Commerce-, Kommunikations- oder Streaming-Plattformen, nicht geeignet.

Diese Begrenzungen werden durch die Charakteristika von NoSQL-Datenbanken aufgehoben. Zudem sind relationale Datenbanken nur mit hohem Aufwand in virtualisierte und containerisierte IT-Architekturen einbindbar. Wer sich aus guten Gründen für diese moderne Form der Basisinfrastruktur entscheidet, der hat seine Entscheidung für NoSQL de facto gleich mit getroffen.

In der Praxis bedeutet das die Notwendigkeit zur Migration von bestehenden SQL-Systemen auf NoSQL-Datenbankplattformen. Dabei stellt sich gleich zu Anfang die spannende Frage: Teil- oder Komplettumstieg? Der komplette Wechsel ist in der Regel aus einem Problem-Mix aus Zeit-, Budget- oder Personalgründen kaum realistisch.

Die Datenbank-Migration erfolgt daher meist nur partiell und konzentriert sich auf die beschriebenen Einsatzszenarien, für die NoSQL dringend gebraucht wird. Alle anderen kommen eventuell später. In bestimmten Teilen der IT-Landschaft werden in diesem Fall also auch weiterhin auf Sicht die SQL-basierenden Altsysteme gefahren.

Dafür spricht auch die Tatsache, dass viele Legacy-Systeme nur mit überproportionalem Aufwand auf moderne IT-Architekturen umgestellt werden können, sofern dafür überhaupt noch eine brauchbare Dokumentation vorhanden ist. SQL wird als die mit Abstand verbreitetste Abfragesprache also auch nach der Einführung einer NoSQL-Datenbank aus einer ganzen Reihe von Gründen gebraucht.

SQL als Migrationserleichterungswerkzeug

Sinnvoll ist daher ein sanfter Übergang, bei dem die vorhandene SQL-Expertise der IT-Mitarbeiter – und gegebenenfalls der vertrauten IT-Dienstleister – für die Migration genutzt wird. Das setzt voraus, dass die NoSQL-Datenbank in der Lage ist, SQL-kompatible Statements abzusetzen. Aber selbst für den Fall eines Komplettumstiegs auf NoSQL ist eine hybride Datenbank sinnvoll, beispielsweise im Kontext von Data Analytics.

Big Data ist auf SQL aufgebaut, fast alle Analytics Tools sind SQL-kompatibel. Sowohl die Einbindung eines Data Warehouses über ETL-Tools als auch die anschließend Zugriffe des Data Warehouse auf die Datenbank erfolgt also über SQL-Statements. Das kann zwar umgangen werden, beispielsweise über Tool-interne Datenbanken, das erhöht aber Aufwand und Komplexität und stellt damit eine ständige Fehlerquelle dar.

Während Data Warehouses lediglich historische Daten zur Verfügung stellen, gewinnt die Einbindung von Echtzeitdaten gerade in den beschriebenen Einsatzszenarien ständig an Bedeutung. Realtime Analytics kann sehr viel einfacher genutzt werden, wenn für die entsprechenden Datenbank-Konnektoren ein SQL-Interface zur Verfügung steht.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Big Data, Analytics & AI

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Gregor Bauer
Gregor Bauer
(Bild: Couchbase)

Aktuell ist die Nutzung von SQL als vielfach benötigte Abfragesprache sinnvoll nur mit einer einzigen NoSQL-Datenbankplattform möglich, die mit N1QL (SQL for JSON) eine eigene Abfragesprache dafür geschaffen hat. Das hat außerdem den positiven Effekt, dass die Umstellung auf den neuen Datenbank-Typ NoSQL für Administratoren, Entwickler und gegebenenfalls externe Dienstleister einfacher ist, und für das Unternehmen schneller und reibungsloser operativ wirksam wird. Sowohl der Umstieg auf NoSQL, als auch der laufende IT-Betrieb danach wird dadurch unter Effizienz- und Kostenaspekten optimiert.

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

(ID:47854855)