Mach’s gut, und danke für den Kabeljau

Relationale, NoSQL- und NewSQL-Datenbanken

Peter Welkenbach und Guido Schmutz

Lange galten relationale Datenbanksysteme und strikte Normalisierung als die Standardtechnologie zur Speicherung von Daten. Wie passen dazu neuere Konzepte wie NoSQL und NewSQL? Ausgehend von einer Darstellung der Konzepte diskutieren wir mögliche Architekturszenarien.

Business Technology

Der Artikel „Mach’s gut, und danke für den Kabeljau“ von Peter Welkenbach und Guido Schmutz ist erstmalig erschienen im

Business Technology Magazin 2.2012

Seit den Arbeiten von Edward F. Codd in den Sechziger und Siebziger Jahren galten Relational Database Management Systems (RDBMS) und strikte Normalisierung als die Standardtechnologie zur Speicherung von Daten. Diese Stellung wurde auch durch Objektdatenbanken und objektrelationale Datenbanken nicht verändert. Die lange Vorherrschaft dieser Konzepte muss seine Gründe haben. Wie passen dazu Konzepte wie NoSQL und NewSQL? Wir postulieren für die nächsten Jahre Informationsarchitekturen, die heterogene, verteilte Speicherkonzepte und eine Koexistenz unterschiedlicher Datenbankkonzepte umfassen.

Datenbanken 2012

Die in Unternehmen und über Unternehmen hinweg produzierte und zur Auswertung gewünschte Datenflut steigt seit Jahren exponentiell. Handelte es sich früher um recht einfach strukturierte Datentypen, so hat man es in der modernen IT auch mit unstrukturierten, komplexen Strukturen zu tun. Die enormen multistrukturierten Datenmengen werden als Big Data bezeichnet. Gleichzeitig aber sollen die Daten in Echtzeit immer und überall verfügbar sein, was als Fast Data bezeichnet wird. Diese Kombination von Big Data und Fast Data führte dazu, dass klassische Datenbanksysteme (RDBMS) als nicht mehr ausreichend empfunden werden, und der derzeitige NoSQL-Hype bringt immer neue Produkte hervor.

NoSQL und NewSQL

Wie aus Abbildung 1 ersichtlich wird, kann man zusätzlich zu den klassischen, relationalen Datenbanken zwei neue Datenbanktypen differenzieren: NoSQL und NewSQL. Die anderen Typen sollen in dieser Diskussion unberücksichtigt bleiben. In der Diskussion bezüglich Big Data werden zurzeit aber vor allem die NoSQL-Datenbanken erwähnt. Sie lassen sich von ihren Ansätzen und ihren Konzepten her wie folgt unterteilen (Abb. 2):

  • Key-Value Stores (also im Grunde Hashtables)
  • Ordered Key-Value Stores (diese haben die Möglichkeit, die Keys zu ordnen)
  • BigTable
  • Document Full Text Search
  • Graph

Abb. 1: Datenbanken 2012 (ohne Gewähr auf Vollständigkeit)

Abb. 2: NoSQL-Speicherkonzepte (nach [1])

Unter den diversen Produkten sind auch solche, die nicht eindeutig dem einen oder anderen Typ zugeordnet werden können, sondern die bewusst mehrere Konzepte umsetzen.
Wir möchten hier nicht weiter auf Details eingehen, da das bereits in diversen Publikationen getan wurde. Es erscheint jedoch interessant, sich die Konzepte etwas genauer anzusehen und mit klassischem RDBMS zu vergleichen. NoSQL sind hochspezialisierte, auf bestimmte Fragestellungen hin optimierte Strukturen. Im Grunde sind diese Speicherstrukturen konzeptionell mit Index-Only Tables vergleichbar. Programmiert man mit NoSQL-Datenbanken, programmiert man auch den zur Abfrage notwendigen Index. Eine solche Sichtweise erlaubt unabhängig von Produkten und Hype eine konzeptionelle Betrachtung auf Architekturebene und führt letztendlich zu einem Datenhaltungsarchitektur-Blueprint, wie er am Ende des Artikels angesprochen wird.

