Datenbanken müssen heute mit neuen Anforderungen fertig werden. Wohl die größte Herausforderung: Das Datenvolumen wächst immer stärker. Dafür sind in erster Linie die vielen neu hinzugekommenen Datenquellen verantwortlich: Nutzer im Internet stellen Inhalte ein. Ständig kommt es zu neuen Diskussio-nen in Social Networks. Unternehmen digitalisieren Geschäftsprozesse zunehmend, zeichnen sie auf und verfolgen und analysieren sie immer detaillierter, um wettbewerbsfähiger zu werden.

Für diese Herausforderungen ist eine andere Form der Skalierbarkeit notwendig. Relationale Datenbanken benötigen leistungsfähigere Server, wenn mehr Daten verwaltet werden sollen oder höhere Performance notwendig ist (Scale-up). Dem sind aber Grenzen gesetzt: Trotz immer schnellerer CPUs ist die Server-Leistung limitiert. Außerdem steigt mit der Leistung der Preis überproportional an. Scale-up ist also nicht besonders kosteneffizient.

Dazu kommt, dass die anfallenden Daten zunehmend weniger strukturiert sind und keinem statischen Schema entsprechen. Durch das Semantic Web nimmt die Bedeutung dieser Gruppe aber weiter zu. Letztendlich entwickelt sich das Web von einer universellen Informationsquelle für Menschen auch zu einer universellen Informationsquelle für Anwendungen. Solche Daten in die Tabellen einer relationalen Datenbank zu pressen, ist jedoch sehr schwierig.

Diese Probleme sollen einige neue Spielarten von Datenbanken angehen, die sich neben dem relationalen Modell mittlerweile etabliert haben. Sie firmieren unter dem Sammelbegriff NoSQL.

1. Zunächst sind Key-Value-Datenbanken zu nennen. Sie haben ein sehr einfaches Datenmodell: Unter einem Schlüssel wird ein Wert gespeichert. Weitere Suchmöglichkeiten gibt es nicht. Diese Datenbanken ermöglichen eine sehr gute Skalierbarkeit und Performance. Beispiele sind "Riak" oder "Redis".

2. Bei den Large-Column-Datenbanken ist das Datenmodell mächtiger und dem relationalen Modell ähnlich, das heißt, es basiert auf einzelnen Tabellen. Auch hier sind sehr viele Spalten und sehr komplexe Tabellen möglich. Beziehungen zwischen den Tabellen werden allerdings nicht unterstützt. Die Skalierbarkeit der Lösungen ist ebenfalls sehr hoch. Beispiele sind "Apache HBase" oder "Apache Cassandra".

3. Dokumentenorientierte Datenbanken haben ein flexibles Datenmodell. Sie speichern Dokumente typischerweise in JSON (Javascript Object Notation) ab und können so nahezu beliebig komplizierte Datenstrukturen abbilden. Dabei gibt es kein Schema, so dass die Datensätze in einer Datenbank beliebige Strukturen haben können. Dennoch bieten diese Datenbanken eine gute Skalierbarkeit. Beispiele sind "Apache CouchDB" oder "MongoDB".

4. Schließlich gibt es noch Graphdatenbanken. Sie können Graphen wie die Freundschaftsbeziehungen in Social Networks besonders gut abbilden und sehr leicht passende Anfragen bearbeiten. Hier ist als Produkt vor allem "Neo4j" zu nennen.

Vor- und Nachteile von NoSQL

NoSQL-Technologien können mit den eingangs erwähnten Herausforderungen besser umgehen. Gerade dem Datenwachstum können Anwender mit den neuen Datenbanken effektiver begegnen. NoSQL ermöglicht eine Skalierbarkeit durch Scale-out - also durch das Hinzufügen von Servern. So lassen sich auch große Datenmengen relativ günstig verwalten. Zur Ausfallsicherheit können die Daten auf mehrere Server repliziert werden. Das ermöglicht eine hohe Verfügbarkeit des Systems, auch wenn die einzelnen Server für sich genommen keine besonders hohe Verfügbarkeit bieten.

Dadurch ergeben sich aber auch Einschränkungen: Ein einzelner Server muss in der Lage sein, eine Anfrage zu bearbeiten, ohne dabei mit anderen Servern zu kommunizieren. Sonst wäre eine globale Koordinierung notwendig, die den Durchsatz beschränkt und dem Scale-out entgegensteht. Im relationalen Modell werden beispielsweise der Kunde und seine Adresse in zwei Tabellen gespeichert. Eine Anfrage nach einem Kunden und seiner Adresse kann durch die Kombination der Daten aus den beiden Tabellen erfolgen.

