NoSQL-Datenbanksysteme

Neben den weit verbreiteten relationalen Datenbanken gibt es auch DBMS in denen die Daten nicht auf Basis des relationalen Datenmodells gespeichert werden. Diese Kategorie von Datenbanken wird als NoSQL bezeichnet.

Motivation und Grundidee

Mit dem Aufkommen von schnell wachsenden, weltweit verbreiteten Webanwendungen mit oft mehreren hunderttausend Nutzern und einem ebenso schnell wachsenden Datenbestand, wurden Datenbanksysteme benötigt, deren Kapazität sich schnell und ohne Beschaffung teurer Spezialhardware vergrößern lässt. Unter dem Begriff NoSQL werden verschiedene, neuartige Datenbanksysteme zusammengefasst, mit denen die Anforderungen von schnell wachsenden Internetanwendungen wie hohe Verfügbarkeit, einfache Skalierung und die Verarbeitung großer Datenmengen gezielt adressiert werden. NoSQL ist dabei kein standardisierter Begiff, sondern wurde durch die Community geprägt. Eine weithin akzeptierte Bedeutung lautet "Not only SQL" und spielt darauf an, dass NoSQL-Datenbanken nicht oder nicht nur mit der Standard DB-Anfragesprache SQL zu verwenden sind.

Bedeutung NoSQL

Wann ein DBMS im konkreten Fall in die Kategorie der NoSQL-Systeme fällt, kann nicht immer eindeutig entschieden werden. Ein Indiz, ob eine Datenbank zur Klasse der NoSQL-Datenbanken zählt, ist sinngemäß die Berücksichtigung einiger der folgenden Punkte:

1. Das zugrundeliegende Datenmodell ist nicht relational.
   Das relationale Datenmodell ist zwar das aktuell am meisten verwendete Datenmodell, jedoch gibt es zum Beispiel mit Wide Column Stores, Key-Value-Systemen, Document Stores und Graphdatenbanken noch eine Reihe anderer Datenmodelle. Diese zeichnen sich häufig unter anderem auch durch ein flexibleres Datenschema aus.


2. Konsequente Ausrichtung auf eine verteilte und horizontale Skalierbarkeit.
   Schnell wachsende Nutzerzahlen bedeuten in der Regel auch einen schnell wachsenden Datenbestand. Darüber hinaus sollen häufig auch datenintensive Objekte wie Filme, Musik oder Bilder verwaltet werden. Der Betrieb eines DBMS muss daher sehr schnell auf einen schnell steigenden Bedarf an Datenbankkapazität reagieren können. Mit horizontaler Skalierbarkeit ist das Ändern der Kapazitäten durch Hinzu- oder Abschalten eines weiteren DBMS bei laufendem Betrieb der Anwendung möglich. Dadurch entsteht ein verteiltes Datenbanksystem, bei dem die Gesamtheit aller Daten auf mehreren einzelnen DBMS gespeichert ist. Durch die Verteilung der Daten auf mehrere Systeme wird auch die Last eines einzelnen DBMS auf viele Systeme verteilt. Wurden beim Betrieb klassischer DBMS die internen Kapazitäten der Spezialhardware eines DBMS angepasst (Scale-up-Prinzip), so wird bei NoSQL-Systemen die Kapazität durch Hinzuschaltung weiterer Systeme geregelt (Scale-out-Prinzip).


3. Aufgrund der verteilten Architektur unterstützt das System eine einfache Datenreplikation.
   Das Replizieren des Datenbestands eines DBMS ist eine wichtige Eigenschaft, um eine horizontale Skalierung zu ermöglichen. Daher bieten viele NoSQL-DBMS eine einfache Möglichkeit, die in ihnen gespeicherten Daten zu replizieren, d.h. mehrfach abzuspeichern. Teilweise wird dazu nur ein Datenbankkommando benötigt.