Eine konzeptionelle Betrachtung erlaubt es uns auch, NoSQL-Konzepte mit klassischem RDBMS-Mitteln zu realisieren (oder speziellen Produktfunktionalitäten, Erweiterungen), sofern wir es nicht mit dem Datenvolumen der üblichen Web-2.0-Verdächtigen zu tun haben. Wenn wir also Produkte ausblenden und uns weiter Konzepte ansehen, so fällt auf einer sehr abstrakten Eben auf, dass der relationale Ansatz eher generisch („im streng normalisierten Modell lässt sich alles mit allem joinen“), der NoSQL-Ansatz hingegen eher applikationsspezifisch ist. Man kann folgende Unterscheidung treffen [1]:

  • Relational: antwortorientiert (Welche Antworten habe ich?), eher generisch
  • NoSQL: abfragenorientiert (Welche Fragen habe ich?) vergleichbar mit Datamart, eher applikationsspezifisch

Diese Betrachtungsweise erlaubt die Einordnung von NoSQL-Konzepten in eine Gesamtarchitektur. Sie zeigt, dass das relationale Modell (und RDBMS-Produkte) mitnichten vor dem Ende steht, sondern durch NoSQL ergänzt wird, so wie es auch durch multidimensionale Modelle für BI ergänzt wird. NoSQL-Konzepte können benutzt werden, um generische Unternehmensdaten spezifischen Applikationen aus Gründen der Performance und Skalierbarkeit in spezieller, abfrageoptimierter Form zur Verfügung zu stellen. NoSQL-Konzepte sind in einer Schichtenarchitektur anders einzuordnen, als klassische, normalisierte, relationale Modelle (Abb. 3).

Gerade hinsichtlich der Anforderung nach Skalierbarkeit wird immer wieder Kritik am relationalen Modell geübt. Dass diese nicht begründet ist, zeigen neue Produkte, die im Gegensatz zu den klassischen RDBMS-Produkten nicht Disk-orientiert sind, sondern als relationale In-Memory-Datenbanken arbeiten. Diese Produkte werden als NewSQL-Datenbanken bezeichnet, ein Begriff der von the451Group geprägt wurde [2].

Von der strengen NoSQL-Gemeinde gerne übersehen, stellen diese Produkte im gängigen Unternehmensumfeld und im Standardbetrieb, im Vergleich zu vielen mit nicht standardisierten Zugriffs-APIs ausgestatteten NoSQL-Produkten, eine interessante Möglichkeit dar, bestehende Anwendungslandschaften mit vertretbarem Aufwand für eine erhöhte Skalierbarkeit und erhöhten Durchsatz zu modernisieren. Da es sich um „normale“, relationale Datenbanken handelt, erfolgt auch der Zugriff aus Applikationen heraus mit den Standardtreibern und Konzepten. Das heißt, die Applikationen müssen nicht angepasst werden, der Zugriff wird nur auf eine andere Datenbank umgeleitet, die als eine Art relationaler Cache der ursprünglichen Backend-Datenbank vorgelagert ist. Demgegenüber muss bei Einführung von NoSQL-Produkten mit neuen Treibern und somit neuer Datenzugriffslogik in den Applikationen umgegangen werden. Da es bislang keinen Standard zum Zugriff auf NoSQL gibt, verlangt das einen nicht unerheblichen Aufwand auch in der Wartung. Kosten und Nutzen sollten wohl abgewogen werden. Derzeit auch wenig diskutiert wird die Frage, welchen Mehrwert ein reiner Key-Value Store gegenüber den ohnehin schon in den meisten Applikationen verwendeten Caches bringt. Interessant wird es erst dann, wenn das entsprechende NoSQL-Produkt sehr intelligent mit dem Typ des Value umgehen kann, zum Beispiel wenn es sich um den Inhalt von ganzen (eventuell sogar Media-)Dateien handelt.

Abb. 3: Datenhaltungsschichten
Geschrieben von
Peter Welkenbach und Guido Schmutz
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.