NoSQL-Datenbanken: Mehr als nur SQL
NoSQL-Datenbanken stehen für einen Paradigmenwechsel in der Datenbanktechnologie. Wie ist es dazu gekommen, dass sich NoSQL-Datenbanken als Alternative zu herkömmlichen relationalen Datenbanken etabliert haben? Die Suche nach Alternativen zu den traditionellen SQL-Datenbanken wurde durch zwei Trends bestimmt: das kontinuierliche Datenwachstum und das Bestreben, mehr Daten in kürzerer Zeit zu verarbeiten. Dafür bieten NoSQL-Datenbanken Möglichkeiten zur Verteilung von Daten und Funktionen in einem Netzwerk. So setzen bereits viele Unternehmen NoSQL-Datenbanken ein, auch wenn diese noch nicht die Vormachtstellung der relationalen Datenbanken in Frage stellen. Die Frage, ob relationale Datenbanksysteme vielleicht doch nicht alles leisten können, was in der Welt von Big Data notwendig ist, soll hier kritisch erörtert werden. Dies liefert die Motivation, sich intensiver mit den Möglichkeiten von NoSQL-Datenbanksystemen auseinanderzusetzen.
Entwicklung
Der Begriff NoSQL im Sinne von "No SQL" tauchte das erste Mal auf im Jahre 1998 für eine relationale Open-Source-Datenbank, die keine SQL-Zugriffsmöglichkeit bot. Carlo Strozzi, der Entwickler der Datenbank, verband mit dieser Idee kein alternatives Datenmodell, sondern es ging nur um den Verzicht auf SQL als Anfragesprache. Es dauerte ein paar Jahre, bis das Schlagwort NoSQL wieder aufgegriffen wurde. Auf einem Treffen über verteilte strukturierte Datenspeicher im Jahre 2009 gebrauchte Johann Oskarsson den Begriff NOSQL mit der Bedeutung "Not only SQL". Seit Anfang der 2000er Jahre war eine Vielzahl von nicht-relationalen verteilten Datenbanksystemen bzw. Datenspeichersystemen entstanden, die nun unter dem Begriff NoSQL zusammengefasst werden konnten. Hier sind insbesondere die Ansätze Bigtable/MapReduce von Google sowie DynamoDB von Amazon hervorzuheben. Aus diesen Anfängen heraus entwickelte sich eine NoSQL-Bewegung mit dem Ziel, Alternativen zu relationalen Datenbanksystemen zu entwickeln, um die Schwierigkeiten zu überwinden, die bei deren Einsatz entstehen. Insofern steht NoSQL heutzutage für Datenbanksysteme, die Daten ohne die Einschränkungen des Relationenmodells speichern und verarbeiten.
NoSQL hat bei einer großen Zahl von Unternehmen an Attraktivität gewonnen und in den letzten Jahren zahlreiche Projekte hervorgebracht. So sind vor allem namhafte Internetfirmen wie Facebook, Amazon und Google von relationalen Datenbanken als Backend zu nichtrelationalen Datenspeichern gewechselt. Bekannte Beispiele sind Cassandra, Voldemort und Amazon SimpleDB. Cassandra wurde ursprünglich für Facebook entwickelt und später auch von Twitter genutzt. Das Projekt Voldemort wurde entwickelt für den Einsatz im Business-Netzwerk LinkedIn. Amazon entwickelte Cloud-Dienste auf Basis von SimpleDB, einer NoSQL-Datenbank. Die meisten populären NoSQL-Datenbanken haben Ideen umgesetzt, die auf Google Bigtable [1] oder Amazon Dynamo [2] beruhen. NoSQL-Systeme auf der Basis von Bigtable erscheinen meistens unter dem Begriff Wide Column Store (z. B. HBase), wohingegen Dynamo die Entwicklung von Key Value Stores stark beeinflusst hat (z. B. Redis, Voldemort). Andere Projekte folgten anderen Ansätzen wie Graph-Datenbanken oder Dokument-Datenbanken. Insgesamt lässt sich mit Blick auf die Entwicklung der vergangenen Jahre feststellen, dass die großen Internetfirmen oft Vorreiter waren, bevor andere Entwickler diese Ideen übernommen und für neue Anwendungen angepasst haben. Sehr häufig sind diese Systeme als Open-Source-Systeme frei verfügbar bzw. werden als Projekt der Apache Software Foundation weiterentwickelt.
Die Einführung des Cloud-Computing brachte einen weiteren Schub für die Weiterentwicklung von NoSQL-Datenbanken. So eignen sie sich sehr gut für Analyse-Aufgaben im Data Warehousing bzw. sind als Plattform für einen einfachen skalierbaren Storage Service auf der Basis von Schlüsseln und Werten gut geeignet. NoSQL-Datenbanken können aufgrund ihrer hervorragenden Performance- und Skalierbarkeitseigenschaften auch als Cloud-Database-Service zur Verfügung gestellt werden.
Daten
Big Data
Big Data wird zumeist durch 3 V beschrieben: Volume, Velocity und Variety.
- Der Begriff Volume steht für das rasante Datenwachstum, das durch aktuelle technologische Trends noch gefördert wird. Beispielhaft hierfür steht das Internet of Things, welches die digitale und die physische Welt durch ein Netzwerk von Sensoren verbindet. Seit einigen Jahren befinden wir uns bereits im Zettabyte-Zeitalter. Aktuelle Prognosen für das Jahr 2025 gehen von einem weltweit generierten Datenvolumen von 175 Zettabytes (ZB) aus. Dies entspricht 175 Mrd. TB.
- Velocity bezieht sich auf die Verarbeitungsgeschwindigkeit der Daten. Einerseits geht es um möglichst kurze Reaktionszeiten, um auf Ereignisse zu reagieren, die z. B. durch einen Sensor signalisiert werden. Andererseits muss das System einen hohen Datendurchsatz garantieren.
- Variety steht für die Vielfalt der Daten, die gleichermaßen verarbeitet werden müssen. Neben den bekannten relationalen Daten mit einem festen Schema gibt es dabei noch andere Arten von Daten. Dafür wurden verschiedene Kategorien von NoSQL-Datenbanken entwickelt.
Datenmodelle in NoSQL
Abb. 1 zeigt einige Beispiele für alternative Datenmodelle in NoSQL. So können Daten in einem Key Value Store als Schlüssel-Wert-Paare gespeichert werden. Dabei hat ein Wert selbst kein festes Format und kann aus mehreren Attributwerten zusammengesetzt sein. In unserem Beispiel handelt es sich um Daten von Personen mit jeweils unterschiedlichen Merkmalen. Es ist ein sehr schneller Datenzugriff auf den ganzen Wert über den Schlüssel möglich, z. B. mittels Hash-Tabelle. Die Extraktion von bestimmten Informationen ist dann Sache der Anwendung, die den Wert als Ganzes von der Datenbank bezieht.
Daten, die in einem Dokumentformat wie z. B. JSON erfasst sind, können in einem Document Store gespeichert werden. Die Dokumentstruktur ist flexibel, dabei sind Hierarchien möglich. Abfragen nach Daten können einen Suchpfad beinhalten, um gezielt Werte an einer bestimmten Position zu suchen (z. B. die Artikel-Nr. in der n-ten Bestellposition innerhalb einer bestimmten Bestellung).
Wenn man Daten spaltenorientiert in einer Datenbank speichert, spricht man auch von einem Column Store. Dabei stehen alle Werte einer Spalte hintereinander und können somit spaltenweise ausgewertet werden. Auch kann man die Daten vertikal partitionieren, indem man die Spalten in einem Netzwerk unterschiedlichen Serverknoten zuordnet. Dazu können jederzeit weitere Spalten hinzugefügt werden, so dass die Datenstrukturen sehr flexibel sind.
Graph-Datenmodelle erfreuen sich zunehmender Beliebtheit, um vielfältig verknüpfte Daten in einem Graph Store zu speichern, z. B. in sozialen Netzwerken oder bei der Wissensrepräsentation. In unserem Beispiel werden Datenobjekte durch Knoten dargestellt (z. B. Person, Order), die Beziehungen untereinander durch gerichtete Kanten (z. B. creates). Die Abfragen in Graphen lassen sich durch entsprechende Suchmuster auf Knoten und Kanten ausdrücken. Die Suche funktioniert durch Traversierung des Graphen. Dies ermöglicht auch die Umsetzung bekannter Graph-Algorithmen, z. B. die Bestimmung des kürzesten Pfades (Dijkstra-Algorithmus).
In einem Informationssystem sind oft sehr heterogene Daten anzutreffen, so dass mitunter auch eine Kombination mehrerer Datenmodelle sinnvoll ist. Hierfür gibt es sogar eine eigene Kategorie von NoSQL-Systemen, die Multi-Modell-Datenbanken, z. B. ArangoDB [3]. Viele Daten sind heutzutage wenig oder gar nicht strukturiert, z. B. Texte oder Bilder. Auch diese Daten eignen sich sehr gut für die Speicherung in NoSQL-Systemen.
Nicht-funktionale Anforderungen
Performance
Betrachten wir nun nicht-funktionale Anforderungen an ein Datenbanksystem genauer. Dabei fokussieren wir uns auf die Performance (Leistungsfähigkeit), weil diese ein wichtiges Kriterium bei der Entscheidung für eine NoSQL-Datenbank ist. Die Performance ist jedoch nicht statisch, sondern kann sich im Laufe der Zeit verändern. So kann sich in einem Portal die Zahl der gleichzeitig stattfindenden Anfragen verzehnfachen. Ebenso kann im Laufe der Zeit der Umfang der Datenbank größer werden, insbesondere dann, wenn auch historische Daten dort aufbewahrt werden. Selbst wenn man diese Daten aus einem operativen System in ein Data Warehouse extrahiert bzw. archiviert, so könnte dafür der Aufwand in einem analytischen System (OLAP) steigen.
Die Performance einer Datenbank hängt sehr stark von der Nutzung der vorhandenen Systemressourcen ab. Dabei spielen die I/O-Zugriffe auf den Externspeicher (z. B. Plattenlaufwerk) sowie die Nutzung von Memory und Netzwerk eine große Rolle. Um die Performance genauer zu kalkulieren, sind bestimmte Leistungsmerkmale der Hardware notwendig, auf der das DBMS arbeitet. Die Performance von Hardware-Komponenten wie CPUs, Festplatten, Disk Controller oder RAM hat signifikanten Einfluss auf die Leistungsfähigkeit des Datenbanksystems.
Der Workload beschreibt die Gesamtbelastung des DBMS. Er entspricht einer Kombination von Benutzeranfragen, Applikationen, Batch-Jobs, Transaktionen und Systemkommandos, die an das DBMS zu einer bestimmten Zeit gerichtet werden. Der Workload schwankt im Laufe des Jahres, folgt dabei oft bestimmten Mustern, z. B. weniger Anfragen am Wochenende, mehr Berichte am Monatsende. Der Workload hat einen sehr starken Einfluss auf die Performance der Datenbank. Bei möglichst genauer Kenntnis des Workload und der Zeiten der Spitzenbelastung kann man die vorhandenen Systemressourcen am effektivsten planen und den maximal denkbaren Workload bewältigen.
Der Durchsatz eines Systems beschreibt dessen Kapazität zur Verarbeitung von Daten. Der Durchsatz eines DBMS wird in Anfragen pro Sekunden (queries per second, qps), Transaktionen pro Sekunde (transactions per second, tps) oder in der durchschnittlichen Antwortzeit (response time) gemessen. Zwischen dem DBMS und den von ihm verwendeten Systemressourcen besteht eine direkte Abhängigkeit. Um realistische Vorgaben für den Systemdurchsatz zu definieren, ist es daher notwendig, den Durchsatz der zugrundeliegenden Hardwarekomponenten zu kennen, z. B. Bandbreite der Disk, CPU-Geschwindigkeit. Ebenso ist zur Bestimmung des Durchsatzes zu berücksichtigen, inwieweit einzelne Komponenten im Workload konkurrierend auf das System zugreifen (Contention). Dies tritt z. B. auf, wenn mehrere Queries dasselbe Datenobjekt zur gleichen Zeit ändern oder wenn mehrere Workloads um Systemressourcen konkurrieren. Mit wachsender Contention sinkt der Durchsatz des Systems.
Die Antwortzeit (Response Time) ist die Zeit, die der Client vom Absenden einer Anfrage bis zum Eintreffen einer Antwort wahrnimmt. Darin enthalten ist die Verarbeitungszeit für die Anfrage (Service Time) sowie die Verzögerungen bei der Netzwerkkommunikation oder Wartezeiten beim Scheduling der Anfrage. Diese Verzögerungen werden unter dem Begriff Latenz (Latency) zusammengefasst. Die Latenz kennzeichnet allgemein die Dauer der Wartezeit für die Bearbeitung eines Requests und kann auf unterschiedlichen Systemebenen auftreten.
Die Verfügbarkeit (Availability) eines Datenbanksystems beinhaltet die Minimierung der Ausfallzeiten. Dazu werden Daten auf verschiedenen Servern repliziert, die sich in einem Rechnerverbund (Cluster) oder auch an entfernten Orten befinden können. Die Zuverlässigkeit eines Datenbanksystems wird bestimmt durch minimale Ausfallzeiten sowie kurze Antwortzeiten bei Ad-hoc-Zugriffen auf die Daten.
Ein bekannter Ansatz für den Leistungsvergleich von Systemen sowie zur Aufdeckung von Verbesserungspotentialen ist das Benchmarking. Im Umfeld von NoSQL-Systemen sind spezifische Benchmarks vorhanden wie YSCB (Yahoo! Cloud Serving Benchmark) zur Bewertung von Cloud-Anwendungen [4] und LDBC (Linked Data Benchmark Council) für Graphdatenbanken und Daten im Semantic Web.
Skalierbarkeit
Eng verknüpft mit der Performance ist der Begriff der Skalierbarkeit bei wachsenden Anforderungen. Dieses Wachstum lässt sich in drei Dimensionen darstellen:
- Größe des Datenbestandes
- Anzahl der Anfragen
- Größe der Anfragen
Datenbank-Queries können von unterschiedlicher Größe sein. So kann es kurze Schreib-Lese-Transaktionen geben, davon aber Tausende pro Sekunde. Umgekehrt kann es analytische Anfragen geben, die zwar seltener auftreten, dafür aber auf große Datenmengen zugreifen müssen. Skalierbarkeit beinhaltet die Fähigkeit, ein wachsendes Datenvolumen durch verbesserte oder optimierte Ressourcen zur Speicherung und Verarbeitung zu beherrschen.
Ein verwandtes Konzept ist Elastizität, die Fähigkeit eines Systems, auf wechselnde Workloads dynamisch durch Hinzufügen oder Freigabe von Kapazität zu reagieren.
Die Ausführung eines Tasks in einem Workload kann grundsätzlich in zwei Bestandteile unterschieden werden: Ein Teil lässt sich durch eine Verbesserung der Systemressourcen nicht beschleunigen, wohingegen ein anderer Teil mit verbesserten Ressourcen profitieren kann. So gibt es in einem Programm einen sequentiellen Anteil sowie einen parallelisierbaren Anteil. Ein Beispiel: Der Task "Sortieren einer Menge von Datensätzen" besteht aus zwei Abschnitten: 1. Einlesen der Daten (Scan), 2. Sortieren der Daten mit einem bestimmten Algorithmus. In Abschnitt 2 ist sehr viel Potential für Parallelisierung, z. B. bei Nutzung des MergeSort-Algorithmus, bei dem Daten aufgeteilt und später wieder zusammengefügt werden.
Vertikale Skalierung (scale up) führt zu einer Leistungssteigerung des Systems durch das Hinzufügen von Ressourcen zu einem Knoten bzw. Rechner des Systems. Mögliche Maßnahmen wären eine Vergrößerung des RAM oder das Hinzufügen einer CPU. Die vertikale Skalierung erfolgt ausschließlich durch das Aufrüsten der Hardware nach dem sog. KIWI-Prinzip (Kill It With Iron). Positive Effekte können zum Beispiel mit einem größeren Arbeitsspeicher auftreten, so dass mehr Daten gepuffert werden können und die Anzahl der Disk-Zugriffe bei I/O-Operationen abnimmt. Dabei stößt man jedoch irgendwann an eine Grenze, bei der man den Rechner nicht weiter aufrüsten kann, wenn man bereits mit der besten am Markt verfügbaren Hardware arbeitet. Gerade hier setzen NoSQL-Datenbanken an.
Horizontale Skalierung (scale out) bezeichnet die Steigerung der Leistung eines Systems durch das Hinzufügen neuer Rechner bzw. Knoten. Genau diesen Ansatz verfolgen Big-Data-Systeme bzw. NoSQL-Datenbanken, indem sie Aufgaben zerlegen und parallelisieren (Divide and Conquer). Die mögliche Leistungssteigerung ist nicht beschränkt, sondern kann durch beliebig viele neue Knoten immer weiter erhöht werden. Entscheidend ist jedoch der Anteil der in der Software enthaltenen parallelisierbaren Algorithmen.
Ein bekanntes Beispiel für horizontale Skalierung von Datenbanken ist die Replikation von Daten. So könnte auf einem Knoten die eigentliche Datenbank mit Schreibrechten liegen (Master), andere Knoten erhalten Read-Only-Kopien (Slaves). Die auf dem Master protokollierten Änderungen werden später zu den Slaves propagiert. Ein Load Balancer verteilt die Last der ankommenden Lese-Transaktionen unter den Slaves. Mit wachsender Zahl von Knoten können auch mehr Transaktionen parallel bearbeitet werden.
Die quantitative Verbesserung der Leistungsfähigkeit eines Systems kann durch den Skalierungsfaktor (Speedup) beschrieben werden. So lässt sich durch den Speedup der Antwortzeiten ausdrücken, inwieweit die Parallelisierung einer einzelnen Anfrage oder eines Batch-Jobs eine Verkürzung der Antwortzeit des Systems bewirkt. Für den Skalierungsfaktor S mit n Prozessoren gilt:
Netzwerkarchitektur
NoSQL-Datenbanken sind als verteilte Systeme nach dem Prinzip Shared Nothing organisiert. Diese bestehen aus lose gekoppelten unabhängigen Rechnern mit eigenem Extern- und Arbeitsspeicher. Die Knoten eines Shared-Nothing-Systems sind in einem lokalen Netz (z. B. als Rechnercluster) oder ortsverteilt in einem WAN (Wide Area Network) miteinander verbunden. Sie haben somit exklusiven Zugriff auf den Teil der Daten, der dort abgelegt ist. Alle Datenzugriffe, ebenso wie die Abstimmung zwischen den Prozessoren, erfolgen ausschließlich mittels Interprozess-Kommunikation. Somit werden Anfragen bzw. Transaktionen verteilt ausgeführt.
Die Aufteilung des Externspeichers in einem Shared-Nothing-System führt nicht zwangsläufig zur Aufteilung der Daten. Diese könnten auch repliziert an mehreren Rechnern gespeichert werden, um die Kommunikation beim Datenzugriff zu reduzieren und die Fehlertoleranz des Systems zu erhöhen. Dies führt jedoch zu einem größeren Speicherplatzbedarf und erhöht auch den Aufwand für Datenänderungen. Bei den in einem Shared-Nothing-Verbund angeordneten Rechnern kann es sich auch um Multiprozessoren oder virtuelle Maschinen handeln. Der Grundgedanke besteht jedoch darin, dass man keine spezielle Hardware für die einzelnen Knoten benötigt, sondern bei der Auswahl auf ein gutes Preis-Leistungs-Verhältnis achten kann. Genau dies entspricht der Idee von NoSQL-Datenbanksystemen, die verteilt auf Standard-Hardware laufen sollen.
Relational vs. NoSQL
Die mit der Entwicklung von NoSQL-Datenbanken verbundene Abkehr von relationalen Datenbanken hängt mit den Grenzen relationaler Datenbanktechnologie zusammen. Relationale Datenbanken (RDBMS) weisen zudem eine Vielzahl an Merkmalen auf, die jedoch nicht alle von datenintensiven Anwendungen benötigt werden. Dazu diskutieren wir eine relationale Datenbank aus zwei Perspektiven: aus der Perspektive eines Entwicklers, der die Funktionalität des Systems nutzt, sowie aus der Perspektive der Systemarchitektur.
Funktionalität: Modelle und Schnittstellen
SQL: Zwar ist SQL standardisiert, besitzt aber eine sehr große Ausdrucksmächtigkeit zusammen mit prozeduralen Erweiterungen. Damit können benutzerdefinierte Typen, Prozeduren oder Trigger entwickelt werden, die auch auf dem Server gespeichert werden. Das Datenbanksystem wird über seine Funktion als reiner Datenspeicher mit zusätzlicher Intelligenz angereichert. Dies erzeugt womöglich eine unnötige Serverlast und erschwert eine mögliche Portierung zu einem anderen Datenbanksystem bzw. die Anbindung anderer Software. Relationale Datenbanken unterstützen insbesondere auch die Verarbeitung von laufzeitdynamischen Anfragen, die aufgrund der Ausdrucksstärke von SQL recht komplex sein können (Dynamic SQL). In vielen Anwendungen, insbesondere im Web, sind solche dynamischen Queries gar nicht erforderlich. Für das Datenmanagement genügen dort schon einfache CRUD-Operationen (Create-Read-Update-Delete), die weitere Verarbeitung könnte außerhalb der Datenbank stattfinden. Es wäre somit ausreichend, vordefinierte Anfragen bereitzustellen, die dann zur Laufzeit mit aktuellen Parametern (z. B. aus Benutzereingaben) versorgt werden.
Zugriffsschnittstelle: Anfragen werden in SQL deklarativ ausgedrückt, d. h. das Ergebnis wird durch eine Bedingung beschrieben, zusammen mit den darzustellenden Spalten. Im Relationenmodell entspricht dies Selektion und Projektion (Zeilen- und Spaltenauswahl). Diese Anfragen sind sehr gut geeignet für Mengen von gleichartigen Datenobjekten, werden jedoch nicht allen Arten von Daten gerecht. In bestimmten Datenstrukturen, wie z. B. Dokumenten oder Graphen, wäre ein nicht-deklarativer Zugriff günstiger. So wären navigierende Zugriffe, z. B. entlang einer hierarchischen Struktur in einem JSON-Dokument, besser geeignet. Wenn Daten gar nicht (oder kaum) strukturiert sind, braucht man ganz andere Operationen aus dem Information Retrieval, um eine Volltextsuche zu realisieren.
Frameworks: In den letzten Jahren sind zahlreiche Frameworks auf den Markt gekommen, die eine objektorientierte Abstraktion für den Datenbankzugriff bieten und die Nutzung von SQL verbergen. Dazu zählen Persistenz-Frameworks für die objektrelationale Abbildung (Object Relational Mapping, ORM) wie z. B. Hibernate oder LINQ. Auch populäre Web-Frameworks wie Ruby on Rails verbergen die relationale Datenbank im Hintergrund. Auf diesen Trend können NoSQL-Datenbanken reagieren, indem sie Datenstrukturen an ihren Zugriffsschnittstellen anbieten, die näher bei denen der Applikationsprogramme sind, z. B. Schlüssel-Wert-Strukturen (Hash-Tabellen) oder Graphen. Davon profitieren all diejenigen Anwendungen, die primitive Datenstrukturen mit einfacher Zugriffsmöglichkeit und Persistenz bevorzugen. Für diese Anwendungen erscheint die objektrelationale Abbildung eher als ein unnötiger Overhead.
Schemaorientierung: Relationale Datenbanken sind gekennzeichnet durch ein relativ starres Schema, das im Ergebnis des Datenbankentwurfs festgelegt wurde. Die nachträgliche Veränderung des Datenbankschemas kann notwendig werden, wenn eine Spalte erweitert werden soll oder eine neue Spalte einer Tabelle hinzugefügt werden soll. Dieser Vorgang wird als Schema-Evolution bezeichnet und kann für die Datenbank sehr aufwändig werden, wenn durch die Strukturänderung die Daten reorganisiert werden müssen. Die Bindung der Daten an ein Schema schließt immer auch die Prüfung von Integritätsbedingungen ein, die im Schema definiert wurden (z. B. Typprüfungen, Schlüssel-Constraints). Daten ohne Schema entsprechen somit nicht der Philosophie eines RDBMS, sind aber für Big-Data-Anwendungen typisch.
Dünnbesetzte Tabellen: Ein starres Datenbankschema ist auch dann von Nachteil, wenn es viele Spalten in einer Tabelle gibt, die nur dünn besetzt sind, d. h. es stehen überwiegend Nullwerte darin (sparse column). Einmal angelegt, lassen sich diese Spalten in einer Tabelle nachträglich nur schwer löschen, selbst wenn sie fast nicht gebraucht werden. Bei einer zeilenorientierten Speicherung würden solche Spalten unnötig Speicherplatz verbrauchen, was sich auch bei I/O-Operationen nachteilig auswirkt.
Metadaten: Wenn Daten unabhängig von einem Datenbankschema ordnungsgemäß verarbeitet werden sollen, so müssen diese durch Metadaten ausgezeichnet werden. Im einfachsten Fall ist dies der Name einer Eigenschaft (Property), dem ein bestimmter Wert zugeordnet ist. Dies erlaubt eine direkte Verarbeitung, weil keine Metadaten wie Schemainformationen aus anderen Quellen benötigt werden. Somit kann man Daten aus verschiedenen Quellen ohne weiteren Zugriff geeignet interpretieren. In einem RDBMS sind die Metadaten getrennt von den Daten in einem Data Dictionary gespeichert.
Zeitbezug von Daten: Temporale Funktionen zum Umgang mit zeitbehafteten Daten sind zwar mittlerweile in den SQL-Standard eingegangen (SQL:2011), werden aber in herkömmlichen relationalen Datenbanken meist nicht umgesetzt. Die Versionierung von Daten, d. h. die Verwaltung von mehreren Versionen eines Datensatzes mit unterschiedlichen Zeitstempeln, ist aber eine häufig gebrauchte Funktion in Big-Data-Anwendungen. Dies gilt insbesondere dann, wenn Zeitreihen oder Datenströme verarbeitet werden sollen.
Nichtfunktionale Merkmale
Ein RDBMS weist eine Reihe von Merkmalen auf, die im Betrieb kommerzieller Anwendungen nützlich sind, wenn es um die Sicherheit der Daten und einen korrekten Ablauf geht. Allerdings hat dies einen Preis, der bei Anwendungsszenarien, wie sie für das Web typisch sind, oft zu hoch erscheint. Zwei der V-Anforderungen, Volume und Velocity, sind hierbei die entscheidenden Faktoren. Leider ist es nicht möglich, eine relationale Datenbank geeignet zu konfigurieren oder die Systemarchitektur eines RDBMS auf andere Workloads anzupassen. Welche Merkmale sind hierbei kritisch?
Strenge Konsistenz: In relationalen Datenbanken sind Transaktionen mit ACID-Eigenschaften Standard. Dabei steht ACID für Atomicity, Consistency, Isolation und Durability. Das bedeutet, dass am Ende einer Transaktion ein neuer konsistenter Zustand hergestellt wird, der gleichermaßen für alle User sichtbar ist. Dies ist vor allem bei Finanzanwendungen wichtig. Einträge in sozialen Netzwerken durch die Benutzer, z. B. ein neuer Kommentar zu einem Blog-Eintrag oder nur ein Like, erfordern jedoch keine ACID-Transaktionen. Mögliche Lese-Schreib-Konflikte können hier zeitweilig toleriert werden. Die Sicherstellung der Konsistenz erfordert nämlich umfangreiche Mechanismen bei der Synchronisation vieler Transaktionen, die auf die gleichen Daten zugreifen. Das System skaliert dann bei steigenden Benutzerzahlen und wachsender Datenmenge nicht mehr. Hier bieten NoSQL-Datenbanken Einstellmöglichkeiten für abgeschwächte Konsistenz (Eventual Consistency).
Seltene Updates: Ein RDBMS ist durch seine Architektur eher für lesende Anfragen als für Updates geeignet. Insbesondere komplexe Queries können gut optimiert werden. Die Schreib-Performance lässt sich zwar durch eine Vergrößerung des Puffers oder durch Partitionierung der Daten noch verbessern, doch es gibt Grenzen, insbesondere bei Anwendungen auf großen Datenmengen, die sich häufig ändern, z. B. Zähler in Web-Portalen. Alternativ können Datenänderungen nicht durch ein Überschreiben in der Datenbank, sondern durch eine fortlaufende Protokollierung umgesetzt werden.
Geringer Durchsatz: Im Umgang mit großen Mengen an Daten kann das RDBMS an Grenzen stoßen, wenn ein hoher Durchsatz erforderlich ist. Eine solche Situation kann entstehen bei der Verarbeitung von Batch-Jobs in einem nächtlichen Zeitfenster, in dem keine Benutzeranfragen gestellt werden. RDBMS sind eigentlich als zentralisierte Systeme entwickelt worden und daher nicht gut geeignet für das verteilte Datenmanagement in einem Netzwerk von Serverknoten.
Systemarchitektur und Hardware-Entwicklung: In den letzten Jahren hat ein enormes Wachstum bei der Verarbeitungsgeschwindigkeit von Prozessoren, bei den RAM-Größen und Disk-Kapazitäten stattgefunden. Damit sind viele Grenzen für Datenbanken nicht mehr vorhanden. Die Bandbreite zwischen Platte und Arbeitsspeicher hat sich jedoch nur unwesentlich vergrößert. Speicherung und Indexierung von Daten sind immer noch auf die Platte als Speichermedium orientiert. Zwar wurden die führenden RDBMS in den letzten Jahren immer mehr erweitert, z. B. um benutzerdefinierte Datentypen (z. B. JSON, Graph), In-Memory-Optionen, Datenkompression oder für spaltenorientierte Analysen. Damit versuchen sich die RDBMS weiterhin als Allzweck-Systeme zu positionieren. Allerdings wurde dabei die Systemarchitektur nicht neu entworfen, so dass grundlegende Funktionen der Transaktionsverwaltung weiterhin zentralisiert ablaufen.
Schlussfolgerung
Relationale Datenbanksysteme sind nach wie vor aus vielen betriebswirtschaftlichen Anwendungen und klassischen Branchen (Finanzwirtschaft, Industrie, Verwaltung) nicht wegzudenken. Die Gründe hierfür sind: die Stärken von RDBMS im Umgang mit strukturierten Daten, SQL als standardisierte Sprache für Anfragen und zur Schemabeschreibung, die Sicherung der Konsistenz der Daten im Mehrbenutzerbetrieb und im Fehlerfall und eine ausgereifte Anfrageoptimierung.
Insofern stellen NoSQL-Datenbanken genau da eine Ergänzung dar, wo eine große Anzahl heterogener und wenig strukturierter Daten zu verarbeiten ist. Dabei kommt es vor allem auf die Performance und die Verfügbarkeit des Systems an und weniger auf die Datenkonsistenz, die in einem Netzwerk nicht zu jedem Zeitpunkt garantiert werden kann. Die Entscheidung für ein NoSQL-System wird dadurch erschwert, dass es eine unüberschaubare Fülle von Anbietern in den einzelnen Kategorien gibt. Orientierung bei der Auswahl bieten die Größe einer Community und die Unterstützung durch große Hersteller.
- Bigtable: A Distributed Storage System for Structured Data
- Dynamo: Amazon’s Highly Available Key-value Store
- ArangoDB, the database for graph and beyond
- Benchmarking Cloud Serving Systems with YCSB
