Einführung in die dokumentenorientierte NoSQL-Datenbank RavenDB

SQL oder NoSQL
Kommentare

NoSQL ist neben Cloud Computing eines der Hypethemen dieses Jahres. Deshalb ist es höchste Zeit, einen genauen Blick auf die Bedeutung von NoSQL und seine Funktionsweise zu werfen. Es werden die Ideen sowie verschiedene Arten und Anbieter von NoSQL-Datenbanken vorgestellt. Die Umsetzung dieser Konzepte unter .NET werden anhand der dokumentenorientierten NoSQL-Datenbank RavenDB praktisch verdeutlicht. Da diese in .NET geschrieben ist, bietet sie neben einem RESTful API noch eine native .NET-Schnittstelle und ist daher für .NET-Entwickler besonders geeignet.

Viele Entwickler denken bei einer neu zu entwickelnden Software zuerst an ein Datenbankmodell. Es werden Entity-Relationship-Modelle erstellt, Tabellen designt und auf einem SQL Server implementiert. Und dieser Prozess verdient viel Liebe und Aufmerksamkeit. Das bedeutet aber auch, dass in einer frühen Phase bereits viel Zeit und Energie in das Datenbankdesign investiert wird, die man vielleicht anderweitig hätte gebrauchen können. Des Weiteren drängt sich die Frage auf, ob eine relationale Datenbank überhaupt für alle Problemstellungen eine gute Lösung ist. Für die meisten Technologien in der Softwareentwicklung gilt der Satz „Diese Technologie ist kein Allheilmittel für alle Probleme“. Sobald es aber um Datenpersistenz geht, scheint das nicht mehr zu gelten, es herrscht scheinbar ein Mangel an Alternativen. Die NoSQL-Bewegung beweist, dass es diese Alternativenlosigkeit nicht gibt und dass es für bestimmte Probleme bessere Lösungen gibt als relationale Datenbanken.

Kernkonzpete relationaler Datenbanken

Die Grundlagen für relationale Datenbanksysteme (RDBMS) wurden 1970 von Edgar F. Codd in seinem Aufsatz „A Relational Model of Data for Large Shared Data Banks“ geschaffen. Die zentralen Konzepte relationaler Datenbanken werden durch das Akronym ACID ausgedrückt. Damit sind vier Eigenschaften transaktionaler Verarbeitung gemeint: Atomic, Consistent, Isolated und Durable. Transaktionen sollen atomar, also untrennbar und nicht zerlegbar sein. Eine Transaktion soll von einem konsistenten Zustand in einen anderen konsistenten Zustand führen. Sie soll von anderen Transaktionen isoliert und nach ihrer Beendigung dauerhaft sein. Konsistenz ist dabei für RDBMS ein besonders wichtiges Kriterium. Das Schema, das allen relationalen Datenbanken zugrunde liegt, wird normalisiert, um mindestens den ersten drei der fünf Normalformen zu entsprechen. Ein Ziel dieser Normalisierung ist die Vermeidung von Redundanzen in den Daten. Das führt einerseits zu einer bessern Konsistenz, da eine Änderung an einer Stelle überall dort Auswirkungen hat, wo der entsprechende Datensatz verwendet wird. Andererseits kann durch die Vermeidung von Duplikaten Speicherplatz eingespart werden.

Wie aber sind diese Designziele heute zu bewerten? Den Zwang, ein Schema festzulegen, bevor man Daten speichern kann, haben sicherlich viele Entwickler schon als unangenehm empfunden. Auch Änderungen am Datenbankschema sind keine erfreuliche Aufgabe. Darüber hinaus sind 80 Prozent der Daten in Unternehmen semi- oder unstrukturiert. Kommt dann noch eine hohe Änderungsrate ins Spiel, wird das Schema schnell zur Qual. Die Einsparung von Speicherplatz war in den 70er Jahren sicherlich ebenfalls ein hehres Ziel, immerhin schlug ein Megabyte Festplattenplatz 1956 noch mit 10 000 US-Dollar zu Buche. Wie sehr sich die Zeiten geändert haben, macht Abbildung 1 deutlich: Eine Internetrecherche förderte zur Drucklegung des Artikels eine zwei Terabyte große Festplatte für etwa 80 US-Dollar zu Tage, also einen Terabyte Speicherplatz für 40 US-Dollar. Das entspricht einem Preis pro Megabyte von etwa 0,000000000036 US-Dollar oder 262 Megabyte pro Cent. Auf das Sparen von Festplattenspeicher kommt es heute also sicherlich auch nicht mehr an. 

Abb. 1: Der Preisverfall des Festplattenspeichers
Abb. 1: Der Preisverfall des Festplattenspeichers

