Kaum etwas verändert sich so rasant wie das Internet, und in kaum einem Bereich sind Entwicklungen so schnell überholt wie im modernen World Wide Web. Für Probleme, die man vor kurzem noch gar nicht kannte, bedarf es plötzlich dringender Lösungen, weil altbewährte Konzepte versagen und das Wachstum nicht gebremst werden soll. In den letzten Jahren war es vor allem das explodierende Datenvolumen großer Seiten wie Amazon, Google und Facebook, das die seit Jahrzehnten eingesetzten Datenbankmodelle an ihre Grenzen brachte und teilweise überrumpelte. Mit NoSQL-Datenbanken wie Apache CouchDB ist man dem Problem riesiger Datenmengen schließlich Herr geworden. Dieser Artikel soll eine kurze Einführung in die Ideen und Konzepte einer solchen Datenbank geben.

Hört man den Begriff NoSQL zum ersten Mal, denkt man fast automatisch an ein lautes und ablehnendes "Nein!" zu bisherigen SQL-basierten Datenbanken wie MySQL und anderen. Das ist aber so nicht ganz richtig, denn hinter dem Begriff verbirgt sich vielmehr der Slogan "Not Only SQL". Das Motto lautet: Nicht nur SQL kommt als Lösung in Frage.

Die Vorreiter der derzeitigen NoSQL-Bewegung wollen herkömmliche relationale Datenbanken also nicht komplett aus der Welt schaffen, sondern vielmehr eine im Einzelfall bessere Alternative bieten. Denn eines ist klar: Auch NoSQL-Datenbanken sind keine Rundum-sorglos-Pakete, sondern haben Vor- und Nachteile, die man je nach Projekt abwägen muss.

Nun wollen wir aber endlich konkret werden und eine Frage klären, die der Ausgangspunkt unserer Reise in die Welt von NoSQL sein wird:

Mit welchen Nachteilen haben herkömmliche Lösungen zu kämpfen?

Spricht man von "herkömmlichen Lösungen", meint man zumeist die vom britischen Mathematiker Edgar F. Codd im letzten Jahrhundert entwickelten relationalen Datenbanken. Was kompliziert klingt, ist nichts anderes als das elektronische Pendant einer Karteikarte.

In Tabellen, die üblicherweise aus mehreren Zeilen und Spalten bestehen, werden Werte gespeichert und in der jeweiligen Datenbank hinterlegt. Die Spalten bieten Platz für Attribute wie "Vorname" und in den Zeilen werden diese dann mit konkreten Werten gefüllt. Aussehen könnte das beispielsweise wie folgt:

Dieser Ansatz hat jedoch einen Haken: Das Schema muss von Anfang an klar sein. Es muss also beim Anlegen einer Tabelle bereits festgelegt werden, wie viele und welche Spalten es geben wird. Wird eine Zahl gespeichert? Soll es eine Zeichenkette sein? Gibt es eine maximale Länge der Zahl bzw. Zeichenkette? Oder verweist die Spalte womöglich auf eine weitere Tabelle?

Solche und ähnliche Fragen mögen in einem einfachen Karteikartenbeispiel noch schnell zu lösen sein, in komplexeren Projekten kann dieser starre Ansatz jedoch ebenso schnell in eine Sackgasse führen. Häufig lassen sich Millionen unterschiedlicher Datensätze nicht in ein einziges starres Schema zwängen.

Doch das ist nicht das einzige Problem, mit dem relationale Datenbanken zu kämpfen haben. Viel schwerer wiegt der Performance-Verlust, der bei vertikal skalierenden Datenbanken wie MySQL unweigerlich eintritt, je "länger" die Tabellen werden.

Zum Vergleich: Sammeln sich in einer MySQL-Datenbank mehr als 50 GB Daten an, liegt die durchschnittliche Schreib- und Lesegeschwindigkeit nur noch bei ca. 300 ms. Das ist eine durchaus spürbare Verzögerung. Bei der gleichen Datenmenge braucht die von Facebook entwickelte NoSQL-Datenbank Cassandra nur wenige Millisekunden.

