NoSQL-Kriterien

Folgende Kriterien sind es, die NoSQL-Datenbanken von relationalen Systemen unterscheiden:

1. Datenbankmodell nicht relational: Dies ist der gemeinsame Nenner aller NoSQLs. Diese Datenbankmodelle bieten in bestimmten Anwendungsfällen eine bessere Performance.

2. Verteilte und horizontale Skalierbarkeit: Für die enormen Datenmengen, die im Web zu bewältigen sind, ist es von Vorteil, wenn das Datenhaltungssystem von Beginn an mit dem Ziel effektiver Skalierung und Verteilung entwickelt wurde.

3. Open Source: Das Kriterium "Open Source" ist kein technisches Kriterium und nicht unumstritten: Googles und Amazons Datenbanksysteme sind zum Beispiel bekannte NoSQL-Datenbanken ohne Open-Source-Lizenz. Dennoch wird gerade das populäre MySQL immer wieder als Maßstab zu Vergleichen herangezogen.

4. (Fast) Schemafrei: Web-2.0-Anwendungen verlangen häufig Flexibilität. Änderungen an den Datendefinitionen bedeuten jedoch in Relationalen Datenbanken eine Überarbeitung des Schemas, was unter Umständen zu längeren Betriebsunterbrechungen führen kann. NoSQL-Systeme arbeiten stattdessen mit einer Versionierung von Daten und Konvertierungen im Rahmen von Hintergrundprozessen.

5. Unterstützung verteilter Architekturen und einfache Replikation: Aus dem Ziel einer besseren Skalierbarkeit und Verteilung resultiert zudem die Forderung nach einer besseren Unterstützung von Replikationen. Einige NoSQL-Datenbanken können mit einem Befehl repliziert werden.

6. Einfache Programmierschnittstelle (API - Application Programming Interface): SQL, das ursprünglich nicht für relationale Datenbanken entwickelt worden war, ist heute als Datenbanksprache trotz oder gerade wegen weniger Befehle sehr komplex geworden. Viele "Joins", Unterabfragen, ineinandergeschachtelte "Selects", rekursive Selects, machen die Abfragen teilweise schwer überschaubar und überfordern manche Programmierer. Daraus ergibt sich die Forderung nach einfacheren Programmierschnittstellen. Manche NoSQL-Datenbanksysteme bieten einfache Schnittstellen, aber dafür weniger mächtige an. Andere setzen für komplexe Abfragen auf Map/Reduce-Techniken. Ob aber mit View-Funktionen in JavaScript oder selbst programmierten Map/Reduce-Funktionen in vorgegebenen Sprachen wirklich eine Vereinfachung aufwendiger Abfragen erzielt wird, ist eher fraglich.

7. Konsistenzmodell nicht ACID (Atomicity, Consistency, Isolation, Durability): Für relationale Datenbanksysteme gilt das strenge Konsistenzmodell ACID, das für kritische Anwendungen mit zum Beispiel Auftrags- oder Finanzdaten unverzichtbar ist. Für andere Anwendungen mit unkritischen Daten beispielsweise in Social-Web-Portalen reicht stattdessen BASE (Basically Available, Soft State, Eventually Consistent) aus. Mit BASE liegt der Schwerpunkt auf der Verfügbarkeit und weniger auf der Konsistenz der Daten. Die Daten sind eben nur vielleicht konsistent oder, optimistisch ausgedrückt, fast immer konsistent.

Nach dem CAP-Theorem (CAP - Consis-tency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Ausfalltoleranz)) können Daten in verteilten Systemen nicht gleichzeitig konsistent, immer verfügbar und ausfalltolerant sein. Es können nur zwei der drei Kriterien erfüllt werden.

• Konsistenz: Alle Knoten sehen zur selben Zeit dieselben Daten.

• Verfügbarkeit: Knotenausfälle hindern die "Überlebenden" nicht daran weiterzuarbeiten.

• Partitionstoleranz: Das System arbeitet trotz willkürlicher Verluste von Nachrichten weiter.

Nicht alle NoSQL-Datenbanksysteme erfüllen sämtliche sieben Kriterien. Darüber hinaus verbessern die Anbieter von relationalen Systemen ihre Produkte laufend weiter, um Defizite auszugleichen.

Im Video: NoSQL-Datenbanken - MongoDB