Die Grundidee von NoSQL

Nach mehr als 15 Jahren einer fast uneingeschränkten Herrschaft der SQL-basierten Datenbanken (SQL steht für Structured Query Language, also zu Deutsch »strukturierte Abfragesprache«) findet nun ein Wechsel in der Landschaft der Web-Applikationen statt.

Web-Applikationen entwickeln mit NoSQL erklärt das Konzept von NoSQL

Diese Technologie hat prinzipiell ein Ziel: die Nachteile bestehender, eingeführter Datenbanksysteme auszugleichen. Die Technik soll besser skalierbar sein und eine bessere Performance bei hoher Datenlast mit vielen umfangreichen Transaktionen bieten. NoSQL-Datenbanken haben im Gegensatz zu relationalen Datenbanksystemen kein festes Schema zur Speicherung der Daten. Dies ist eine radikale Änderung zu SQLDatenbanken, die auf eine strenge Struktur (oder ein strenges Schema) der gespeicherten Daten achten.

NoSQL-Datenbanken können folgende Eigenschaften besitzen:

nicht-relational
schemafrei
horizontal skalierbar
BASE
einfache Replikation

BASE - Basically Available, Soft State und Eventual Consistent

Da RDBMS (relationale Datenbankmanagementsysteme, also konventionelle Datenbanken) sehr streng auf die Konsistenz der Daten achten, kann es hier zu Problemen mit der Performance und Verfügbarkeit kommen. Dieses Konzept wird bei NoSQL zugunsten der besseren Skalierbarkeit und auch Verfügbarkeit aufgeweicht. Man akzeptiert die »lose Konsistenz«. Dabei wird die Datenkonsistenz von nachfolgenden Datenoperationen immer wieder neu hergestellt. Die Datenbank wechselt dadurch immer wieder zwischen einem konsistenten und inkonsistenten Zustand. Im Gegensatz dazu müssen sich SQL-Datenbanken dauerhaft in einem konsistenten Zustand befinden.

Werden durch verschiedene Datenbankoperationen Duplikate im Datenbestand angelegt, so wird die Datenbank durch eine zeitversetzte Synchronisierung immer wieder in einen konsistenten Teilzustand versetzt. Wobei der Begriff Eventual Consistent festlegt, dass alle Clients, die die Daten nutzen, nur in einem bestimmten Zeitfenster einen konsistenten (denselben) Datenbestand sehen.

CAP - Consistency, Availability und Partition Tolerance

Der Informatiker Eric Brewer vermutete im Jahr 2000, dass Systeme zum verteilten Rechnen nicht alle drei genannten Eigenschaften gleichzeitig erfüllen können. Diese Überlegung war und ist besonders wichtig für das Erstellen von Applikationen mit NoSQL-Datenbanken, denn sie sind verteilte Systeme.

Consistency - Konsistenz - Alle Clients sehen zur selben Zeit dieselben Daten
Availability - Verfügbarkeit - Ein Ausfall eines Clients (be)hindert die restlichen verfügbaren Clients nicht am Weiterarbeiten.
Partition Tolerance - Partitionstoleranz - Das verteilte System arbeitet trotz zufälliger Verluste von Nachrichten fehlerfrei weiter.

Im Jahr 2002 lieferten Seth Gilbert und Nancy Lynch einen axiomatischen Beweis, dass Brewers Vermutung richtig ist und nur zwei der drei Eigenschaften gleichzeitig erfüllt werden können. Dieses Theorem wirkt sich, wie wir später sehen werden, entscheidend auf das Design von NoSQL-Datenbanken aus.

Arten von NoSQL-Datenbanken

Datenbanken lassen sich in verschiedene Klassifikationssysteme einordnen. Am einfachsten gehen wir dabei vor, wenn wir die Art der Datenspeicherung betrachten. Für jede der folgenden Arten gibt es typische Vertreter und auch Anwendungsgebiete. Daher muss man sich vor der Wahl der Datenbank über das Anwendungsgebiet oder auch die zu verwaltenden Daten klar werden.

Dokumentenorientiert

Ganzen Artikel lesen...

Diese Datenbanken speichern Textdaten von beliebiger Größe in unstrukturierter Form. Der Zugriff auf die Daten erfolgt hier über die Dokumentinhalte. Hierzu gehören Apache CouchDB2, MongoDB3 oder auch Lotus Notes4.

Key-Value-orientiert

Hier werden definierte Schlüssel verwendet, die auf einen bestimmten Wert verweisen. Diese Werte können aus beliebigen Zeichenfolgen bestehen. Die Key-Value-Datenbanken können entweder als In-Memory- oder als On-Disk-Version implementiert werden. Die Implementierung In-Memory eignet sich zum Beispiel sehr gut für Cache-Speichersysteme, da sie speicherresistent ist. Dies ist zum Beispiel das System memcached5. Die On-Disk-Version ist für große Datenmengen vorgesehen und wird beispielsweise von Google BigTable6 oder Amazon SimpleDB7 implementiert. Eine Kombination der beiden Versionen vereint - so gut es geht - die Vorteile beider Implementierungen miteinander. Eine Implementierung ist zum Beispiel Redis8 und wird aktiv von GitHub9 eingesetzt.

Spaltenorientiert

Hier werden die Daten als Schlüssel-Wert-Relation, auch Key/Value oder Tupel genannt, abgelegt. Das Hauptaugenmerk liegt hier auf der Verminderung der Ein-/Ausgabe- Aktivität bei der Berechnung der Datensätze. Ein Vertreter ist beispielsweise die Datenbank Cassandra10 der Apache Foundation11. Diese Art von Datenbanken ist beispielsweise bei Facebook12, Digg13 oder Twitter14 im Einsatz.

Graphenorientiert

Diese Datenbanken spiegeln die Beziehungen der Daten zueinander wieder. Dazu werden die Daten in einer Art Baumstruktur gespeichert. Sie eignen sich ideal zur Darstellung von Beziehungen in sozialen Netzwerken. Dabei werden die Daten als einzelne Knoten und die Beziehungen als Verbindungen zwischen diesen dargestellt. Beispiele für diese Art der Datenbank sind FlockDB15 (wie sie Twitter verwendet), AllegroGraph16 oder Neo4j17.

Die passende Ergänzung zu diesem Artikel: