NoSQL: Wie moderne Datenbanken arbeiten

Die Zuordnung zu diesen vier Kategorien ist bei manchen NoSQL-Datenbanken nicht eindeutig. Beispielsweise könnte Amazon SimpleDB [11] sowohl zu Wide Column Stores als auch zu den dokumentenorientierten Datenbanksystemen gezählt werden. Das NoSQL-Archiv bezeichnet die oben genannten Kategorien als Core-NoSQL-Systeme und unterscheidet zusätzlich zwischen Key/Value-basierten Datenbanken mit starker und mit schwacher Konsistenz. Neben den Core-NoSQL-Systemen werden die Soft-NoSQL-Systeme genannt. Dazu zählen objektorientierte Datenbanken, XML-Datenbanken, Grid-Datenbanken und sonstige nicht relationale Datenbaken.

Ebenso kann man NoSQL-Systeme nach dem Speichermedium unterscheiden. So ist Redis ein Key/Value Store [10], der alle Daten im Arbeitsspeicher hält, während Amazon SimpleDB [11] auf Festplatten setzt. Daraus ergeben sich natürlich ganz andere Performancecharakteristika und auch die Datenmenge, die verwaltet werden kann, unterscheidet sich bei diesen Datenbanken. Trotz der großen Unterschiede bei den einzelnen NoSQL-Spielarten haben sich einige typische neue Ansätze etabliert, die bei vielen NoSQL-Systemen verwendet werden.

CAP-Theorem

Eine wesentliche Motivation für solche Ansätze ist CAP. Das Akronym steht für die folgenden drei Eigenschaften:

  • Das C steht für starke Konsistenz (Consistency). Das bedeutet, dass alle Clients stets dieselben Daten sehen. Es gibt also zu keinem Zeitpunkt zwei Clients, die unterschiedliche Antworten auf die gleiche Anfrage erhalten.
  • Das A steht für Availability (Hochverfügbarkeit). Der Ausfall einzelner Knoten wird dann von den verbleibenden Knoten kompensiert, um die Funktionsfähigkeit des Gesamtsystems aufrecht zu halten.
  • Bei Partitionstoleranz (P) kann das System trotz Nachrichtenverluste (Netzwerkpartitionierung) weiter arbeiten.

Das CAP-Theorem besagt, dass ein verteiltes System höchstens zwei dieser Eigenschaften erfüllen kann, jedoch nie alle drei. Schlecht designte Systeme können natürlich im Extremfall noch nicht einmal eine der Eigenschaften erfüllen. Das Theorem hilft, die Eigenschaften verteilter Systeme zu planen. Für konkrete Systeme kann der Architekt eine der Kombinationen CA, CP und AP wählen. Klassisch sind für viele Persistenzlösungen gerade in Enterprise-Umgebungen CA-Systeme. Die deutschsprachige Wikipedia zählt die klassischen RDBMS wie DB2 und Oracle zu dieser Kategorie. Diese RDBMS verwenden Transaktionen, sodass die Datenbank immer konsistent (C) ist. Mit Multi-Master- oder Master-Slave-Replikation stellen die RDBMS Hochverfügbarkeit (A) sicher. Diese Systeme können also eigentlich nicht mit Netzwerkpartitionierung umgehen, weil dann die Replikation nicht mehr gewährleistet werden kann.

Ganz so schwarz-weiß sind die CAP-Eigenschaften aber nicht: Wäre ein CA-System tatsächlich intolerant gegenüber Netzwerkpartitionen, müssten alle für eine Transaktion relevanten Ressourcen auf einer Maschine liegen, andernfalls müsste das gesamte System bei einer Netzwerkpartitionierung stoppen oder inkonsistente Daten würden entstehen. Die Skalierungs- und Verteilungsmöglichkeiten wären damit stark eingeschränkt. Die CAP-Eigenschaften sind aber graduelle Größen. Auch ein CA-System besitzt eine gewisse Partitionstoleranz. Falls beispielsweise der Interconnect eines Shared-Disk-Datenbankclusters mit SAN ausfällt, arbeitet das System mit höherer Latenz weiter, weil zumindest noch ein Server arbeiten kann. Falls jedoch das SAN von den Datenbankservern nicht erreicht werden kann, fällt das Gesamtsystem aus, weil kein System mehr auf die Platte schreiben kann.

Bei einem großen verteilten System ist wegen der Anzahl der Komponenten die Wahrscheinlichkeit für das Eintreten eines partiellen Hardwareausfalls relativ hoch. Soll trotzdem ein ausfallsicheres System gebaut werden, kann man auf Partitionstoleranz nicht verzichten. Aber nicht nur für die Skalierung ist P unerlässlich. Ebenso ist P notwendig, wenn man Daten offline bearbeiten und später replizieren möchte. Beispiele dafür sind Offline-Storages im Browser oder NoSQL-Datenbanken auf mobilen Geräten. Daher ergeben sich dann die Optionen CP und AP, zwischen denen man sich entscheiden muss:

  • CP-Systeme: Diese verteilten Systeme garantieren starke Konsistenz und sind für Netzwerkpartitionen optimiert. Die starke Konsistenz verringert die Performance, denn typischerweise hat eine Partitionierung zur Folge, dass die Verfügbarkeit reduziert wird. Ein Teil des Systems darf keine Anfragen mehr bedienen, obwohl es funktionsfähig ist, um Datenreplikate in verschiedenen Netzwerkpartitionen nicht inkonsistent zu ändern. Google Bigtable und Apache HBase sind CP-Systeme.
  • AP-Systeme: Diese großen verteilten Systeme tolerieren vorübergehende Dateninkonsistenzen aus zweierlei Gründen. Zum einen soll die Lese- und Schreibperformance unter hochnebenläufigen Bedingungen verbessert werden. Zum anderen soll die Verfügbarkeit von lauffähigen Servern oder Systemen, die gerade offline sind, nicht unnötig eingeschränkt werden. Bekannte AP-Systeme sind CouchDB und Apache Cassandra. Mit diesem Ansatz ist auch das Replizieren von Daten auf mobile Systeme möglich.

Entsprechend des CAP-Theorems muss ein Kompromiss zwischen starker Konsistenz und Hochverfügbarkeit gefunden werden, um verlässliche verteilte Systeme mit enormen Skalierungsanforderungen bauen zu können. Die bereits beschriebenen AP-Systeme verzichten auf starke Konsistenz, um möglichst viele Server auch bei Netzwerkpartitionierungen einsetzen zu können. Die Konsistenz, mit der ein System arbeitet, kann aus Sicht eines Clients und aus der eines Servers betrachtet werden. Für einen Client ist wichtig, wie Datenänderungen für ihn sichtbar werden. Aus Sicht eines Servers ist der Datenfluss durch das System und die garantierte Sichtbarkeit von Updates ausschlaggebend.

Kommentare

Schreibe einen Kommentar

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