Mit dieser Erkenntnis der Facebook-Entwickler, die ihre Datenbank mittlerweile an die Apache Software Foundation zur freien Weiterentwicklung übergeben haben, wollen wir uns nun den Vorteilen der NoSQL-Technologie widmen.

Welche Vorteile bieten NoSQL-Datenbanken?

Einer der größten Vorteile einer NoSQL-Datenbank wie Apache Cassandra, Apache CouchDB oder einer der vielen anderen spezialisierten Lösungen liegt in ihrer schnellen und kostengünstigen Erweiterbarkeit – Skalierung genannt.

Während relationale Datenbanken üblicherweise vertikal skalieren – also eine Erweiterung zumeist das Aufrüsten des Server-Systems erzwingt –, lassen sich Datenbanken wie CouchDB horizontal erweitern. Statt den einen zentralen Server kontinuierlich mit immer mehr teurem Speicher aufzurüsten, werden einfach weitere Server hinzugefügt und die Daten auf die Systeme verteilt. Dieser Ansatz spart nicht nur Kosten, sondern ist auch enorm flexibel.

In diesem Zusammenhang ergibt sich jedoch auch eine Herausforderung, der sich verteilte Systeme seit jeher stellen müssen: Wird die Anwendung auf mehrere Rechner verteilt, kann es zu Verzögerungen beim Lesen und Schreiben kommen. Oft bewegen sich diese nur im Bereich weniger Millisekunden, aber die Frage bleibt: Was tun, wenn Änderungen vorgenommen wurden, aber noch nicht alle Rechner im Cluster darüber "informiert" sind? Warten oder weitermachen?

Bei solchen und ähnlichen Problemen antworten NoSQL-Befürworter augenblicklich mit "weitermachen" und propagieren ein Modell mit dem wohlklingenden Namen BASE (Basically Available, Soft state, Eventual consistency). Dahinter steckt die Überzeugung, dass schnelle Verfügbarkeit und flexible Skalierung den höchsten Stellenwert genießen sollen. Das Risiko, dass Daten für kurze Zeit nicht konsistent sind – quasi hinterherhinken –, wird ganz bewusst in Kauf genommen.

Neben der kostengünstigen Erweiterbarkeit und der enorm schnellen Verfügbarkeit der Daten können NoSQL-Datenbanken deutlich besser mit denen von Nutzern generierten Inhalten des Web 2.0 umgehen. Weil sie bewusst auf starre Typenbeschränkungen und Schemata beim Speichern der Datensätze verzichten, werden Lösungen wie Cassandra oder CouchDB mit jeder Überraschung fertig.

So setzt etwa Apache CouchDB beim Speichern der Daten auf die JavaScript Object Notation (JSON), die vor allem durch schlankes Design und einfache Lesbarkeit überzeugt. Der Datensatz unseres obigen Beispiels würde in JSON schlicht so aussehen:

{
     "Vorname": "Max",
     "Nachname": "Mustermann"
}

{
     "Vorname": "Erika",
     "Nachname": "Musterfrau"
}

Hätte "Erika" nun aber überraschenderweise noch einen Zwischennamen, so könnte man ihren Datensatz einfach um diesen erweitern, ohne dass diese Änderung den Datensatz von "Max" in irgendeiner Form tangiert.

Welche NoSQL-Datenbanken gibt es und wo liegen die Unterschiede?

Während herkömmliche SQL-Datenbanken bereits seit langem verfügbar sind und einige im Laufe der Zeit besondere Verbreitung und Beliebtheit erfahren haben, ist NoSQL noch immer ein Sammelbegriff für mehrere unterschiedliche, relativ junge Datenbanken.