4. Das System ist schemafrei oder hat nur schwächere Schemarestriktionen.
   Seit dem Internetboom in den 1990er Jahren werden Anwendungen agil entwickelt. Der Funktionsumfang vieler Webanwendungen entwickelt sich mit den Bedürfnissen einer schnell wachsenden Nutzeranzahl und dem Geschäftsmodell des Betreibers. Dabei muss es jedoch allen Nutzern permanent zur Verfügung stehen. Mit dem Funktionsumfang einer Anwendung ändert sich in der Regel auch das Datenschema. NoSQL Datenbanken verlagern die Verantwortung der Schemadefinition und der Einhaltung der durch das Datenschema vorgegebenen Beschränkungen in die Logik der Anwendung. Daher muss bei Anpassungen des Datenschemas nicht die gesamte Datenbank gesperrt und umstrukturiert werden. Mit NoSQL-Datenbanken wird der Datenbestand bei Schemaänderungen versioniert und die Konvertierung der Daten als Hintergrundprozess angestoßen. Das System bleibt verfügbar, es gibt jedoch eine Zeitspanne, in der das DBMS bei einer Anfrage noch nicht konvertierte alte Daten im neuen Schema ausliefert. Diese Einschränkungen bei der Konsistenz sind jedoch bei vielen (Unterhaltungs-)Anwendungen hinnehmbar. In sicherheitskritischen Systemen oder Systemen, bei denen große Mengen Geld verwaltet werden, sind hingegen Abschwächungen der Anforderungen an die Datenkonsistenz nicht akzeptabel.


5. Dem System liegt meistens ein anderes Konsistenzmodell zugrunde: Eventually Consistent und BASE, aber nicht ACID.
   Für die meisten relationalen Datenbanken gilt das ACID-Konsistenzmodell, das sehr hohe Anforderungen unter anderem an die Konsistenz von Transaktionen stellt. Viele Anwendungen aus dem Web 2.0 und Unterhaltungsumfeld haben im Gegensatz zu Systemen von Finanzdienstleistern wie Banken und Versicherungen jedoch keine besonders hohen Anforderungen an die Konsistenz. So können beispielsweise Nachrichten oder Statusinformationen in sozialen Netzwerken für einen bestimmten kurzen Zeitraum inkonsistent sein, ohne dass diese Inkonsistenz bemerkt wird oder ein Schaden entsteht. Fällt jedoch das System nur für einen kurzen Moment aus, hat das zum Teil deutliche Auswirkungen auf die Nutzerakzeptanz. Daher reicht für viele Anwendungen ein BASE-Konsistenzmodell (Basically Available, Soft state, Eventual consistency), in dem das Kriterium Verfügbarkeit höher als das Kriterium Datenkonsistenz gewichtet wird. Eventually Consistent bedeutet in dem Zusammenhang, dass der Datenbestand für kurze Zeit inkonsistent sein kann, jedoch nach einer gewissen Zeit ohne weitere Änderungen am Datenbestand wieder einen konsistenten Zustand erreicht.
   Einige, jedoch nicht alle, NoSQL-Systeme unterstützen das BASE-Konsistenzmodell. Die konkreten Anforderungen an Verfügbarkeit und Konsistenz bestimmen maßgeblich die Auswahl eines geeigneten DBMS.


6. Das System bietet eine einfache API.
   Die technische Schnittstelle zu relationalen Datenbanken ist die seit Jahrzehnten ausgereifte Structured Query Language. Mit ihr können sehr komplexe Anfragen an die Datenbank formuliert werden. NoSQL-Systeme ohne relationales Datenmodell bieten keine SQL-Schnittstelle an. Hier erfolgen die Anfragen an das DBMS über definierte technische Schnittstellen (engl.: application programming interface, kurz: API). Diese Schnittstellen sind in der Regel sehr einfach gehalten und bieten (noch) keine Unterstützung komplexer Anfragen.


7. Das NoSQL-System ist Open Source.
   Viele ursprüngliche NoSQL-Systeme sind Open Source Systeme oder aus ursprünglich als Open Source entwickelten Datenbanksystemen entstanden.