NoSQL-Datenbanken für die Datenhaltung in der Cloud

Webanwendungen oder Server-Applikationen in kleinen und mittelständischen Unternehmen greifen für die Organisation und Speicherung der zu verarbeitenden Daten in den meisten Fällen auf klassische relationale Datenhaltungssysteme wie SQL-Datenbanken zurück. Der Vorteil dieser Systeme liegt auf der Hand: Sie sind einfach zu warten, hochverfügbar, (grundsätzlich) kostengünstig zu betreiben, garantieren Transaktionseigenschaften und lassen sich durch eine deskriptive Abfragesprache wie SQL (Structured Query Language) leicht in den Anwendungskontext einbinden. Die im Zuge der Verbreitung von Cloud-Infrastruktur und Big-Data immer stärker aufkommenden NoSQL-Datenbanken gehen hier einen anderen Weg, den wir uns im Folgenden etwas genauer anschauen wollen.

Wenn sich Geschäftsführer, Vorstände oder Berater über digitale Unternehmensstrategien austauschen, ist das Thema Cloud und verteilte Datenhaltung nahezu immer an der Spitze der Agenda. Logisch – schließlich wird die richtige (oder falsche) Entscheidung in Punkto Datenhaltung signifikanten Einfluss auf das Unternehmensergebnis haben. Entweder arbeiten wir produktiver, innovativer und kostengünstiger -oder wir versenken Unmengen an Liquidität im digitalen Nirvana. Mit ein wenig Verständnis über diese „neuen“ Datenhaltungskonzepte lassen sich derartige Geldvernichtungsorgien aber durchaus vermeiden.

NoSQL-Datenbanken im Kontext der Datenhaltung

Das Wachstum von Webanwendungen mit exponentiell steigenden Datenmengen in den letzten Jahren forderte die Entwicklung neuer Datenhaltungskonzepte, mit denen diese gigantischen Datenmengen auch in der Zukunft effektiv gehandelt und skaliert werden können.

Inzwischen liegen die täglich zu verarbeitenden Datenmengen, die bei den Internet-Giganten wie Google, Facebook oder Amazon auflaufen, im Petabyte Bereich und rasen mit hohem Tempo auf immer höhere Rekordmarken zu. Und das liegt sicherlich nicht nur an heimlich gesammelten Nutzerdaten, gefälschten Produktbewertungen und den frequenten Postings amerikanischer Chaos-Präsidenten.

Das heißt jedoch nicht, dass die bisherigen Datenhaltungssysteme für umfangreiche Webapplikationen und Softwaresysteme im digitalisierten Zeitalter nicht zu gebrauchen sind. Auch ein wesentlicher Anteil der Datenverarbeitung von Google und Co. basiert auf erweiterten (relationalen) SQL-Konzepten, die jedoch in einem modifizierten Umfeld operieren. Denn klassische relationale Datenbanksysteme kommen schnell an ihre Grenzen der Skalierbarkeit, wenn bestimmte Eigenschaften in der Datenhaltung garantiert werden müssen.

Relationale Datenbanksysteme basieren auf dem sog. ACID-Paradigma, das die Einhaltung bestimmter Bedingungen für Atomarität, Konsistenz, Isolation und Durabilität von Transaktionen gewährleistet. Doch genau dieses Pardigma führt auch dazu, dass relationale Datenbanksysteme für den Einsatz in verteilten und hochgradig beanspruchten Umgebunden nicht immer kompromisslos geeignet sind.

Zwar lässt sich im einfachen Mehrbenutzerbetrieb, der z.B. unternehmensintern über ein oder zwei Standorte organisiert wird, nahezu jedes relationale DBS einsetzen. Doch spätestens mit dem Aufkommen von verteilter Datenhaltung über die verschiedenen Winkel dieser Welt gelangen die relationalen Systeme aufgrund ihrer strikten Konsistenzanforderungen an ihre Grenzen der Skalierbarkeit, wenn viele Anwendungen und Transaktionen zeitgleich in der Datenhaltung herumfuchteln.

Das ACID-Problem

Genau diese ACID-Prinzipien, die im Normalbetrieb die Konsistenz (…) und Integrität der Daten garantieren, werden im verteilten Fall zum Flaschenhals. Das Flaschenhals-Problem lässt sich bereits physikalisch (im stark vereinfachten Modell) erläutern:

