NoSQL-Datenbanken: Der Stand der Dinge
Daten anders speichern
NoSQL-Datenbanken haben ihren Exotenstatus längst verloren und sind in unterschiedlichsten Anwendungsszenarien im Einsatz. Angesichts der Vielfalt an Ansätzen, Projekten und Produkten stellt sich jedoch schnell die Frage, welche Datenbank wann die richtige ist.
Sieben Jahre ist es her, da fand parallel zur ApacheCon North America in Kalifornien eine Veranstaltung mit dem Namen „NoSQL Meetup“ statt. Das spätere Momentum des Namens NoSQL war bei diesem Treffen noch nicht abzusehen – vielmehr ging es darum, die Vorträge aller Referenten unter einen Hut zu bekommen.
So verwundert es denn auch nicht, dass heutzutage vielfältige Datenspeicherlösungen unter dem Label NoSQL anzutreffen sind. Selbst klassische relationale Datenbanken wie PostgreSQL können inzwischen mit einer NoSQL-Schnittstelle aufwarten. Doch bei soviel Auswahl stellt sich die Frage, wann welche Lösung zum Speichern der anfallenden Daten taugt.
Auch wenn die Verlockung groß ist, dem jeweils aktuellen Hype zu folgen, sollte man prinzipiell den konkreten Anwendungsfall ansehen:
– Sind große Datenmengen zu speichern, die die auf einem Rechner verfügbare Kapazität sprengen, muss man sich unter den verteilten Datenbanken umschauen. Oft bringen diese die für die Sicherheit der Daten notwendige Redundanz in Form von Replikation bereits mit.
– Entsprechen die Zugriffsmuster einem simplen Key-Value-Muster, bietet sich ein Key-Value-Store an.
– Handelt es sich bei den zu speichernden Daten um in sich abgeschlossene Datensätze (sogenannte Dokumente), kommen – wie der Name schon vermuten lässt – Document Stores in Frage. Ihre Stärke liegt im effizienten Umgang mit optionalen Attributen je Dokument.
– Besteht die Notwendigkeit, neben einfachen Abfragen auch Volltextsuchen auszuführen, sind Volltextsuchmaschinen wie Solr oder Elasticsearch das Werkzeug der Wahl.
– Für Daten, die sich am besten als Graphen darstellen lassen, gibt es spezielle Graphdatenbanken.
Als generelle Richtschnur gilt: Wenn man sich noch fragt, warum man in einer Anwendung lieber eine NoSQL-Datenbank nutzen sollte statt des gewohnten relationalen Datenbankmanagementsystems, ist es unwahrscheinlich, dass man tatsächlich eine NoSQL-Datenbank (oder eine Kombination von mehreren) einsetzen muss.
Kriterien zur Auswahl einer NoSQL-Datenbank
Steht die Frage an, zu welcher NoSQL-Datenbank man wechselt, gilt es unterschiedliche Kriterien zur Entscheidung heranzuziehen: Welches Wissen ist bereits im Entwicklungsteam vorhanden und wie kostenintensiv ist es, bestehende Wissenslücken zu schließen? Projekte mit guter Dokumentation sind sicherlich schlecht dokumentierten Lösungen vorzuziehen. Aber auch die Verfügbarkeit von Trainingsmodulen kann ein Kriterium sein.
Auch der Aufwand zum Betreiben der ausgewählten Datenbank muss betrachtet werden: Wie fehlertolerant ist die Software? Wie einfach lässt sie sich in die betriebsinternen Überwachungssysteme einbinden? Wie viel zusätzliche Software ist nötig, damit die Applikation wirklich von den Stärken der gewählten Datenbank profitiert? Kann das Projekt mit den erwarteten Datenmengen mithalten? Skalierbarkeit muss hier nicht unbedingt ausschließlich in Petabytegrößen gedacht werden: Eine Datenbank, die das Projekt mit wenig Aufwand von den kleinen Anfängen über wachsende Anforderungen begleitet, kann durchaus einer hoch skalierbaren Lösung überlegen sein.
Beim Thema Performance werden sich umfangreiche Tests nicht umgehen lassen: Zu sehr hängt die Leistung von der Umgebung (Festplatte vs. SSD, virtualisiert vs. bare metal und so weiter) und vom individuellen Anwendungsfall ab. Je nach Anforderungen muss man sich Schreib- und/oder Lesegeschwindigkeit anschauen. Wichtig ist auch die Frage, wie schnell geschriebene Daten tatsächlich zum Lesen zur Verfügung stehen. Typische Abfragen sollten getestet und gegebenenfalls optimiert werden. Oft lohnt bei der Optimierung von Anfragen ein Blick auf das verwendete Datenschema.
Im Hinblick auf Interoperabilität stellt die zur Verfügung gestellte Schnittstelle ein wichtiges Entscheidungskriterium dar. Viele der heute unter dem Begriff NoSQL bekannten Datenbanken sind längst nicht mehr NoSQL im Sinne von „kein SQL“, sondern eher als „Not only SQL“ zu verstehen. Allerdings steckt der Teufel oft im Detail der genauen Implementierung des unterstützen Sets an SQL-Befehlen.
Verteilt und spaltenorientiert: Big-Data-Datenbanken
Im Folgenden sollen die bereits kurz angerissenen Typen von NoSQL-Datenbanken erläutert, mit konkreter Software unterfüttert und hinsichtlich ihrer Stärken und Schwächen beleuchtet werden. Stimmen aus einigen der angesprochenen Projekte wurden für diesen Artikel in Form von Interviews eingefangen. Die kompletten Fragen und gegebenen Antworten finden Sie über „Alle Links“.
Ziel klassischer Datenbanken für Big Data ist die redundante Speicherung von großen (genauer gesagt: Petabyte-großen) Datenmengen auf normaler Standard-Hardware. Die bekanntesten Kandidaten sind die spaltenorientierten Datenbanken Apache Cassandra, HBase, Accumulo und SAP HANA.