Wie ist des Weiteren mit der referenziellen Integrität umzugehen, wenn bei der Änderung eines Datensatzes, zum Beispiel eines Kunden, alle Referenzen auf diesen Kunden bei einer erneuten Abfrage die neuen, veränderten Daten anzeigen? Die Verarbeitung von Rechnungen ist nur eins von vielen Beispielen, wo dieses Verhalten eine Katastrophe ist. Überall dort wo Audit-Anforderungen bestehen oder Revisionssicherheit gefragt ist, ist ein solches Design schlichtweg unbrauchbar. Also umgeht man die referenzielle Integrität oder dupliziert doch Daten.

Umdenken mit NoSQL

Es gibt also Szenarien in denen relationale Datenbanken nicht die optimale Lösung darstellen. Das ist großen Firmen nicht zuletzt im Zusammenhang mit dem Internet klar geworden. Hier wird man mit riesigen Datenmengen konfrontiert. Lag das Datenvolumen im Internet 2006 noch bei 161 Exabytes, ist es 2010 auf fast 1000 Exabyte gestiegen (Abb. 2), Tendenz steigend. Ein Exabyte entspricht einer Milliarde Gigabyte (Gigabyte – Terabyte – Petabyte – Exabyte). Es liegt auf der Hand, dass es ein extrem skalierbares Daten-Backend braucht, um dieser Masse an Daten Herr zu werden. Und hier liegt ein weiteres Problem von RDBMS: Die Daten sind schlecht skalierbar. Addam Wiggins bringt es in seinem Blog auf den Punkt. Auf die häufig gestellte Frage „Wie skaliert ihre eure relationalen Datenbanken?“ lautet die Antwort „Wir tun es nicht“, weil es nicht geht. Weiterhin besagt das zuerst 2000 von Eric Brewer als Vermutung geäußerte und später 2002 bewiesene CAP-Theorem, dass ein DBMS von den drei Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz immer nur zwei gleichzeitig erfüllen kann. Bei den RDBMS ist neben der Konsistenz noch die Verfügbarkeit ein wichtiger Punkt. Und hier kommt die NoSQL-Idee ins Spiel: Wenn man auf die unbedingte Konsistenz verzichtet, kann man dafür Partitionstoleranz erwerben, das ist eine Eigenschaft die eine Skalierung erheblich vereinfacht. Als Gegenpol zu ACID bei den relationalen Datenbanken setzt die NoSQL-Bewegung das Akronym BASE, erstmals formuliert von Werner Vogels von Amazon. Das steht für Basically available, Soft State, Eventually consistent. Erklärungen zu diesen Akronym gibt es zur Genüge, wichtig ist, dass erkannt wurde, dass man auf Konsistenz verzichten kann, um andere Eigenschaften dafür zu gewinnen. 

Abb. 2: Wachstum der Daten im Internet
Abb. 2: Wachstum der Daten im Internet

Es gibt verschiedene Arten von NoSQL-Datenbanken. Die NoSQL-Bewegung steht nicht für die Abschaffung von RDBMS, sie will vielmehr ein vorliegendes Problem durch eine passende Technologie lösen. Daher steht NoSQL auch nicht für „Kein SQL“, sondern für „Not only SQL“. Es steht für „Wähle das richtige Tool“. Allen NoSQL-Datenbanken ist gemein, das sie über kein oder ein deutlich gelockertes Schema verfügen. Es wird komplett auf Joins verzichtet, da sie die Partitionierung erschweren und bei Abfragen teuer sind. NoSQL-Systeme haben das Ziel, eine gute Abfrageperformance zu bieten, da die Anzahl von Lese- und Schreibvorgängen inhärent asymmetrisch ist. Alle relevanten Informationen sollen auf einen Schlag gelesen werden. Die einfachste Form der NoSQL-Datenbank ist der Key/Value Store. Er speichert zu einem Schlüssel einen BLOB als Daten. Es kann nur über den Schlüssel gelesen werden. Eine weitere Form, die in diesem Artikel noch näher behandelt wird, sind dokumentenorientierte Datenbanken wie RavenDB. Sie speichern Daten in Form von Dokumenten, im Fall von Raven in Form von JSON Strings. Das ermöglicht eine bessere Verarbeitung der Daten in der Datenbank (z. B. Indizierung). Viele große Unternehmen bieten inzwischen NoSQL-Datenbanken an, typischerweise im Cloud-Umfeld. Eine ausgezeichnete Übersicht bietet [6]. Mit von der Partie sind zum Beispiel Amazon, Microsoft, IBM und Google.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -