NoSQL Datenbanken

Fast jede größere Anwendung muss Daten speichern und wieder lesen. Doch viele Anwendungsfälle unterscheiden sich stark im Format der Daten und damit auch bei den Anforderungen an Performance und Datenkonsistenz. Lange Zeit waren relationale Datenbanksysteme (RDBS) die erste Wahl für neue Projekte. Dies hat mehrere Gründe:

• SQL ist eine Abfragesprache, die so ziemlich jede/r angehende Softwareentwickler/in im Informatikstudium lernt und ist daher den meisten vertraut.
• SQL ist mehr oder weniger standardisiert, d.h. die grundlegenden Sprachkonstrukte sind bei allen Anbietern von relationalen Datenbanksystemen gleich.
• Konsistenz
• RDBS gibt es schon sehr lange, daher existiert eine Menge Erfahrung in dem Bereich.

Es gibt aber auch einige Nachteile von RDBS:

• Schwierige Skalierbarkeit: Relationale Datenbanken lassen sich oft nur vertikal gut skalieren, da die Synchronisation zwischen mehreren Instanzen der gleichen Datenbank mit dem strikten Transaktionsmodell von RDBS sehr komplex ist.
• Dynamische Daten, ohne festes Format, sind nicht immer einfach zu behandeln, da relationale Datenbanken in der Regel ein festes Schema für ihre Daten brauchen.
• Sehr stark relationale Daten können je nach Anwendungsfall Performanceprobleme erzeugen. Relationen über Foreign-Keys sind zwar ein gutes Mittel um Datenkonsistenz zu garantieren, aber die Performance leidet stark bei Abfragen, die Daten aus vielen unterschiedlichen Tabellen aggregieren.

Exkurs: Vertikale vs. horizontale Skalierung

Wenn die Last auf einer Anwendung (und damit auch auf den Datenbanksystemen) steigt (z.B. durch viele gleichzeitige Benutzer) möchte der Betreiber meistens sicherstellen, dass es zu keinen Ausfällen kommt. Gerade bei kommerziellen Anwendungen wie Online-Shops ist dies wichtig, da es Umsatzeinbußen zur Folge hat, wenn Benutzer wegen Serverüberlastungen nicht einkaufen können. Man muss also die Kapazität der Systeme erhöhen. Dafür gibt es zwei Möglichkeiten:

• Verbessern der Hardware der Systeme. Mehr Rechenleistung oder mehr Speicher kann das Problem schon lösen (vertikale Skalierung).
• Replizieren der Systeme, sodass sich die Last auf mehrere Systeme aufteilt (horizontale Skalierung).

Grundsätzlich ist vertikale Skalierung einfacher umzusetzen, stößt aber irgendwann an eine Grenze. Die Menge an Rechenleistung und Speicher in einem Computer ist begrenzt (auch wenn diese Grenze mit dem technischen Fortschritt immer weiter steigt). Der Vorteil dieser Skalierungsstrategie ist, dass sie keine direkten Auswirkungen auf die Architektur der Anwendung hat.

Horizontale Skalierung hingegen hat prinzipiell keine solche Grenze, hat aber starke Auswirkungen auf die Gesamtarchitektur des zu skalierenden Systems. Relationale Datenbanken zum Beispiel lassen sich nicht gut horizontal skalieren, da es schwer ist, die Konsistenz der Daten zu garantieren, wenn es mehrere Instanzen der Datenbank gibt.

Alternative NoSQL

Als Alternative zu relationalen Datenbanken haben sogenannte NoSQL Datenbanken in letzter Zeit stark an Popularität gewonnen. Treibende Kräfte waren und sind immer noch sicherlich große Technologieunternehmen, die massive Anforderungen an Skalierung haben, um eine stabile Anwendung für Millionen gleichzeitiger Nutzer bieten zu können.

Hinter dem Namen NoSQL verbergen sich viele verschiedene Datenbankkonzepte. Im folgenden werfen wir einen Blick auf Key-Value Stores, Dokumentendatenbanken, Graphdatenbanken und Wide-Column Stores.

Key-Value Stores

Datenbanken die diesem Typ entsprechen, bestehen im Grunde nur aus einem Mapping von Schlüsseln zu Werten. Granularere Strukturen wie Tabellen gibt es in der Regel nicht. Key-Value-Stores eignen sich für kleinere Datenmengen oder als Cache vor einem anderen Datenbanksystem.

Ein populärer Vertreter dieser Art ist Redis. Redis ist ein in-memory Key-Value-Store. Dies bedeutet, dass alle Daten nach Start der Datenbank komplett im Arbeitsspeicher gehalten werden. Dies führt zu extrem schnellen Zugriffszeiten im Vergleich zu anderen Systemen. Daher wird Redis oft als Cache vor anderen Systemen verwendet, um beispielsweise aufwendige Abfragen zwischenzuspeichern, kann aber auch durch viele verfügbare Plugins als primärer Datenspeicher verwendet werden.

Dokumentendatenbanken

Dieser Typ ist besonders geeignet für Daten, die nicht unbedingt immer die gleiche Struktur haben. Dokumentendatenbanken legen ihre Daten meist im JSON Format ab und benötigen nicht zwingend ein festes Schema. Dokumente können wiederum Subdokumente enthalten, wodurch eine Art Relation abgebildet werden kann. Abfragen werden meist in einer eigenen Abfragesprache verfasst.

Ein populäres Beispiel für eine Dokumentendatenbank ist Elasticsearch. Das Hauptmerkmal von Elasticsearch ist sicherlich die sehr performante und mächtige, eingebaute Suchfunktion, aber das System erfüllt alle Kriterien einer Dokumentendatenbank. Interaktion mit der Datenbank geschieht hier über eine REST-Schnittstelle, wodurch Entwickler keine neue Sprachsyntax lernen müssen. Des weiteren bringt Elasticsearch schon ein komplettes Skalierungskonzept mit, um auch mit extrem großen Datenmengen umgehen zu können.

Exkurs: Clustering und Sharding

Mehrere Elasticsearch Instanzen (Nodes) können in einem Cluster zusammengefasst werden. Damit arbeiten alle Nodes zusammen und teilen sich die Last auf. Um sicherzustellen, dass bei einem Ausfall eines Nodes keine Daten verloren gehen, verwendet Elasticsearch das Konzept von Shards. Damit werden die Daten auf mehrere Nodes repliziert, sodass der gleiche Datenbestand auf mehreren Nodes verfügbar ist. Dies stellt zum einen sicher, dass die Daten ausfallsicher sind, zum anderen kann dies viele Abfragen beschleunigen indem zum Beispiel Anfragen auf mehrere Nodes aufgeteilt werden.

Graphdatenbanken

Es gibt Anwendungsfälle in denen die Relationen zwischen Daten genauso wichtig sind wie die Daten selbst. Beispielsweise soziale Netzwerke, in denen die Beziehungen zwischen den Benutzern stark im Vordergrund stehen. Relationale Datenbanken modellieren solche Beziehungen als normale Felder, die eine spezielle Bedeutung haben (Foreign Keys). In Graphdatenbanken hingegen verhalten sich Relationen mehr wie eigene Objekte und können auch eigene Felder haben. Dadurch lassen sich auch sehr komplexe Modelle mit vergleichsweise einfachen Abfragen navigieren. Die Abfragesprachen von Graphdatenbanken unterscheiden sich daher etwas stärker von den anderen Datenbanktypen, da diese besondere Rolle von Relationen ein etwas anderes Sprachkonzept erfordert.

Ein populäres Beispiel für eine Graphdatenbank ist Neo4J mit der Abfragesprache Cypher. Cypher wird teilweise auch von anderen Graphdatenbanken verwendet, sodass Entwickler sich beim Evaluieren von Graphdatenbanken mehr auf die eigentlichen Konzepte konzentrieren können, als auf die Syntax der Sprache.

Wide-Column Stores

Dieser Datenbanktyp ist von allen anderen hier genannten NoSQL Datenbanken am ähnlichsten zu relationalen Datenbanken. Daten werden ebenfalls in Tabellen abgespeichert, allerdings mit dem Unterschied, dass nicht jede Zeile einer Tabelle dieselben Spalten haben muss. Sie sind damit gewissermaßen eine Mischung aus relationalen und Dokumentendatenbanken.

Relationale Datenbanken arbeiten oft zeilenorientiert, d.h. die Systeme sind darauf ausgelegt, dass eine ganze Zeile gelesen oder geschrieben wird. Die Daten werden daher auch eher zeilenweise gespeichert, wodurch der Zugriff auf ganze Zeilen relativ schnell ist. Im Kontext von klassischen Businessanwendungen mit vielen Formularen, die oft eine Zeile einer Tabelle repräsentieren, ergibt dies auch viel Sinn.
Wide-Column Stores hingegen arbeiten eher spaltenorientiert, das heißt die Daten einer Tabelle werden spaltenweise abgelegt. Zugriffe auf die Werte aller Spalten einer Tabelle sind daher sehr schnell, während das Lesen oder Schreiben von ganzen Zeilen etwas weniger performant ist. Sie sind damit gut geeignet für Anwendungsfälle in denen zum Beispiel viele Auswertungen über einzelne Kennwerte von Objekten gemacht werden.

Auswahl des passenden Datenbanksystems

Um die richtige Entscheidung für die zu verwendende Datenbank in einem Projekt zu treffen ist es essentiell, einen groben Überblick über die Anwendungsfälle und die Art der anfallenden Daten zu haben. Es kann auch durchaus Sinn ergeben, eine Art Hybridmodell zu verwenden, in dem strukturierte Daten in einer klassischen relationalen Datenbank und eher dynamische Massendaten in einer Dokumentendatenbank verwaltet werden. Die Garantien bezüglich Datenkonsistenz, die relationale Datenbanken mit ihrem transaktionsbasierten Konzepten bieten, können die anderen Nachteile durchaus aufwiegen. Am Ende kommt es immer auf den speziellen Anwendungsfall und die Anforderungen an die Performance an.

 

 

---

www.eckcellent-it.de

weitere Artikel vom Autor: GraphQL: Das bessere REST?; Onboarding mit Hindernissen? oder „Entern gut, ALLES gut“; Neuronale Netzwerke – Was steckt dahinter?, ECMAScript 2015