NoSQL

Als Motivation für NoSQL werden hier ein paar Gründe beschrieben, kein RDBM zu nutzen.
Die heutigen Datenbestände sind groß und unstrukturiert. Es werden viele Lese- und Schreiboperationen auf unterschiedlichste Daten getätigt. Je nach Anforderungen gibt es sehr viele Schreiboperationen auf den Datenbestand und Konzepte der RDBM wie Fremdschlüssel und Joins werden nicht oft gebraucht.
RDBM hat eine relationale Struktur und ist auf Leseoperationen optimiert. Außerdem ist die Struktur auf Schlüsselbeziehungen und Joins ausgerichtet.

NoSQL-Datenmodelle

Das Datenmodell beschreibt wie die Datenbank die Daten organisiert.

• Key-Value-Stores
• Riak
• Document Stores
• MongoDB
• Wide Column Stores
• Cassandra
• Graph Databases
• Neo4J, Infinite Graph, OrientDB und FlockDB

Aggregate

Aggregatorientierte NoSQL-Datenmodelle sind Key-Value-Stores, Document Stores und Wide Column Stores.

Verteilungsmodelle

Verteilungsmodelle über die wir in der Vorlesung gesprochen haben sind Single-Server, Sharding, Master-Slave Replikation und Peer-to-Peer Replikation.
Außerdem haben wir über verschiedene Stufen der Konsistenz in einer DB gesprochen. Dies waren Update Consistency, Read Consistency und Relaxing Consistency.
Dies waren aber Themen die wir bereits zuvor in der Datenbankvorlesung hatten und deshalb werde ich hier nicht weiter darauf eingehen.

CAP-Theorem

• Consistency (Konsistenz)
• alle Knoten sehen zur selben Zeit dieselben Daten
• Availability (Verfügbarkeit)
• alle Clients können stets lesen und schreiben
• Partitioning tolerance (Partitionstoleranz)
• das System funktioniert trotz Verlust von Nachrichten zwischen Knoten bei Netzwerkpartitionierung weiter

Theorem: Ein verteiltes System kann maximal zwei der drei Eigenschaften erfüllen.

Es gibt die folgenden drei Fälle:

Quelle: Vorlesungfolien

Fall CP

Ein verteiltes System, das eine Netzwerkpartitionierung hat und konsistent ist, kann nicht die Verfügbarbarkeit erfüllen. Dies führt dazu, dass Transaktionen blockiert werden und Merge Konflikte verhindert werden.

Beispiele für Datenbanken, die die CP Eigenschaften besitzen, sind MongoDB, BigTable und HBase.

Fall AP

Ein verteiltes System, welches eine Netzwerkpartitionierung hat und verfügbar ist, kann die Konsistenz nicht erfüllen. Dies hat zur Folge, dass Clients immer schreiben können, aber verschiedene Versionen von Daten auf verschiedenen Knoten vorhanden sind (inkonsistente Daten).

Beispiele für Datenbanken, die die AP Eigenschaften besitzen, sind Dynamo und Cassandra.

Fall CA

Ein verteiltes System, welches konsistent und verfügbar ist, kann nicht gut mit einer Partitionierung umgehen. Relationale Datenbanken wie DB2 und Oracle streben vor allem Konsistenz an und ein RDBMS-Cluster fällt in diese Kategorie.

BASE vs ACID

RDBMS gewährleistet für Transaktionen ACID-Eigenschaften, während für NoSQL DB die BASE-Eigenschaften gelten. Diese sind weicher als die ACID-Eigenschaften.

ACID

• Atomicity
• Die Ausführung einer Transaktion erfolgt ganz oder gar nicht
• Consistency
• Transaktionen überführen die Datenbank von einem konsistenten Zustand in einen anderen
• Isolation
• Transaktionen werden so ausführt, als wenn sie alleine auf der Datenbank operieren würden
• Durability
• Transaktionen sind nach erfolgreichem Abschluss dauerhaft und gehen auch durch Fehler nicht mehr verloren

BASE

• BA - Basically Available
• Bei einem partiellen Ausfall von Teilen des verteilten Systems läuft der Rest des Systems weiter
• S - Soft State
• die Daten werden irgendwann mit aktuelleren Daten überschrieben
• E - Eventually Consistent
• die DB kann in einen inkonsistenten Zustand kommen, aber irgendwann werden alle Replika aktualisiert