DATENBANKSYSTEME TEIL 3

- Falk Borgmann

Verteilte Systeme Zentrale Systeme NoSQL-Store Fachbeitrag Datenbanksysteme

Relational versus NoSQL

Neben dem Aspekt ihrer Verteilung, der im 2. Teil dieser Serie betrachtet wurde, ist ein weiteres wesentliches Unterscheidungsmerkmal von NoSQL-Datenbanken und relationalen Datenbanken, deren Datenmodell. In der relationalen Welt bewegt man sich immer in einer festen Tabellenstruktur, deren Dateninhalte mittels einer Abfragesprache (SQL = Structured Query Language) nutzbar sind. Leere Felder sind dabei nicht leer, sondern führen den Wert „Null“.

Eine SQL-Abfrage für die Beispieltabelle könnte also etwa so lauten: „Gib mir alle Datensätze der Tabelle, bei denen der Vorname = Max und der Nachname = Mustermann ist.“ Das Ergebnis wäre:„Max;Mustermann;35;m;Musterhausen“. Um die extrahierten Daten bewerten oder weiter verarbeiten zu können, muss man nur noch die fachliche Bedeutung der einzelnen Werte kennen. Wichtig ist, dass in der relationalen Welt versucht wird, Datenredundanzen nach Möglichkeit zu vermeiden. Im Idealfall werden Informationen also nur einmal in einer Tabelle abgelegt. Beziehungen zwischen Daten in verschiedenen Tabellen werden dann durch Tabellenbeziehungen hergestellt. Dieses Vorgehen wird auch als „Normalisierung“ bezeichnet.

NoSQL-Datenbanken (Not Only SQL) verwalten ihre Daten hingegen anders. Die bekanntesten Konzepte sind:

  • Key-Value (Schlüsselwert)
  • Column-oriented (spaltenbasiert)
  • Document-oriented (dokumentenorientiert)
  • Graph

Key-Value und Document-oriented

Von den vier erwähnten Technologien kommen sich die Konzepte der Key-Value- und Document-oriented-Datenbanken am nächsten. Beide arbeiten mit einem Schlüssel (Key), um zugehörige Daten (Values) zu identifizieren. Der Unterschied beider Ansätze liegt im Wesentlichen darin, wie diese Key-Value-Paare technisch verwaltet werden.

Bei Document-oriented-Technologien liegen die Daten in einem so genannten Document. Den Schlüssel (Key) kann man sich stark vereinfacht als Wegweiser zu einer Kiste mit Informationen vorstellen (ebend dem Document). Hat man den Wegweiser und folgt ihm, kommt man schnell zu besagter Daten-Kiste. Der bekannteste Vertreter dieser Gattung ist MongoDB, deren Daten als json-Format zugreifbar gemacht werden. Es gibt also keine Tabellenstruktur im relationalen Sinne, die einfach mit SQL abgefragt werden könnte. Eine Struktur entsteht ausschließlich über den Key, und so führt der Abfrageweg im Idealfall immer vom Schlüssel zum Datensatz. Am besten ist es, wenn man nie gezwungen wird, einen Datensatz inhaltlich zu durchsuchen, um eine bestimmte Information zu finden. In unserem Beispiel wäre das eine Suche nach z. B. Max Mustermann, ohne zu wissen, dass er sich hinter dem Schlüssel „00001“ verbirgt. Das würde nämlich bedeuten, auf gut Glück sämtliche „Kisten“ zu öffnen und ihren Inhalt zu durchsuchen. Bei vielen Millionen Daten-Kisten kann so etwas sogar mit einem leistungsfähigen Computer sehr lange dauern. Es gibt für dieses Problem auch bei Key Value Datenbanken die Möglichkeit, einen Index – also einen zusätzlichen Verweis auf eine bestimmte Information – anzulegen, nur ist es wie bei allen anderen Datenbanken auch hier nicht sinnvoll, ein System mit all seinen Daten permanent und vollständig zu indizieren, da das zu Lasten von Performance, Rechenleistung und Speicher geht.

Im Unterschied zur relationalen Tabelle können sich die Werte eines zugeordneten Schlüssels strukturell unterscheiden, was in der relationalen Welt nicht möglich ist, da die Daten-/Tabellenstruktur im relationalen System immer gleich ist und Lücken mit dem Null-Wert gefüllt werden. Dieser Aspekt scheint auf den ersten Blick nicht sonderlich spannend zu sein, kann aber bei großen Datenmengen relevant für die darunterliegende Infrastruktur (Kosten und Performance) werden.

Ein Vorteil von Key-Value-Stores ist es, dass sie sich in der Regel gut dazu eignen, für einen PoC mit geringem Aufwand hinter eine Anwendung installiert zu werden. Dadurch, dass Entwickler z. B. die Struktur eines MongoDB-.json selbst nach Bedarf bestimmen können, besticht diese Form der Datenverwaltung mit sehr großer Flexibilität bei der Entwicklung und Herstellung von Lösungen. Der Nachteil zeigt sich – wie bei einer Droge – meistens erst später, wenn man abhängig ist. Denn ein Key-Value-PoC kann oft dadurch überzeugen, dass er schnell und flexibel, quasi ohne DB-Expertise, aufgesetzt werden kann. Genau das kann aber ein Problem sein, denn es gibt keine natürliche „Last Line of Defence“ zwischen dem Datenmodell und der Entwicklung. Schraubt man über  die Applikationsentwicklung  nur lange genug an  den Datenstrukturen im Backend, schafft man es irgendwann garantiert, das System völlig zu verkorksen. Man könnte sich das so vorstellen: Jeden Tag wird eine zusätzliche Information in die .json-Struktur aufgenommen (in unserem Beispiel: Hausnummer, PLZ etc.). In der Vergangenheit erzeugte Values werden aber nicht automatisch mit einem Update versehen. Ergo: Das Datenmodell läuft mit der Zeit auseinander. Und da sich in aller Regel die Anforderungen an eine Lösung permanent ändern, gibt es im Ergebnis mit hoher Wahrscheinlichkeit keine größere Key-Value-Installation, deren Datenmodell nicht mindestens an einer Stelle nahezu unbrauchbar geworden ist. Darum: Nur weil etwas in der Herstellung einfach und schnell geht, ist es mittel bis langfristig noch lange nicht sinnvoll.

Spaltenorientierte Datenbanken

Einen Gegenentwurf zu den grade beschriebenen Key-Value-Eigenschaften bilden spaltenbasierte Systeme. Spalten-(Column-)oriented bedeutet, dass Daten auf den ersten Blick ganz ähnlich wie bei einem Key-Value-Store abgelegt werden. Technisch werden sie jedoch spaltenweise und/oder partitionsweise auf Platte oder InMemory verwaltet. Das Ziel ist, Schreib- und/oder Lesezugriffe zu optimieren. Eine spaltenorientierte Datenbank arbeitet dabei in der Regel auch mit einem eindeutigen Schlüssel, der sich wiederum aus der Kombination unterschiedlicher Werte zusammensetzten kann. So ist es beispielsweise möglich, den Identifikationsschlüssel eines Datensatzes aus den Rohdaten selbst zu errechnen.

Systeme dieses Typs eignen sich hervorragend, wenn gleichförmige Daten verwaltet werden sollen. Einmal richtig implementiert, sind sie in Sachen Geschwindigkeit bei großen Volumen kaum zu überbieten. Die Modellierung des Datenmodells richtet sich jedoch nach der gewünschten Abfrage. Änderungen in der Datenstruktur aufgrund modifizierter Abfragen sind auf der technischen Ebene anstrengend, da in der Regel eine Datentabelle je fachlicher Anfrage modelliert wird. Dieses Paradigma ist übrigens das Gegenteil der relationalen „Normalisierung“, da identische Datensätze bewusst redundant abgelegt werden. Im Gegensatz zu den Key-Value-Datenbanken beschützt ein solches System sein Datenmodell per Design. Aus diesem Grund verliert z. B. Cassandra auch häufig einen PoC gegen MongoDB und ist bei den typischen Entwicklern weniger beliebt. Eben weil die initiale Implementierung aufwendiger ist und man sich intensiver mit der Technologie und dem Datenmodell beschäftigen muss.

Eine vorschnelle Entscheidung für oder gegen eine bestimmte Datenbank kann sich durchaus erst nach 12 bis 18 Monaten im Regelbetrieb rächen, wenn z. B. Probleme oder Herausforderungen der Key-Value-Stores auftreten, weil sich niemand für das Datenmodell interessiert. Unwissenheit schützt auch hier vor Strafe nicht. Der bequemere Weg nach dem PoC hat sich nicht selten als der schlechtere erwiesen, da nicht alle Facetten der Technologie ausreichend bewertet und verstanden wurden.

Graph Database

Einen völlig anderen Ansatz, Daten zu speichern und auszuwerten, bieten Graph-Datenbanken.

Sie werden häufig verwendet, um Beziehungen zwischen Daten sichtbar zu machen. Deshalb werden gern dreidimensionale Darstellungsmodelle verwendet, um Ergebnisse zu visualisieren. Man kann solche Datenbanken vor allem einsetzen, um die Beziehung von Entitäten zu analysieren und beispielsweise Muster zu erkennen. In unserem einfachen Beispiel ergänzen wir die Informationen aus der ursprünglichen Tabelle um einige Eigenschaften, damit der Sinn einer solchen Datenbank besser darstellbar ist. Häufig nutzen Graph-Datenbanken andere Datenbanksysteme als Datenbasis für entsprechende Auswertungen oder Darstellungen. Eine Anwendung z. B. im klassischen ERP-Bereich ist dabei eher unüblich, da es sich bei diesen Technologien um Werkzeuge handelt, die im wesentlichen analytischen Anwendungsfälle fokussieren.

Im nächsten Beitrag dieser Serie werden wir uns mit hybriden Verteilungskonzepten beschäftigen. Im Fokus der Betrachtung stehen dann insbesondere die als NewSQL bekannten Systeme.