Gehen wir einmal davon aus, dass ein persistentes Speichermedium, auf dem die operative relationale Datenbank liegt (also eine Festplatte), rund 250 sequentielle Schreibvorgänge pro Sekunde verarbeiten kann. Laufen nun 5 Client-Anwendungen parallel, die jeweils 100 lesende und schreibende Transaktionen (TA) ausführen, müssten nun 5x 100 TA nacheinander verarbeitet werden (wenn wir davon ausgehen, dass die Reihenfolge der Transaktionen auch streng sequentiell angemeldet wird und sich nicht gegenseitig blockiert).

Damit ergeben sich bereits 500 Transaktionen, also rund 2 Sekunden rechnerische Wartezeit, bevor die letzte Transaktion (#500) verarbeitet werden kann. Aber auch nur, wenn wir alle sonstigen Faktoren wie Deadlocks, Sperren oder interne Recovery-Maßnahmen (REDO/UNDO-Operationen) bewusst außer Acht lassen.

Greift beispielsweise die Anwendung von Client 1 auf Daten zu, für die die Anwendung des Client 5 bereits eine Sperre hält, weil sie hier lesen oder schreiben möchte, können die Transaktionen von Client 1 nicht vollzogen werden, bis die Anwendung von Client 5 seine Transaktionen erledigt hat. Schließlich würde Nummer 5 gerne verhindern, dass durch zwischenzeitliches Schreiben „fremder“ Transaktionen auf den von ihr benutzten Objekten Inkonsistenz entsteht, die zum Abbruch einer Transaktion führen könnte.

Blöd nur, wenn auch Client 5 auf Objekte angewiesen ist, die in der Anwendung von Client 1 blockiert werden. Damit ist 1 von 5 und 5 von 1 abhängig. Diese zyklischen Abhängigkeiten sind ein Worst-Case Szenario in relationalen Systemen und werden als Deadlock bezeichnet, der im Regelfall zu einem Transaktionsabbruch führt. Je mehr Clients und Anwendungen hier parallel auf der Datenbank arbeiten, desto höher wird das Risiko für derartige Verklemmungen oder sogar ganze Systemausfälle.

Würde man die Datenbank nun auf mehr als eine Festplatte verteilen, hätte man zumindest die physikalische Beschränkung der sequentiellen Zugriffe gelöst. Damit ergeben sich dann aber wiederrum neue Probleme. Denn für ein effizientes (verteiltes) Arbeiten stellt das ACID-Paradigma auch hier ein Hindernis dar. Schließlich muss auch im verteilten Fall die Konsistenz und Integrität der Daten gewährleistet werden, damit alle Transaktionen mit den gleichen gültigen Objekten arbeiten können. Wir können die Daten also woanders speichern, müssen aber trotzdem sicherstellen, dass alle Anwendungen auf den identischen Datenbestand zugreifen können und mit den selben Objekten und Werten arbeiten.

Zwar skalieren verteilte Datenbanken mit ACID-Eigenschaften deutlich besser, als klassische relationale Systeme, aber auch hier können aufgrund der verwendeten Commit-Protokolle und Serialisierbarkeitsverfahren in der Datenhaltung Probleme auftreten, mit denen die Verfügbarkeit der Systeme massiv eingeschränkt werden könnte. Und damit wären wir wieder da, wo wir eigentlich angefangen haben: bei blockierten Transaktionen und nicht verfügbaren Systemen.

Ein möglicher Lösungsansatz für dieses Problem:

• Wir vereinfachen die Konsistenzbedingungen und geben uns mit abgestufter Inkonsistenz zufrieden, die wir dann erst später sinnvoll wiederherstellen.

Und genau hier kommen die NoSQL-Datenbanken als Konzept für hochverteilte Datenhaltungssysteme zum Einsatz. Oder anders gesagt: die Cloud.

In der IT-Praxis werden zwar bereits einfache Netzwerk-Speicher mit mehreren Festplatten, die über das Internet zugänglich sind, als „Cloud“ bezeichnet. Im Zusammenhang zum Kontext der NoSQL-Datenbanken ist diese Definition aber unzutreffend. Nicht jedes extern gespeichertes Word-Dokument, das der Chef über das WLAN bearbeiten kann, ist automatisch auch „in der Cloud“. Aber das nur am virtuellen Rande.

Was sind NoSQL-Datenbanken?

Aus unseren Erfahrungen mit den relationalen Datenbanken wissen wir also, dass insbesondere bei schreibintensiven Applikationen mit Mehrbenutzerbetrieb, der Indexierung von großen Datenmengen oder bei lastintensiven Transaktionen von verbreiteten Webapplikationen mit einer hohen Anzahl an Schreib- und Lesevorgängen die meisten Probleme und Leistungsengpässe auftreten.

Damit haben wir auch schon ein klar definiertes Setting an Problemstellungen, die durch die NoSQL-Datenbanken („Not only SQL“) gelöst werden können! Dabei ist NoSQL nicht einmal eine technische Weiterentwicklung oder eine grandiose Innovation. Genau genommen sind verteilte Datenbanken mit NoSQL sogar ein technischer Rückschritt, in dem wir uns lediglich auf das Wesentliche beschränken, das schon lange bekannt ist. Quasi Back 2 the Roots, Back 2 the Basics. Oder etwas formaler definiert:

NoSQL-Datenbanken sind ein Datenhaltungskonzept, das einen nicht-relationalen Ansatz verfolgt. Dabei können NoSQL verschiedene Datenbankmodelle zu Grunde liegen, die horizontal skalierbar sind und sich für den Einsatz im Kontext von Big-Data und Data-Mining eignen.

Das NoSQL-Konzept kann also mit vielen gleichzeitigen Schreib- und Lesezugriffen auf die Daten umgehen  und erfüllt dabei alle Anforderungen an die Skalierbarkeit der Systeme. Denn anders als in relationalen Datenbanken, in denen Tabellen, Spalten und Zeilen für die Speicherung von Datenobjekten genutzt werden, kommen bei NoSQL strukturierte Datenspeicher zum Einsatz. Das können Dokumente, Listen, Wertepaare oder Objekte sein, die zur Speicherung der Daten herhalten müssen.

Eigenschaften von NoSQL-Datenbanken

Diese Organisation bringt eine Reihe an Vorteilen für den Verarbeitungsprozess von Daten mit sich, von dem gerade Cloud-Umgebunden und Big-Data Applikationen sehr stark profitieren. Grundsätzlich weisen aber alle verteilten Systeme auf Basis von NoSQL-Datenbanken die folgenden Merkmale und Eigenschaften auf, die sie für den Einsatz in verteilten Umgebungen und im Big-Data Kontext prädestinieren:

• Performance im Datenzugriff
• Hohe Skalierbarkeit
• Hoher Datendurchsatz
• Geringe Komplexität im Datenschema
• Vermeidung von Mainframe-Hardware, dafür massentaugliche Komponenten
• Einfache Erweiterung und Installation von Datenbank-Clustern
• Elastizität durch Lastverteilung bei Bedarf

Natürlich lassen sich den klassischen relationalen Systemen diese Eigenschaften nicht gänzlich absprechen. Ein wesentlicher Unterschied von NoSQL zu „regulären“ SQL-Datenbanken besteht allerdings darin, dass sich NoSQL nicht auf das reine ACID-Paradigma stützt, sondern auf eine abgewandelte Form für verteilte Systeme, die als BASE-Modell bezeichnet  wird.

BASE steht für Basically Available, Soft State, Eventually Consistent und beschreibt den Verzicht auf absolute Konsistenz („eventually consistent“, also irgendwann), richtet sich dafür aber auf hohe Verfügbarkeit der Datenhaltungssysteme aus.

Verfügbarkeit meint in diesem Zusammenhang die Unterstützung von verteilten Datenbanken mit einer redundanten Datenhaltung auf einer hohen Anzahl an Servern, die beispielsweise verteilte Hashtabellen nutzen, um den Speicherort von Datein im verteilten System zu lokalisieren. Derartige Implementierungen finden sich in vielen NoSQL-Systemen und stoßen uns dabei auf eine der wichtigsten Eigenschaften: Den Umgang mit Replikaten [vgl. Kemper et al., Datenbanksysteme, 10. Aufl., De Gruyter Oldenbourg].

Replikate in NoSQL

Das Verwalten von Replikaten ist eine fundamentale Grundlagen in verteilten NoSQL-Datenbanken. Denn nur durch ein smartes Replikationsmanagement ist es möglich, dass in einer verteilten Datenhaltung unterschiedliche Anwendungen auf dasselbe (replizierte) Objekt zugreifen können und am Ende auch zwischen den verteilten Systemkomponenten eine gewisse Konsistenz herrscht.

Wird ein Objekt geändert, muss es zunächst auf allen anderen Knoten propagiert werden, bevor ein erneuter Zugriff darauf möglich sein kann. Nur so kann gewährleistet werden, dass Anwendungen auch mit den selben Objekten und Werten arbeiten, die aber irgendwo verstreut in der Cloud lokalisiert sind.

Doch dieser Vorgang benötigt Zeit und Ressourcen. Dabei kann es immer wieder vorkommen, dass Rechnerknoten in einem verteilten Datenhaltungssystem ausfallen und die Datensynchronisation unterbrochen wird.

Ist das der Fall (und das ist er in der Praxis ziemlich häufig!), steht das Datenhaltungssystem vor einer wichtigen Entscheidung:

• Warte ich beim Ausfall von Knoten und den darauf befindlichen Replikaten im Falle von Änderungsoperationen so lange, bis der gesamte Knoten mit seinen Replikaten wieder verfügbar ist und dann geändert werden kann, und halte alle anderen Transaktionen bis zu diesem Zeitpunkt auf
• oder akzeptiere ich eine bestimmte Inkonsistenz, die ich erst zu einem späteren Zeitpunkt wiederherstelle, kann dafür aber zwischenzeitlich weitere Transaktionen abarbeiten.

Diese (schematische) Fragestellung führt uns unmittelbar zum theoretischen Kern der verteilten NoSQL-Datenbanken: Das CAP Theorem.

Das CAP-Theorem in NoSQL

Fällt ein Teil der Knoten in verteilten Systemen aus, sprechen wir von einer Netzwerkpartition. In der Praxis kommt eine Netzwerkpartitionierung nicht nur bei Vollmond vor, sondern in größeren Netzwerken quasi am laufenden Band. Es muss nicht erst ein Rechenzentrum abbrennen oder geflutet werden, bevor uns ein Knoten abschmiert. Grundsätzlich reicht bereits ein Verbindungsabbruch oder zu lange Antwortzeit (Timeout) aus, um den Effekt eines Knotenausfalls und den damit verbundenen Problemen für die Datenkonsistenz herbeizuführen.

Das CAP-Theorem ist das theoretische Grundgerüst, mit dem genau solche Probleme angegangen werden.

Biser war unser Verständnis von Konsistenz eine semantische Integrität, in der eine Transaktion nur dann committen darf, wenn alle Integritätsbedingungen erfüllt sind. Aber da wir hier nicht bei relationalen Systemen und dem ACID-Paradigma sind, machen wir einfach ein paar Abstriche und formulieren diese Bedingung neu:

• Ein Commit erfolgt erst dann, wenn alle Replikate auf dem gleichen Stand sind.

Dieser Gedanke führt uns zu einer Klassifikation von verteilten Datenbanken, die durch die nachfolgende Grafik veranschaulicht wird:

Erläutern wir zunächst die drei Bestandteile dieses Venn-Diagrammes:

• Consistency (C): Nach dem erfolgreichen Abschluss einer Transaktion ist der gesamte Datenbestand in einem verteilten Datenbanksystem in konsistentem Zustand.
• Availability (A): Verteilte Datenbanksysteme müssen eine angemessene Reaktionszeit liefern, Transaktionen also möglichst schnell abarbeiten können.
• Partition Tolerance (P): Ein Ausfall in einem Knoten eines verteilten Systems darf nicht dazu führen, dass das Gesamtsystem ausfällt.

Diese drei Bestandteile C, A und P stehen allerdings in bestimmten Abhängigkeiten zueinander, sodass jeweils nur zwei Attribute paarweise in einem verteilten Datenbanksystem erreicht werden können.  Die Vereinigung aller drei Attribute ist in verteilten Systemen also grundsätzlich nicht möglich:

Nach diesen Abhängigkeiten ergeben sich drei Typen für verteilte Systeme:

• CA-Systeme, wie z.B. MySQL
• CP-Systeme, wie z.B. MongoDB, Google BigTable, MemcacheDB
• AP-Systeme, wie z.B. Amazon Dynamo, Apache Cassandra, CouchDB

Gerade AP-Systeme werden häufig als Datenbankgrundlage für Cloud-Umgebunden eingesetzt. Prominente Beispiele dafür sind Amazon Dynamo oder Apache Cassandra, die inzwischen sehr weit verbreitet sind [vgl. Weikum, G. & Vossen, G., Transactional Information Systems – Theory, Algorithms, and the Practice of Concurrency Control and Recovery, Morgan Kaufmann 2002, Weikum & Vossen 2002].

Wie wirken sich diese Eigenschaften auf die Performance verteilter Datenbanken aus?

Konsistenz

Es gibt eindeutig sichtbaren Systemzustand, an den sich alle Clients im System wenden können. Alle Clients sehen zu dem selben Zeitpunkt also auch die selbe Version eines Objektes, egal von welchem Knoten auf das Objekt zugegriffen wird.

Im Umkehrschluss bedeutet dass, dass im Änderungsfall erst die vollständige Änderung auf sämtliche Kopien eines Objektes auf allen anderen Knoten propagiert sein muss, bevor eine erneute Änderung auf dem selben Objekt von anderen Transaktionen ausgeführt werden kann. Je mehr Knoten und Replikate existieren, desto teurer ist natürlich die Propagierung für das betreffende Objekt.

Bei reinen Leseoperationen gewinnen wir hier den größten Performance-Vorteil. Denn hier können Clients auf allen Knoten lesen, auf denen Replikate eines Objektes existieren. Und in Cloud-Umgebunden sind das im Regelfall die Netzwerkpartitionen, die dem Client am nächsten liegen und damit die geringstmögliche Antwortzeit aufweisen.

Das funktioniert allerdings nur, wenn im betreffenden System eine globale Ordnung auf allen Operationen existiert, mit der ein Datensatz von einem initialen Zustand in den neuen Zustand überführt wird. Im nachfolgenden Beispiel erfolgt also zunächst der Schreibvorgang v1 auf Knoten 1, im Anschluss die Propagierung von v1 auf Replikate in Knoten 2 und erst dann ein Lesevorgang von v1 auf Knoten 2 [vgl. Weikum & Vossen 2002].

Verfügbarkeit

Die Verfügbarkeit in verteilten Systemen lässt sich nicht ganz so formal definieren, weil hier vielmehr die technische Infrastruktur für die Gewährleistung von Ausfalltoleranz zuständig ist. Allgemein lässt sich aber sagen, dass jede eingehende Anfrage an ein verteiltes Datenbanksystem eine Antwort in einer akzeptablen Zeit zurückgeben muss. Was nun akzeptabel ist, hängt natürlich vom Anwendungskontext und der Geduld der Datenbankmanager ab. Cloud-Applikationen in Militärumgebung haben hier sicherlich ein anderes Antwortverhalten als die Datenanalyse einer E-Commerce-Plattform für 50er-Jahre Klamotten.

Vereinfacht gesagt bedeutet das aber auch, dass jeder Client in VDBS immer lesen und schreiben können muss. Das setzt voraus, dass jeder Algorithmus in einer endlichen Zeit auch terminiert und andere Transaktionen weiterarbeiten können.

Ausfalltoleranz

Die Eigenschaft der Partition Tolerance macht das Ganze etwas anspruchsvoller. Denn auch bei einer Netzwerkpartition, also dem Ausfall von Knoten, muss das verteilte System korrekt antworten können. Ein Komplettausfall des gesamten Systems ist davon zunächst ausgenommen.

Fällt ein Teil der Knoten einer verteilten Umgebung aus, können somit zwei Varianten eintreten:

• Entweder ist das System konsistent, aber nicht verfügbar, weil bei einem Ausfall zunächst darauf gewartet werden muss, bis alle anderen Knoten wieder verfügbar sind und Änderungen propagiert werden können (CP).
• Oder Ein System ist verfügbar, dann aber nicht konsistent. Denn im Falle von Ausfällen kann es vorkommen, dass Propagierungen auf den ausgefallenen Netzwerkteilen nicht erfolgen konnten, somit also zumindest dort temporäre Inkonsistenz besteht und mit verschiedenen Versionen von Objekten gearbeitet werden muss (AP).

Zusammenhang

Kombinieren wir diese drei Eigenschaften, entstehen genau zwei wesentliche Abhängigkeiten:

• Keine Konsistenz ohne Verletzung der Verfügbarkeit
• Keine Verfügbarkeit ohne Verletzung der Konsistenz

Entweder blockieren wir also Abfragen, bis das Ankommen von Änderungsoperationen von allen Knoten bestätigt ist (kann zu erhöhter Antwortzeit führen und verletzt damit die Verfügbarkeit), oder wir antworten so schnell wie möglich, müssen dann aber in Kauf nehmen, dass die Antwort dann keine Konsistenz liefert.

Das macht deutlich, warum niemals alle drei Eigenschaften zusammen erreicht werden können, sondern lediglich die Kombination aus CA, CP und AP.

Konsistenzklassen

Durch die Abhängigkeiten zwischen C, A und P müssen wir also stets entscheiden, welche Eigenschaften Abstriche vertragen können. In hochgradig verteilten Systemen müssen wir aber immer davon ausgehen, dass der Ausfall von Knoten an der Tagesordnung ist. Das bedeutet, dass wir dann zwangsweise Abstriche in der Konsistenz zulassen müssen.

Das BASE-Prinzip legt hier den Fokus schließlich auf Verfügbarkeit und nicht auf Konsistenz, wie es bei ACID-Datenbanken der Fall ist. Damit lassen die verbreiteten AP-Systeme von Facebook, Amazon, Google und Co. also stets gewisse Inkonsistenz zu.

Aber auch in der Cloud können wir nicht gänzlich auf Konsistenz verzichten. Zur Wahrung der Konsistenz kommen sog. Konsistenzklassen zum Einsatz, die hier zumindest die abgestuften Konsistenzbedingungen garantieren. Im Wesentlichen sind das:

• Read-your-Writes
• Monotonic-Read
• Monotonic-Write
• Write-Follow-Reads
• Strong Consistency

Auf eine genaue Ausführung dieser Konsistenzklassen verzichte ich an dieser Stelle. Wir sollten nur mitnehmen, dass es auch in den verteilten Umgebunden forcierte Konzepte gibt, mit denen eine gewisse Konsistenz gewährleistet werden kann (und muss). Wir können unsere betrieblichen Applikationen also auch ohne gravierenden Datenverlust in die Cloud verlagern!

Ein interessante Fakt am Rande ist jedoch, dass auch das Änderungsverhalten in den Konsistenzklassen gewissen Bedingungen unterliegt, die beispielsweise durch Quorum-basierte Protokolle gesteuert werden. In der vereinfachten Kernaussage können Änderungen von Objekten nur auf weitere Knoten propagiert werden, wenn mehr als die Hälfte aller Knoten der Änderung zustimmt.

Diese Eigenschaft weckt leichte Assoziationen mit den Konsens-Protokollen der Blockchain-Technologie, in denen mehr als 50% der Hashleistung für eine erfolgreiche Änderung der Blockchain nötig ist. Damit wird auch verständlich, warum die Blockchain-Technik im Kontext der Cloud-Anwendungen so inflationär auftaucht. Beide Systeme weisen zumindest im Konsensverhalten starke Ähnlichkeiten auf, auch wenn die Blockchain nicht automatisch eine Cloud ist!

Gängige Datenmodelle für NoSQL-Datenbanken

Jetzt haben wir zwar die theoretischen Grundlagen für NoSQL-Datenbanken, aber noch keinen Bezug zum Anwendungskontext und noch immer kein Speichermedium für unsere Objekte. Schließlich speichern wir die Daten unserer Applikationen in NoSQL nicht in einem relationalen Tabellen-Schema mit div. Schlüsselbeziehungen, sondern benötigen dafür eine vereinfachte Struktur, auf der die CRUD-Operationen (Create, Read, Update, Delete) möglichst effizient ablaufen können.

Das sind im Kontext der NoSQL-Datenbanken insbesondere:

• Key-Value-Stores (Cloud und Big Data)
• Document-Stores (Cloud und Big Data)
• Wide-Column-Stores (Cloud und Big Data)
• Graphenbasierte Datenbanken (primär für wissenschaftliche Anwendungen)

Key-Value-Stores

Die KVS bieten ein sehr einfaches Schema an, das sich lediglich aus einem Schlüssel (Key) und einem Wert (Value) zusammensetzt. Werte können hier auch willkürliche Zeichenketten oder Listen sein, womit eine sehr einfache Datenhaltung und Replikation der Key-Value-Stores möglich ist.

Allerdings lassen sich KVS auch lediglich über den Key ansprechen und identifizieren, was die Abfrage-Möglichkeiten für die Key-Value-Stores entsprechend einschränkt. Prominenteste Vertreter dieses Ansatzes sind Amazons Dynamo oder REDIS.

Document-Stores

Die Document-Stores verfolgen einen ähnliche Ansatz wie die Key-Value-Stores und sind ebenfalls primär nur über einen Dokumentenschlüssel indexierbar und abfragbar. Doch für die Speicherung der Informationen kommen hier strukturierte Dateiformate wie XML oder JSON zum Einsatz.

Die schemafreien Document-Stores ermöglichen somit ebenfalls eine einfache Replikation und Datenhaltung, sind in der Anfrageverarbeitung auf den Dokumenten aber sehr beschränkt. Ein Beispiel für die praxisnahe Verwendung ist das CP-System von MongoDB.

Wide-Column-Stores

Teilen wir die Datenhaltung in einer Relation vertikal nach den Attributen auf und weisen jedem Attribut einen Schlüssel zu, lassen sich so auch umfangreiche Tabellen vollständig partitionieren. Wir speichern die Einträge also nicht mehr in Zeilen, sondern in Spalten. Wide-Column-Stores ermöglichen so einen enormen Performance-Zuwachs, da wir beim Indexieren von Relationen keinen unnötigen Attribute mehr lesen müssen, sondern direkt auf die Einträge zugreifen können.

Allerdings sind damit dann auch automatisch aufwändige Join-Operationen verbunden, wenn wir an alle Attribute eines Tupels kommen müssen, die ja nunmal über viele einzelne Tabellen verteilt gespeichert werden.

Bekannter Vertreter für Wide-Column-Stores als CP-System ist Googles Cloud BigTable, das auch die Datenbankgrundlage für die Google-Suche, Google-Analytics oder Google Maps bildet.

Was kosten NoSQL-Datenbanken in der Cloud?

In erster Linie muss für die Kostenermittlung einer Cloud-Infrastruktur die Anzahl der ablaufenden Schreib- und Leseoperationen auf den Daten berücksichtigt werden. Auf dieser Basis erfolgt nämlich auch die Skalierung der Lastverteilung in einem Cloud-Netzwerk und damit in den meisten Fällen auch die Preiskalkulation, die uns ein Cloud-Anbieter auf das unternehmerische Auge drückt.

Entsprechend müssen die Cloud-Anbieter ein gewisses Service-Level garantieren können, das die für unsere Applikationen nötigen Ressourcen bereitstellt. Diese Ressourcen können aber genauso wachsen oder schrumpfen, je nach dem, wie hoch der Ressourcenbedarf unserer Applikationen im Realbetrieb ausfällt.

Natürlich erfolgt die Ermittlung hier vielmehr auf algorithmischer Grundlage, die aus unternehmerischer Sicht so gut wie unmöglich nachvollziehbar ist. Erst dann folgen weitere Aspekte wie Speicherplatz oder Aufwand für Verschlüsselung und Datensicherung, die sich aber logischerweise aus dem Aufwand für das Scale-Out von NoSQL-Datenbanken ergeben.

Wer hier auf der sicheren Seite sein will, sollte also definitiv ein paar EZB-Euros in Experten für IT-Finanzplanung und Datenhaltung investieren, die hier eine solide Kalkulation für das Investment in Cloud-Infrastruktur liefern können.