Welches Datenbankmodell soll es denn sein – SQL oder NoSQL? Eine Frage, die auch nach Jahren noch zu Diskussionen und Lagerbildung führt. Eine unnötige Debatte, denn in der modernen Datenverarbeitung haben beide Ansätze je nach Anwendungsfall ihre Berechtigung. Vielmehr kommt es auf das Wissen an, wann Unternehmen sich für welche Datenbank entscheiden sollten. Gregor Bauer, Manager Solutions Engineering CEUR bei Couchbase, in einem exklusiven Gastbeitrag. [...]
SQL-Datenbanken gelten seit den 1980er Jahren als Standard, gegen den der NoSQL-Ansatz eine Abkehr vom relationalen Datenmodell darstellt. Mit ihrem Auftreten haben NoSQL-Datenbanken eine dringend benötigte Antwort auf neue Herausforderungen geliefert, die durch moderne Technologien wie Container, Microservices und Edge Computing entstanden sind. Tatsächlich weisen relationale, transaktionsorientierte SQL-Datenbanken eine starre, schemabasierte Struktur und begrenzte Skalierbarkeit auf. So ist es auch kein Zufall, dass der NoSQL-Ansatz in einer Zeit immens an Popularität gewonnen hat, in der Produktionsprozesse mehr Flexibilität und Agilität von den Datenbanken gefordert haben.
Abgelöst hat NoSQL den SQL-Ansatz damit bei Weitem nicht. Denn auch wenn der Höhepunkt der SQL-Ära bereits in der Vergangenheit liegt, erfreut sich das Datenbankmodell weiterhin großer Beliebtheit und kommt überall dort zum Einsatz, wo neben Legacy-Systemen auch die Verlässlichkeit und Stabilität von Transaktionen im Mittelpunkt stehen. SQL-Datenbanken erfüllen außerdem die Kriterien des Data Reference Model (DRM), einem Rahmenwerk für die Struktur, Standards und Praktiken, um die Interoperabilität und gemeinsame Nutzung von Daten über verschiedene Systeme und Prozesse hinweg zu erleichtert. Nicht zuletzt ist SQL auch deshalb weiterhin relevant, weil die relativ geringen Einstiegshürden und die weit verbreitete Expertise den Ansatz immer noch attraktiv machen. Dem gegenüber steht mit NoSQL ein Datenbank-Konzept, das nicht an ein starres Tabellenschema gebunden ist und mit mehreren flexiblen Datenmodellen arbeitet ¬– etwa Multi-Modal, Key-Value oder dokumentenorientiert. Damit eignet sich NoSQL nicht nur für die Verarbeitung von großen Datenmengen und Durchsatzraten, auch semi- und unstrukturierte Daten wie Bilder oder Videos kann eine NoSQL-Datenbank speichern.
Auch wenn beide Ansätze ihre Daseinsberechtigung haben ist die Diskussion innerhalb der IT-Welt, welches Datenbankmodell denn nun das bessere ist, weiterhin aktuell. Ein Blick auf die Praxis zeigt allerdings, dass die Debatte mit dem richtigen Vorwissen und der langfristigen Planung der eigenen Projekte längst überflüssig geworden ist.
Unternehmen müssen ihre Hausaufgaben machen
Die Probleme beginnen mit den ersten Entscheidungen. SQL-Datenbanken sind schnell verfügbar, das Know-how ist meist inhouse vorhanden und viele Unternehmen setzen auf Altbekanntes – in diesem Falle auf relationale Datenbanken. Was sich kurzfristig für einen schnellen Start eignet, kann sich langfristig allerdings zu großen Herausforderungen entwickeln. Beispielsweise dann, wenn der jeweilige Anwendungsfall nicht bis zum Ende durchdacht ist, das Datenwachstum eine Skalierung der Lösung erfordert oder ein neuer Use Case Anpassungen notwendig macht. Hier erreicht die SQL-Datenbank schnell ihr Limit. Die Alternativen, die Unternehmen jetzt zur Verfügung stehen, sind kostspielig und zeitintensiv. Eine Migration von einem relationalem zu einem JSON-Modell ist nicht per Eins-zu-Eins-Umsetzung realisierbar, notwendig sind Analysen, eine Neumodellierung der Queries und des Datenmodells, Codeanpassungen sowie die Datenmigration in das neue System. Kurz gesagt, alles, was Unternehmen im Sinne der Effizienz, Produktivität und des Budgets verhindern wollen.
Bequemlichkeit und eine „Wir machen das schon immer so“-Einstellung sollten daher niemals ausschlaggebende Argumente bei der Entscheidung für ein grundlegendes Datenbankmodell sein. Vielmehr muss die Frage nach dem individuellem Anwendungsfall im Mittelpunkt stehen. Ist dieser fest definiert und soll sich auch in Zukunft nicht ändern, ist SQL weiterhin ein bewährtes Mittel der Wahl, das Stabilität und Verlässlichkeit liefert. Aber auch nur dann. Eine dogmatische Diskussion über die Vor- und Nachteile ist daher auch eine Scheindiskussion, weil NoSQL-Datenbanken mit ihrem nicht-relationalem Multi-Purpose-Ansatz für die Arbeit mit neuen Technologien ausgelegt sind. So können sie etwa Vektoren verarbeiten, die die Grundlage für den Einsatz von KI-Modellen bilden. NoSQL-Datenbanken sind zudem prädestiniert für den Einsatz in dynamischen Microservices-Architekturen. Da Microservices stark auf Automatisierung setzen, ist es wichtig, dass die benötigten Datenbankdienste ebenfalls automatisiert sind. Das bedeutet, dass sie leicht skaliert, bereitgestellt, bei Problemen wiederhergestellt oder dupliziert werden können. Traditionelle SQL-Datenbanken können all das nicht leisten und kommen in den genannten Bereichen gar nicht erst in Frage.
Für Unternehmen besteht der erste Schritt also darin, den individuellen Anwendungsfall zu erörtern, zukünftige Entwicklungen miteinzubeziehen sowie benötigte Datenmodelle und Skalierungsfunktionen zu berücksichtigen. Handelt es sich um ein wachsendes System, das so viel Flexibilität wie möglich benötigt? Könnten Technologien KI, ML oder der Analytics-Bereich noch wichtig werden? Erst auf Grundlage dieser Erkenntnisse kann eine Entscheidung für SQL oder NoSQL wirklich Sinn ergeben. Mit Blick auf moderne Datenbankmanagement-System wird sich zudem zeigen, ob eine strikte Trennung der beiden Modelle in Zukunft überhaupt noch ein Thema sein wird.
Die Grenzen verschwimmen
Die aktuelle Entwicklung zeigt einen Trend weg von starren Datenbanksystemen hin zu Plattformen, die auch verschiedene Modelle unter einem Dach bündeln und Unternehmen somit mehr Flexibilität bieten. Hinzu kommen attraktive Angebote im Bereich DBaaS (Database as a Service), also von Anbietern verwalteten Cloud-Datenbanken, bei denen sich Anwender nicht um Hardware, Backups, Wartung oder Skalierung kümmern müssen. Sie sind sofort verfügbar und bieten oftmals erhebliche Kostenvorteile. Trotz dieser Angebote scheuen viele Unternehmen nicht selten die Abkehr von rein relationalen Datenbanken und versuchen, ein vermeintliches Risiko zu umgehen, indem sie auf Altbewährtes setzen.
Dabei nähern sich SQL- und NoSQL-Datenbanken auch selbst bereits an – nicht zuletzt, weil die jeweiligen Nachteile wohl bekannt sind. So sind beispielsweise Plug-ins verfügbar, die es einer relationalen Datenbank erlaubt, JSON-Dokumente aus der NoSQL-Welt zu verwenden. Dennoch bieten nur NoSQL-Datenbanken eine wirklich Zukunftssicherheit für Unternehmen, die ihre Systeme flexibel und skalierbar halten wollen. Dafür lohnt auch ein geringer Mehraufwand zu Beginn. Die Diskussion über die richtige Technologie ist hingegen überflüssig, da sich der Einsatz strikt an die jeweiligen Ziele und Anwendungsfälle richten sollte.
*Gregor Bauer ist Manager Solutions Engineering CEUR bei Couchbase.
Be the first to comment