Was ist NoSQL überhaupt?

26. Juli 2012Eberhard Wolff

Die Datenbank-Welt steht vor einer fundamentalen Änderung – ausgelöst durch die NoSQL-Datenbanken. Aber warum sind neue Technologien überhaupt notwendig? Dafür gibt es verschiedene Gründe:

  • Die Datenmenge nimmt ständig zu – und zwar überproportional. Das stellt neue Herausforderungen an Datenbanken. Und wenn die Datenmenge so stark wächst, gibt es genügend Daten für neue Technologien – selbst wenn bereits etablierte Datenbanken nicht abgelöst werden.
  • Die Daten sind zunehmend weniger strukturiert. Während früher leicht strukturierbare Daten wie Adressen oder Finanzen verwaltet worden sind, werden nun Daten aus Social Media, aber auch usergenerierte Inhalte oder Web-Seiten interessant.
  • Gleichzeitig stehen gerade soziale Netzwerke oder das World Wide Web für Strukturen, in denen Beziehungen der Daten untereinander wichtiger werden als die Daten selber.
  • Durch die Cloud muss sich Datenhaltung ebenfalls ändern: Lösungen mit vielen, wenig leistungsfähigen Servern können in der Cloud besonders gut betrieben werden. Außerdem muss in der Cloud mit dem Ausfall einzelner Server gerechnet werden – ein Datenverlust ist dann aber natürlich nicht akzeptabel. Auch außerhalb der Cloud können so Datenbanken mit einfachen Servern statt mit hochverfügbaren und hochskalierten Servern betrieben werden, was kostengünstiger ist.

NoSQL Technologien
Keine Technologie kann diese Herausforderungen alle gleichzeitig und gleich gut lösen. Daher steht NoSQL auch nicht für einen bestimmten Ansatz, sondern wird mit „Not only SQL“, also „nicht nur SQL“ übersetzt. Es geht also darum, das relationale Modell durch verschiedene andere Technologien zu ergänzen. Das kann mit ganz unterschiedlichen Zielsetzungen erfolgen. Daher gibt es auch verschieden NoSQL-Ansätze:

  • Key/Value-Stores speichern unter einem Schlüssel einen Wert. Anfragen oder Joins sind nicht möglich. Dieser Ansatz ist nicht sehr mächtig, aber in einigen Situationen ausreichend. Key/Value-Stores erreichen dafür eine sehr gute Skalierbarkeit. Beispiele für diese Technologie sind Redis und Riak. Aber nur einfache Werte abzulegen schränkt die Modellierung natürlich ein.
  • Die Limitierungen des Key/Value-Modells haben zum Wide-Column-Modell geführt. Dabei wird unter einem Schlüssel eine Sammlung von Spalten verwaltet. Jeder Datensatz kann dabei zusätzliche Spalten haben. Beispiele für diesen Ansatz sind Apache Cassandra und Apache HBase.
  • Dokumentorientierte Datenbanken speichern Dokumente – oft als JSON (JavaScript Object Notation), so dass sie gerade für JavaScript-Web-Frontends gleich mundgerecht serviert werden können. Beispiele sind CouchDB und MongoDB.
  • Schließlich bieten Graphendatenbanken Graphen mit Knoten und Beziehungen sowie Eigenschaften an. Ein Beispiel ist neo4j.

Welche Vorteile haben diese Ansätze nun? Bis auf Graphendatenbanken können alle Ansätze die Daten auf mehrere Server verteilen. Beim Zugriff über einen Schlüssel kann der zuständige Server ermittelt werden, der die Anfrage dann ausführt. Dadurch können die Datenbanken wesentlich besser skalieren und größere Datenmengen verwalten.

Ebenso kann eine hohe Datensicherheit erreicht werden – selbst wenn die genutzte Hardware nicht besonders ausfallsicher ist. Dazu werden die Daten redundant gespeichert. Wenn ein Server ausfällt, sind dann immer noch Replikate übrig, so dass Anfragen weiterhin beantwortet werden können. Dadurch laufen die Lösungen besser in der Cloud und es sind keine hochverfügbaren Datenbankserver mehr notwendig.

Ansätze wie Wide-Column oder dokumentenorientierte Datenbanken erlauben einen guten Umgang mit semistrukturierten Daten, da nicht mehr alle Datensätze identisch strukturiert sein müssen. Ebenso ist es möglich, die Datenbanken immer noch nach bestimmten Datensätzen zu durchsuchen.

Schließlich sind graphenorientierte Datenbanken gut dazu geeignet, Beziehungen zu modellieren.

Ein Beispiel
Aufgrund der unterschiedlichen Stärken können unterschiedliche NoSQL-Datenbanken in unterschiedlichen Szenarien genutzt werden. Nehmen wir als Beispiel eine E-Commerce-Anwendung:

  • Für die Finanzdaten wird eine relationale Datenbank genutzt. Die gute Unterstützung von Transaktionen ist in diesem Kontext hilfreich. Außerdem können bei relationalen Datenbanken einfach Reports erzeugt werden. Und die Daten können außerdem recht leicht in die relationalen Tabellen aufgeteilt werden.
  • Der Produktkatalog kann mit einer dokumentenorientierten Datenbank implementiert werden. Gerade Produkte können sehr viele unterschiedliche Eigenschaften haben. In solchen Situation ist die Flexibilität einer dokumentenorientierten Datenbank hilfreich. Außerdem können dokumentenorientierte Datenbanken auch komplexe Anfragen bearbeiten, wie sie für einen Produktkatalog notwendig sind.
  • Für die Ablage des Einkaufswagens kommt ein Key/Value-Store zum Einsatz. Er skaliert gut. Die Daten müssen nicht weiter verarbeitet werden, sondern nur gespeichert werden, so dass die Einschränkungen des Key/Value-Stores akzeptiert werden können.
  • Für Empfehlungen wird eine Graphendatenbank genutzt: Sie kann für jeden Kunden die Bekannten ermitteln und deren Käufe und aus diesem Graphen dann Empfehlungen ableiten.

NoSQL zielt also nicht auf eine Ablösung relationaler Datenbanken, sondern auf eine Ergänzung. Architekten können nun also aus einer größeren Menge von Technologien die optimale Lösung für das jeweilige Projekt wählen. Dokumentenorientierte Datenbanken sind dabei oft eine sehr gute Option, weil sie auch mit komplexen Datenstrukturen umgehen können und gleichzeitig gut skalieren.

Attraktiv sind NoSQL-Datenbanken übrigens auch, weil praktisch alle Open-Source-Projekte sind, zu denen aber auch professioneller Support angeboten wird, wenn das notwendig ist. Daher sind NoSQL-Lösungen meistens kosteneffizient.

Fazit
Mit NoSQL erweitert sich das Datenbankspektrum. Für viele Probleme stehen nun interessante Alternativen bereit. Daher sollten Architekten und Entwickler in den Projekten entscheiden, ob NoSQL-Datenbanken im aktuellen Kontext einen Vorteil haben und welche Technologie sinnvollerweise eingesetzt werden kann. Dadurch ergeben sich effizientere und oft auch einfacher zu implementierende Lösungen.

Eberhard Wolff Eberhard Wolff ist Architecture & Technology Manager bei adesso.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: