Es gibt zwei Trends, die dieses Problem in letzter Zeit immer mehr ins Zentrum der Aufmerksamkeit der internationalen Entwicklergemeinde gerückt haben:
- Die exponentielle Zunahme des Volumens der von Anwendern, Systemen und Sensoren produzierten Datenmengen und deren Konzentration auf große verteilte Systeme (Amazon, Google und andere Cloud-Systeme)
- Die zunehmende Abhängigkeit, Komplexität und Vernetzung von Daten, beschleunigt durch das Internet, Web 2.0, soziale Netzwerke und offene und standardisierte Schnittstellen zu Daten aus verschiedensten Systemen
Die relationalen Datenbanken sind diesen Entwicklungen in zunehmendem Maß nicht mehr gewachsen. Das hat zu einer Flut von alternativen Techniken für die Lösung spezieller Datenprobleme geführt, die alternativ oder zusammen mit den bestehenden SQL-Datenbanken angewendet werden können – auch als Polyglot Persistence bekannt. Es gibt schon lange alternative Datenbanken wie die Objektdatenbanken, Hierarchische Datenbanken (z. B. LDAP) und viele andere. Jedoch sind in letzter Zeit eine eine Reihe neuer Projekte gestartet worden, die unter dem Namen „NoSQL-Datenbanken“ bekannt sind.
Im folgenden Artikel soll eine Einführung in die Funktionsweise von Graphendatenbanken und ihre Positionierung im Umfeld der NoSQL-Bewegung gegeben werden. Der zweite Teil beleuchtet dann die Neo4j-Graphendatenbank ein wenig näher.
Das NoSQL-Umfeld
NoSQL (Not Only SQL) ist eigentlich eine sehr weite Bezeichnung für eine Gruppe von Persistenzmodellen und Datenbanken, die nicht das relationale Datenmodell anwenden und nicht SQL als Abfragesprache haben.
Kurz gesagt kann man die NoSQL-Szene aufgrund ihrer unterschiedlichen Datenmodelle in vier Kategorien einteilen:
- Key-Value-Datenbanken
- BigTable-Implementationen
- Dokumentendatenbanken
- Graphendatenbanken
Bei Key-Value-Systemen wie Voldemort oder Tokyo Cabinet ist die kleinste Modellierungseinheit das Key-Value-Paar, die BigTable-Klone hantieren viele Datentupel mit variablen Attributen, bei Dokumentendatenbanken wie CouchDB und MongoDB das Dokument. Graphendatenbanken sehen alle Daten als eine große vernetzte Struktur.
Hier sollen vor allem zwei Aspekte der Einteilung von NoSQL-Datenbanken aufgegriffen werden – die Skalierbarkeit und die Komplexität.
1. Skalierbarkeit
CAP: ACID vs. BASE
Um die referenzielle Integrität der Daten zu gewährleisten, sind die allermeisten klassischen Datenbanken transaktionsbasiert. Das gewährleistet die Konsistenz der Daten in allen Situationen der Datenhaltung. Die transaktionalen Charakteristiken sind auch unter dem Namen ACID (Atomicity, Consistency, Isolation, Durability) bekannt. Da ACID Datenkonsistenz voraussetzt, wird jedoch die Skalierung dieser Systeme ein Problem. Es kommt zu einem Konflikt der unterschiedlichen Zugänglichkeitsaspekte in verteilten Systemen, der nicht vollständig zu lösen ist - bekannt als CAP-Theorem:
- Strong Consistency: Alle Klienten sehen die gleichen Daten, auch bei Datenänderungen, z. B durch das Two-Phase-Commit-Protokoll (XA-Transaktionen), siehe ACID
- High Availability: Alle Klienten können immer wenigstens eine Kopie der Daten finden, auch wenn ein Teil der Maschinen aussetzt
- Partition-Tolerance: Das Gesamtsystem behält seine Eigenschaften, auch wenn es auf mehrere Maschinen verteilt wird.
Das CAP-Theorem sagt, dass man nur zwei der drei Skalierungsaspekte gleichzeitig erreichen kann.
Um mit CAP in großen verteilten Systemen arbeiten zu können, hat man die unterschiedlichen CAP-Merkmale unter die Lupe genommen.
Viele NoSQL-Datenbanken haben vor allem Consistency gelockert, um hohe Erreichbarkeit und Partionierung (AP) liefern zu können. Herausgekommen sind so genannte BASE-Systeme (Basically Available, Soft-state, Eventually consistent), die keine Transaktionen im klassischen Sinn haben und Einschränkungen im Datenmodell einführen, um bessere Partitionierungsmechanismen zu ermöglichen. Eine tiefere Erklärung von CAP, ACID und BASE gibt es in dieser Einführung.
