Welchem Datenbankmodell gehört die Zukunft?

Auf der NoSQL-Konferenz 2009 wurde eine neue Kategorie von hochspezialisierten Datenbanken vorgestellt. Dieses neue Modell bedeutete eine Abkehr von der Herrschaft der relationalen Datenbanken, die den Markt jahrzehntelang unangefochten dominiert hatten und trotz ihrer mangelnden Spezialisierungsmöglichkeiten als Status quo akzeptiert wurden.

In den darauffolgenden Jahren wurden viele neue Datenbankmodelle eingeführt, um alle erdenklichen Anforderungen und Datentypen abzudecken. Doch wie so oft scheint die Entwicklung einem zyklischen Muster zu folgen: Allzweckplattformen gewinnen wieder an Popularität.

In einer zunehmend digitalisierten Welt ist es eine Binsenweisheit, dass der Erfolg von Unternehmen in hohem Maße von der Geschwindigkeit abhängt, mit der sie innovative Anwendungen entwickeln und ihren Kunden anbieten können. Die Erwartungen ändern sich ständig. Apps, die wir im Alltag häufig nutzen, wie Netflix oder Instagram, setzen die Standards für Reaktionsfähigkeit, Optimierung für mobile Geräte, Aufbereitung gewünschter Inhalte und Informationen, Sicherheit sowie Aktualisierungen und Einblicke in Echtzeit. Ein Teil dessen, was moderne Apps und ihre Anbieter ausmacht, spielt sich jedoch hinter den Kulissen ab. Unternehmen müssen die sich weiterentwickelnden Erwartungen und Anforderungen der Nutzer ihrer Apps verstehen. Dazu müssen sie in der Lage sein, ihren Daten Fragen zu stellen und Antworten zu erhalten – Fragen, an die man früher vielleicht nie gedacht hat und die in der Struktur dieser Daten auch nicht unbedingt vorgesehen sind.

Datenplattformen müssen diesen ständig wachsenden Anforderungen auf produktive, schnelle und flexible Weise gerecht werden. Relationale Datenbanken, die fast vier Jahrzehnte lang die Grundlage für datengesteuerte Anwendungen bildeten, bringen oft nicht die gewünschte Agilität mit. Sie stammen aus einer Zeit, als Anwendungen auf eine überschaubare und feste Anzahl von Attributen wie Vornamen, Nachnamen und Postleitzahlen zugriffen. Die heute gesammelten Daten sind viel unstrukturierter und lassen sich nur schwer in einer starren Struktur aus Zeilen und Spalten speichern, analysieren oder abfragen. Die Grenzen des relationalen Modells wurden in den Nullerjahren immer deutlicher: Seine Fähigkeit, Ad-hoc-Änderungen in der Struktur der zu speichernden Daten oder in den Mustern, wie sie abgefragt werden können, zu verarbeiten, blieb begrenzt. Viele Architekturen – wie z. B. die der großen Online-Händler – mit ihrem enormen Umfang, ihren anspruchsvollen Kundenerwartungen und ihrer obsessiven Back-End-Datenanalyse, erforderten einen anderen Ansatz. 

NoSQL 2009: Von der Monokultur zur Datenbankvielfalt

Die Veranstaltung NoSQL 2009 läutete den Wandel ein. Während relationale Datenbanken den Markt bis dahin unangefochten dominiert hatten, entstanden nun zahlreiche neue Datenbanken. Diese spezialisierten Lösungen, die zunächst nur für bestimmte Anwendungsfälle geeignet waren, schufen völlig neue Geschäftsmodelle. Relationale Datenbanken blieben eine wichtige Kategorie, konkurrierten aber nun mit Dokumentendatenbanken, Graphdatenbanken, kolumnaren Datenbanken, In-Memory-Datenbanken, Key-Value-Stores, Streaming-Plattformen oder Suchmaschinen, die je nach Anforderung ausgewählt wurden. 

Dokumentendatenbanken sind heute die beliebteste und am weitesten verbreitete Alternative, was zum großen Teil an ihrer Flexibilität liegt, die die Darstellung vieler Datenstrukturen ermöglicht. Anstelle der starren Zeilen- und Spaltenstruktur des relationalen Modells bilden Dokumentendatenbanken ihre interne Darstellung direkter auf Objekte im Code ab, wodurch die bei relationalen Datenbanken erforderliche zusätzliche Abbildungsebene entfällt. Der Vorteil dieser Ähnlichkeit ist, dass sie, da sie auf JSON-ähnlichen Dokumenten basieren, für Entwickler äußerst intuitiv zu verwenden sind. JSON ist ein sprachunabhängiges und von Menschen lesbares Format, das sich zu einem weit verbreiteten Standard für die Speicherung und den Austausch von Daten entwickelt hat, insbesondere für Webanwendungen. 