Bei einer NoSQL-Datenbank ist diese Lösung nicht sinnvoll: Wenn ein neuer Kunde mit einer neuen Adresse eingefügt werden soll, müssten die Server mit den beiden Einträgen koordiniert werden. Das ist komplex. Sind die Daten dann noch auf mehreren Servern repliziert, ist es aufwendig, die Konsistenz auf allen Replikas zu garantieren. Eine Lösung ist, die Änderung in zwei Anfragen aufzuteilen und die Daten weiterhin getrennt zu speichern. Dann ist das Problem der Konsistenz in die Anwendung verlagert. Die Alternative wäre, die Daten zusammen in einer Struktur zu speichern. So können beide zusammen gespeichert werden, und eine Koordinierung der Server ist nicht notwendig.

Neben der Skalierbarkeit ist ein weiterer Vorteil von NoSQL, dass sich auch andere Datenstrukturen effizient bearbeiten lassen. In dokumentenorientierten Datenbanken lassen sich auch wenig strukturierte Daten speichern. Das ist besonders bei komplexen Datenstrukturen von Vorteil. In Graphendatenbanken können vor allem Graphen gespeichert werden, die sich mit dem relationalen Modell nur schwer bearbeiten lassen. Aber auch für Datenstrukturen wie Produktkataloge, in denen viele unterschiedliche Datensätze gespeichert werden, sind NoSQL-Datenbanken besser geeignet als relationale Datenbanken.

Zukunft des relationalen Modells

Relationale Datenbanken haben aber natürlich auch ihre Stärken. Sie unterstützen Transaktionen, die auch mehrere Tabellen und Datensätze umfassen können. Wie erwähnt, gehen NoSQL-Lösungen in diesem Bereich Kompromisse ein, die vor allem der Skalierbarkeit zugutekommen. Außerdem sind relationale Datenbanken dafür optimiert, Daten zu verwalten, die gut in Tabellen passen. Zum Beispiel sind Umsatzdaten oder Buchhaltung dort gut aufgehoben. Zudem gibt es für relationale Datenbanken eine große Auswahl an ausgereiften Reporting-Werkzeugen. Geht es also um die Verwaltung von eher einfachen Datenstrukturen, bei denen auch Transaktionen oder Reports benötigt werden, können relationale Datenbanken ihre Vorteile ausspielen.

Fazit: Polyglotte Persistenz ist die Zukunft

Die Zukunft gehört nicht der Ablösung von relationalen Datenbanken, sondern ihrer Ergänzung. Aus diesem Grund steht NoSQL auch für "Not only SQL", also "nicht nur SQL" - und nicht etwa für eine vollständige Abkehr von SQL. Dadurch wird kein Anspruch auf ein Ersetzen, sondern auf ein Ergänzen von relationalen Datenbanken erhoben. Für Anforderungen, die durch relationale Datenbanken abgedeckt werden können, ist eine Ablösung nicht sinnvoll. Aber in Bereichen, in denen die flexiblen Datenmodelle und das einfache Scale-up von Vorteil sind, sollten Anwender NoSQL-Datenbanken nutzen.

Diese Idee wird "polyglotte Persistenz" genannt. Der Ansatz trägt der größeren Auswahl an Technologien Rechnung und plädiert für eine Nutzung des richtigen Datenbankmodells nach dem jeweiligen Kontext. Also können die komplexen Datenstrukturen eines Produktkatalogs mit einer dokumentenorientierten NoSQL-Datenbank gespeichert werden, während die Umsätze in einer relationalen Datenbank landen und dort für Reports verfügbar sind. Einfache Daten für die Website können dann in einem Key-Value-Store hinterlegt werden.

Durch das Datenwachstum sind auch genügend Daten für alle da - relationale Datenbanken alleine werden dieser Datenflut kaum Herr werden. Und für die neuen gro-ßen Datenmengen bieten sich dann NoSQL-Lösungen an. Auch interessant: Die meisten NoSQL-Lösungen sind Open-Source-Projekte, so dass sie auch bei den Lizenzkosten besser abschneiden als die meist kommerziellen relationalen Datenbanken. (ba)