Sinn und Zweck von NoSQL Datenbanken

NoSQL Datenbanken sind in aller Munde und es wird eifrig darüber gemutmasst, ob sie das relationale Datenmodell zu Grabe tragen werden. Um es vorweg zu nehmen: Kaum!

Um was geht’s genau?

NoSQL steht für nicht etwa für no SQL, sondern für not only SQL. Ein Definitionsversuch von nosql-database.org: “Next Generation Databases mostly addressing some of the points: being non-relational, distributed, open-source and horizontal scalable”.

Der Begriff umfasst also nicht-relationale DB-Systeme und somit jene, die mit dem traditionellen relationalen Ansatz, wir er heute von allen populären Datenbanksystemen verfolgt wird, brechen.

  • Eine NoSQL Datenbank speichert zwar strukturierte Daten, zwingt diese aber nicht in vordefinierte Tabellenschemas. Die Struktur ist also weder einheitlich, noch verbindlich.
  • Des weiteren handelt es sich typischerweise um verteilte Datenbanken. Eine als logische Einheit erscheinende Datenbank kann demnach aus mehreren physisch voneinander unabhängig arbeitenden, aber untereinander verbundenen Datenbanken bestehen. Die grosse Herausforderung in einem solchen Verbund ist die möglichst sichere und wirtschaftliche Handhabung von Änderungen in weitverzweigten Datenbanken.
  • Das dritte wichtige Merkmal ist die horizontale Skalierbarkeit. Dabei begegnet man einem wachsenden Resourcenbedarf infolge einer grösseren Nennlast mit zusätzlichen Servern, die sich die Last teilen und die Ausfallsicherheit des Systems steigern (vertikale Skalierung im Gegensatz verlangt einen leistungsfähigeren Ersatz für das bestehende System).

Nun ist die Frage nach dem Begriff NoSQL geklärt, jedoch nicht, warum diese Systeme reihum so hoch im Kurs stehen. Wann lohnt sich der Einsatz einer solchen Datenbank?

Worin liegen die Vorteile?

Zunächst gilt es festzuhalten, dass NoSQL ein Überbegriff für eine Vielzahl von DBs mit unterschiedlichen Konzepten ist, weshalb die Vorteile nicht immer die selben sind.

SQL ist grundsätzlich ein äusserst flexibles Werkzeug. Nicht-relationale DBs vermögen gegenüber RDBMS’ nur unter bestimmten Gegebenheiten zu brillieren. Konkret bei schlechter Strukturierbarkeit der Daten und hohen Anforderungen an die Skalierbarkeit. NoSQL DBs können u.a. bei folgenden Symptomen in Betracht gezogen werden:

  • Wenn die Ausarbeitung eines geeigneten Schemas schwierig ist, sich die Daten also schwer strukturieren lassen. Dies impliziert eine Vielzahl von Attributen in einer Tabelle, von welchen kaum je ein Datensatz alle benötigt.
  • Wenn es häufiger Schemaanpassungen bzw. -erweiterungen bedarf, damit neue Daten überhaupt abgebildet werden können, oder wenn Modellierungsversuche gänzlich fehlschlagen und die Daten folglich serialisiert gespeichert werden müssen.
  • Wenn die Last auf der Datenbank in kurzer Zeit um Grössenordnungen variieren kann und vertikale Skalierung nicht wirtschaftlich oder aus anderen Gründen unmöglich ist (z.B. bei Cloud Diensten).

Beispiel: CouchDB

Um einige Vorteile von NoSQL zu verdeutlichen, betrachten wir exemplarisch die freie und dokumentenorientierte Apache CouchDB. “Couch” steht dabei für “Cluster Of Unreliable Commodity Hardware”, was die Skalierbarkeit, Verfügbarkeit und Verlässlichkeit selbst auf fehleranfälliger Hardware verdeutlichen soll.

Anstatt Daten in relationaler Manier tabellarisch zu speichern, verwaltet CouchDB seine Daten als Sammlung von JSON-Dokumenten, die keiner festen Struktur folgen müssen (ausser jener, die von JSON erzwungen wird). Der grosse Nachteil bei CouchDB (wie für alle NoSQL DBs) ist das Unvermögen, Joins über mehrere Dokumente durchzuführen. Dies ermöglicht aber gleichzeitig die automatische Partitionierung der Daten, was für die Skalierung von essenzieller Wichtigkeit ist. Dokumentenorientierte DBs handhaben gewisse Dinge genau umgekehrt als RDBMS. Einige RDBMS bieten für hohe Performanceansprüche die Möglichkeit, normalisierte Daten in Form von materialisierten Sichten (Oracle Terminologie) zu denormalisieren. Ein dokumentenorientiertes System speichert Daten prinzipiell unnormalisiert und bringt im Falle von CouchDB erst über Views Struktur in die Daten. Views werden in einer beliebig komplexen JavaScript-Funktion beschrieben und bieten eine beachtliche Flexibilität.

Ein Performance-Flaschenhals bei relationalen Datenbanksystemen (RDMS) liegt oft in der Tatsache, dass gleiche Queries repetitiv über riesigen Tabellen abgesetzt und alle involvierten Kalkulationen jedes mal aufs Neue durchgeführt werden müssen. Dies vielleicht ohne dass sich die Daten seit dem Insert je geändert haben und je nach Art der Daten mit einer Änderung auch nicht zu rechnen ist. Genau solche Berechnungen zu vermeiden ist das Potential von Views. Die Resultate eines Views werden von CouchDB in einer effizienten Datenstruktur (B-Tree) gespeichert. Nach der initialen Erstellung wird der Index eines Views nur noch inkrementell aktualisiert, d.h. es werden nur noch neue und geänderte Dokumente betrachtet. Dies macht Views vorallem für riesige Datensammlungen sinnvoll, gleichzeitig verlangsamen oder verunmöglichen sie aber auch das Absetzen von Ad-hoc Queries.

Die ganze Architektur von CouchDB basiert stark auf Konzepten des Webs und den Philosophien hinter HTTP. Der Zugriff auf die Daten erfolgt bei CouchDB ausschliesslich über eine REST-Schnittstelle, wobei Clients für eine Vielzahl von Plattformen verfügbar sind.

Fazit

Weder CouchDB, noch eine andere NoSQL Datenbank stellen einen Ersatz für eine relationale Datenbank dar. Die beiden Ansätze können grundsätzlich nicht gegeneinander abgewogen werden, da sie mit unterschiedlichen Methoden andere Probleme lösen. So gesehen existieren Anwendungen, die
mit RDBMS-Systemen nur bedingt oder gar nicht realisiert werden können. Trotzdem will die Abzweigung vom relationalen Pfad gut bedacht sein. Verteilte Datenbanken bergen grosse Herausforderungen, die man nicht bloss beschreiten sollte weil NoSQL als frisch, spannend und zukunftsweisend gilt. Der Aufwind von nicht-relationalen DBs ist aber garantiert legitim, nicht zuletzt hinsichtlich der wachsenden Popularität von Cloud-Diensten.

Kommentare sind geschlossen.