Ein wesentlicher Vorteil von Dokumentendatenbanken besteht darin, dass die Struktur der Daten, das so genannte Schema, in der Datenbank nicht vordefiniert werden muss und dass dieses Schema jederzeit geändert werden kann. Änderungen am Schema können aus einer Vielzahl von Gründen erfolgen: Quelldaten, die in einem anderen Format geliefert werden, neue erweiterte Daten, die erfasst oder neue Abfragen, die unterstützt werden sollen. Die Schemaverwaltung ist ein wesentlicher Bestandteil der Arbeit mit relationalen Datenbanken, bei denen die Struktur der Daten im Voraus abgebildet werden muss, um Abfragen über die Beziehung zwischen verschiedenen Elementen zu unterstützen. Die Fähigkeit, diese Änderungen ohne umfangreiche Überarbeitung des Datenbank- und Anwendungscodes unterstützen zu können erhöht die Flexibilität von Entwicklern, die mit Dokumentendatenbanken arbeiten, erheblich.

Es funktioniert in der Praxis, nicht nur in der Theorie 

Das haben auch die Entwickler von Travelers Insurance, einem seit fast 170 Jahren führenden Anbieter von gewerblichen Sach- und Unfallversicherungen in den USA, erkannt. Die gestiegene Zahl der Anwendungsfälle und die höheren Anforderungen an die Daten machten einen Wandel notwendig. Den Anstoß für den Paradigmenwechsel gab schließlich ein konkretes Projekt: Für die angeschlossenen Makler sollte eine Single-View-Anwendung entwickelt werden, damit sie sich nicht mehr für einen einzigen Anwendungsfall bei einem Dutzend verschiedener Dienste anmelden müssen. Ursprünglich auf Basis eines relationalen Datenbankmodells konzipiert, erwies sich das Projekt als zu komplex und letztlich nicht realisierbar. 

Travelers entschied sich für die Dokumentendatenbank von MongoDB. Der Wechsel auf ein Dokumentenmodell nach jahrzehntelanger ausschließlicher Verwendung des relationalen Modells war eine große Umstellung, und die Teams mussten lernen, wie man Datenmodelle in JSON erstellt. Die Verringerung des Arbeitsaufwands für die Entwickler war jedoch größer als der anfängliche Aufwand. Die Entwicklungsteams konnten beim ersten Projekt mehr als 600 Codezeilen einsparen und den Zeit- und Kostenrahmen einhalten, was bei früheren Projekten nicht der Fall gewesen war. Durch den Wegfall von Datenmapping und -modellierung konnten die Entwickler von Travelers auch die Zeit zwischen Anforderung und Bereitstellung von Software oder Funktionserweiterungen erheblich verkürzen, was die Agilität des Unternehmens und seine allgemeine Fähigkeit, auf veränderte Marktbedingungen zu reagieren oder Chancen zu nutzen, erhöhte. 

Toyota Material Handling Europe profitierte ebenfalls von der Umstellung auf eine Dokumentendatenbank, die es dem Unternehmen ermöglichte, von einer monolithischen Codebasis zu einer auf Microservices basierenden Architektur überzugehen. Der historische Wandel der Branche hin zu intelligenteren und autonomeren Fabriken und Flotten, deren IoT-Sensoren enorme Datenmengen erzeugen, machte auch hier ein Umdenken erforderlich. „Alles ist ein natürliches JSON-Dokument“, sagt Filip Dadgar, ehemaliger Principal Solutions Architect und IT Manager bei Toyota Material Handling Europe. 

Gehört die Zukunft also der Dokumentendatenbank?

Hat die Dokumentendatenbank also das Potenzial, die relationale Datenbank als marktführendes Modell abzulösen? Oder gehört die Zukunft einer Vielzahl von spezialisierten Modellen, die je nach Einsatzzweck und Anforderungen ausgewählt werden? Lange Zeit sah es so aus, aber wie bei so vielen Dingen scheint sich auch hier der Kreis zu schließen. Viele Unternehmen wünschen sich wieder allgemeinere Lösungen, die sich für eine Vielzahl von Anwendungsfällen in der gesamten Organisation eignen. 

Dafür gibt es mehrere Gründe: 

• Die Nutzer spezialisierter Datenbanken drängen auf Funktionserweiterungen, damit sie nicht zwischen verschiedenen Datenspeichern wechseln müssen, weil sie bestehende Datensätze über organisatorische und technologische Grenzen hinweg konsolidieren wollen. 

• Auch die Entwickler wollen mehr Integration. Zwar möchte niemand zu der Zeit zurückkehren, als die relationale Struktur die einzige Option war, doch wird der Aufwand für die Integration mehrerer verschiedener spezialisierter Datenbanken, die jeweils spezifischen Anwendungen zugrunde liegen, selbst immer komplexer und damit zeit- und arbeitsintensiver. Bei spezialisierten Datenbanken besteht daher die Gefahr, dass ihr Integrationsaufwand so hoch wird, dass er die Vorteile ihrer besonderen Fähigkeiten in einem bestimmten Bereich zunichtemacht.

Trend zu einer universellen Plattform 

Schon heute zeigt sich, dass die Datenbanken weniger hoch spezialisiert sind als zu Beginn des NoSQL-Konzepts auf dem Markt. MongoDB bietet jetzt Data Lake- und Zeitreihenfunktionen, Diagramme und andere Analysefunktionen. Auch andere Anbieter erweitern ihre Lösungen um neue Funktionen, was einen klaren Trend hin zu einer allgemeineren Lösung verdeutlicht.

Einer der Gründe für diese Konsolidierung sind die Betriebskosten, die durch die Pflege mehrerer spezialisierter Datenspeicher entstehen, und zwar nicht nur in Bezug auf die Pflege der verschiedenen Plattformen, sondern auch in Bezug auf die Entstehung von Betriebssilos: Daten, die in einem bestimmten Format in einem System gespeichert sind, müssen umgewandelt werden, damit sie mit anderen Systemen und den Teams, die sie nutzen, gemeinsam genutzt werden können.

Generalistische Plattformen reduzieren den Aufwand für die Einhaltung von Sicherheitsstandards

Hinzu kommt die Vervielfachung der Compliance- und Sicherheitsanforderungen, die mit der Zunahme der Plattformen einhergeht. Jeder Datenspeicher muss separat abgesichert werden. Seine Konfiguration muss auf die Einhaltung interner und externer Vorschriften hin überprüft werden. Im Gegensatz dazu bietet eine generalistische Anwendungsdatenplattform den Sicherheits- und Compliance-Teams einen einzigen Kontrollpunkt für die Sicherung und Einhaltung der Vorschriften, zusätzlich zu der betrieblichen Vereinfachung, die sich daraus ergibt, dass sich alles an einem Ort befindet.

Die Anbieter von Allzweckplattformen erweitern ihren Anwendungsbereich, indem sie ihre Plattformen um spezialisierte Funktionen ergänzen, so dass in vielen Fällen die Notwendigkeit entfällt, diese eigenständigen Spezialwerkzeuge zu pflegen. Moderne Anwendungsdatenplattformen können Textsuche, Zeitreihendatenverarbeitung und Analysen direkt in der Kernplattform unterstützen, ohne dass spezielle Systeme integriert und der Datenaustausch mit ihnen eingerichtet werden muss. Während sich die Datenbankanbieter in den zehn Jahren nach NoSQL im Jahr 2009 zunehmend von Allzweck-Workloads entfernten, zeichnet sich hier eine klare Trendwende ab. 

Ausblick

Die Zukunft wird wahrscheinlich denjenigen Anbietern gehören, denen es gelingt, Datenbanklösungen anzubieten, die das Beste aus beiden Welten vereinen und für ein breites Spektrum von Anwendungen und Aufgaben eingesetzt werden können, aber auch die Möglichkeit bieten, bei Bedarf auf spezielle Funktionen zurückzugreifen.

Die Veränderungen auf dem Datenbankmarkt werden von den Entwicklern vorangetrieben, deren Anforderungen wiederum durch die immer schneller und umfangreicher werdenden Anforderungen von Geschäftsinteressenten und Endnutzern beeinflusst werden. Anwendungen müssen in der Lage sein, sich schnell weiterzuentwickeln, um Änderungen in ihrem Anwendungsfall zu berücksichtigen, und zwar nach einem Zeitplan, der flexibel ist und externen Ereignissen Rechnung trägt. Gewinner werden diejenigen Datenplattformen sein, die Entwicklern die Bereitstellung neuer Funktionen ermöglichen, die die Endnutzer nachfragen, um Erkenntnisse aus ihren Daten zu gewinnen. Definitionsgemäß erfordert dieses Ziel eine einheitliche Sicht auf die Daten und eine Vielzahl von Tools, mit denen sie analysiert werden können. Das ist es, was moderne Anwendungsdatenplattformen bieten.