Im Blog-Artikel „Gesucht: Eine Datenbank für alle Fälle“ habe ich mich mit unterschiedlichen Ansätzen für das Datenmanagement bei der Anwendungsentwicklung beschäftigt. Dabei wurde deutlich, dass sich die verschiedenen Datenbankmanagement-Technologien für jeweils andere Einsatzszenarien anbieten.
Relationale Datenbanken sind tabellenbasiert und nutzen die Datenbanksprache Structured Query Language (SQL), um Daten abzurufen und zu verarbeiten. Sie eignen sich hervorragend für transaktionale Anwendungen, die Zuverlässigkeit und ACID-Garantien (Atomicity, Consistency, Isolation und Durability) erfordern und für Abfragen und die Berichterstellung auf die Effizienz und Einfachheit von SQL setzen. Für den reibungslosen Produktivbetrieb einer Anwendung auf Basis relationaler Datenbanken ist es jedoch erfahrungsgemäß notwendig, auf die Expertise von Datenbank-Administratoren (DBA) zurückzugreifen. Zudem ist das Leistungsvermögen relationaler Datenbanken durch vordefinierte relationale Strukturen eingeschränkt und sie sind bei steigenden Datenmengen und Workloads kaum wirtschaftlich skalierbar.
Nicht-relationale Datenbanken wie Key-Value- oder Document-Datenbanken hingegen sind sehr flexibel und können unproblematisch und kostengünstig skaliert werden. Anwendungsentwickler können Daten weitaus einfacher speichern und verwalten als im Fall des relationalen Ansatzes, ohne sich über das Mapping auf fixe Datenstrukturen den Kopf zerbrechen zu müssen. Nur in seltenen Ausnahmefällen wird eine solche „Spezial“-Datenbank jedoch alleinige Basis einer komplexen Business-Anwendung sein können. Stattdessen gilt es für den Anwendungsentwickler, verschiedene nicht-relationale Datenbanken in die Applikation einzubinden (Polyglot Persistence), was naturgemäß erheblichen Integrationsaufwand nach sich zieht, die Weiterentwicklung erschwert und die Zusammenarbeit mit mehreren Anbietern erfordert.
Diese Probleme umgehen Multi-Model Datenbanken, indem sie unterschiedliche Datentypen in einer einzigen Datenbank speichern und verarbeiten können. Doch sind nicht alle Multi-Model-DBMS gleich; Im Gegenteil, sie weisen zum Teil erhebliche Unterschiede hinsichtlich der technischen Umsetzung auf. So lösen einige Multi-Model-Lösungen die Aufgabe der Speicherung und Verarbeitung diverser Datentypen in einer einzigen Lösung dadurch, dass sie unterschiedliche Datenbank-Engines für unterschiedliche Datentypen unter einer gemeinsamen Oberfläche vereinen. Hier stehen Anwendungsentwickler vor der Schwierigkeit, dass die Daten oft redundant vorliegen und entsprechend orchestriert werden müssen. Andere Multi-Model-Datenbanken können zwar verschiedene Datenmodelle in der gleichen Engine verarbeiten, benötigen dafür aber immer noch speziell für das interessierende Modell vorbereitete Daten. Das bedeutet, dass ein einzelner Datensatz nicht gleichzeitig in unterschiedlichen Modellen genutzt werden kann.
Das Beste aus allen Welten vereint die InterSystems IRIS Data Platform.
Sie speichert eine einzige Repräsentation der Daten. Und sie nutzt eine einzige Datenbank-Engine, die es ermöglicht,
Daten sowohl relational als auch nicht-relational abzurufen und zu verarbeiten, ohne diese zu duplizieren. Für einen nicht-relationalen Zugriff wird kein vordefiniertes Schema benötigt. Das System bietet ACID-Transaktionen, lässt sich sowohl vertikal als auch horizontal skalieren und unterstützt lokale sowie Public- und Private-Cloud-Umgebungen und hybride (Public/Public, Public/Private, Cloud/lokal) Deployment-Umgebungen. Dieselben Daten können wahlweise mittels SQL oder als Dokumente, Objekte oder Key-Value-Daten abgerufen und manipuliert werden. Anwendungsentwickler müssen demzufolge nicht mit verschiedenen Datenbanken jonglieren oder Daten über mehrere Data Stores hinweg integrieren und synchronisieren.
Unser Multi-Model-Ansatz vereint damit die Vorteile relationaler und nicht-relationaler Technologien – und das ohne ihre Nachteile und die Komplexität oder Ineffizienz, die mit Polyglot Persistence einhergehen. All das ist in einem zentralen DBMS vereint, das wir von Grund auf aufgebaut haben.