Gemeinsam haben sie vor allem das Ziel der leichten Erweiterbarkeit, die Ablehnung starrer Strukturen zum Speichern von Daten und den Verzicht auf die am weitesten verbreitete Datenbanksprache SQL (Structured Query Language). Ansonsten hat jedoch jede NoSQL-Datenbank spezifische Eigenschaften und ist für einen ganz bestimmten Zweck optimiert worden.

• Graphendatenbanken wie Neo4j legen den Schwerpunkt auf die Beziehungen von Personen oder Dingen untereinander. Sie können Eigenschaften nicht nur in den Knoten – vergleichbar mit einer Tabelle – speichern, sondern auch die Verbindungen zwischen zwei Knoten (Kanten) sind von Bedeutung.
• Dokumentorientierte Datenbanken wie Apache CouchDB oder auch Lotus Notes speichern ihre Daten in einzelnen – voneinander völlig unabhängigen – Dokumenten ab. Besonders das schlanke JSON-Format wird gerne zum Strukturieren der Daten genutzt, da es auch für Menschen leicht zu lesen ist.
• Key-Value-Datenbanken bilden die "Basislösung" unter den diversen NoSQL-Datenbanken. Das erklärte Ziel ist die größtmögliche Vereinfachung der Daten auf einzelne Schlüssel plus den zugehörigen Werten. Der bekannteste Vertreter dieses Typs ist Googles NoSQL-Datenbank BigTable, die mit Datenmengen im Petabyte-Bereich umgehen können muss, die über tausende Rechner verteilt sind.

Für eine umfangreiche Liste aller zumindest einigermaßen bekannten und verbreiteten NoSQL-Datenbanken empfiehlt sich ein Blick auf die Webseite NoSQL-Database.org.

Fazit

Lange Zeit schien die Vormachtstellung der relationalen Datenbanken, wie sie der Brite Edgar F. Codd. bereits vor Jahrzehnten erdachte, unantastbar und SQL-Datenbanken galten als Lösung für alle bekannten Probleme. Doch das hat sich geändert. Unter dem Schlagwort NoSQL sammeln sich inzwischen Dutzende alternativer und teils hochspezialisierter Datenbanklösungen, zu deren gemeinsamen Zielen das flexible Speichern verschiedenster Datensätze, die unkomplizierte Erweiterbarkeit durch horizontale Skalierung und die Verteilung extrem großer Datenmengen auf Hunderte oder gar Tausende Rechner zählen.

All das spart nicht nur Zeit und Kosten, sondern ist auch deutlich sicherer, da Daten zumeist auf mehreren Maschinen gleichzeitig liegen (Redundanz) und ein Server-Ausfall mit einhergehendem Datenverlust nur begrenzten Schaden anrichten kann.

Ein Wermutstropfen bleibt jedoch: Wer eine bereits laufende Anwendung für den Betrieb mit einer NoSQL-Datenbank umbauen will, wird viel zusätzliche Zeit investieren müssen. Wer sich jedoch noch im Planungsstadium befindet und einen Weg sucht, für die Zukunft gerüstet zu sein, sollte sich intensiv mit den Möglichkeiten befassen, die NoSQL bietet.

Weiterführende Informationen

Ihr neues Projekt soll mit modernsten Technologien entwickelt werden? Sie möchten ein bestehendes System erweitern oder eine Software-Plattform migrieren? Sie benötigen Schnittstellen zwischen Anwendungen im Unternehmen? //SEIBERT/MEDIA ist der richtige Partner. Wir legen größten Wert auf iterative Erweiterbarkeit, Performanz, Skalierbarkeit, Testbarkeit und Plattformunabhängigkeit und schaffen so individuelle High-End-Software-Lösungen, die sich auch im Nachhinein flexibel ausbauen und verändern lassen. Bitte sprechen Sie uns unverbindlich an!

Mitwirkender an Konzeption und Umsetzung: Benjamin Borbe

Mehr über die Creative-Commons-Lizenz erfahren