NoSQL-Datenmodelle und -Systeme

Der Begriff NoSQL hat in seiner doch noch recht jungen Geschichte bereits einen Bedeutungswandel hinter sich. In seinen Anfängen (1998 Carlo Strozzi (IBM): RDBS ohne SQL-API) wurde er als im wahrsten Sinne des Wortes als "no SQL" also "kein SQL" verstanden. Seit ca. 2009 wird NoSQL als Sammelbegriff für zum relationalen Modell "alternative" Datenbankentwicklungen verwendet (2009 Johan Oskarsson: Titel für ein "distributed data storage"-Event) und eher im Sinne von "Not Only SQL" verstanden.

Die Zeiten, wo ein Datenmodell bzw. ein DBS, vorzugsweise das relationale, die "Lösung" für alle Probleme darstellte bzw. darstellen musste, sind wohl endgültig vorbei. Für die klassische Geschäftsdatenverarbeitung mit ihren strikten Konsistenzanforderungen stellen RDBMS in der Regel immer noch die erste Wahl dar. Für diesen Zweck sind diese DBS auch seit den 70-er Jahren entwickelt und optimiert worden. Nur haben sich mit Aufkommen des Web 2.0 seit Ende Anfang dieses Jahrtausends die Anforderungen dramatisch geändert.

Im Vordergrund stehen nun Datenverarbeitung im Tera- und Peta-Datenbereich. Da stoßen die Scale-up-Potentiale relationaler Systeme, die für eine "Ein-Server"-Hardware konzipiert wurden, an ihre Grenzen,
- was die Laufzeit von Anfragen angeht,
- die explodierenden Investitionskosten für immer aufwändigere Servertechnik,
- wie auch immer fundierte Spezialkenntnisse bei den Administratoren.
  Kurz, die Skalierungsfähigkeit von RDBS ist nicht so unbegrenzt, wie dies in NoSQL-Systemen möglich wird.
Der Stellenwert der Laufzeit von Anfragen hat sich sehr stark in den Vordergrund geschoben. Bei Internetanwendungen großer Konzerne geht es nicht mehr darum, Tausende von Anwendern zu bedienen, es geht in die Hunderttausende und Millionen, die dann auch nicht gleichverteilt sondern mit extremen Lastspitzen zugreifen. Kunden strafen Web-Shops mit langsamen Seiten dadurch ab, dass sie nicht einkaufen, womit sich Laufzeit und Performance-Probleme direkt auf den Geschäftserfolg auswirken. Diese Anfrageperformance kann nicht über "Ein-Server"-Systeme realisiert werden, die gewünschten Antwortzeiten lassen sich nur in Rechnernetzen (Rechner-Clustern) erreichen, die extrem schnell skalierbar sind. Und genau damit tun sich RDBS schwer.
Eine weitere Technik, um die Antwortzeiten zu beschleunigen aber auch um tolerant gegenüber Ausfällen von Rechnern bzw. Netzteilen zu sein (Fehlertoleranz), ist die Replikation der Daten. Damit ist das speichern von Duplikaten auf verschiedenen Rechnern gemeint. Für diese Anforderung gibt es auch Antworten in RDBS, nur sind die Antwortzeiten nicht annähernd so schnell wie bei NoSQL-Systemen.
Dafür ist der Stellenwert der sehr strikten Konsistenzanforderungen und der damit verbundenen ACID-Eigenschaften ? von Transaktionen deutlich in den Hintergrund getreten. Was für die Geschäftsdatenverarbeitung mit relationalen Systemen in der Vergangenheit, wie auch heute noch gilt, spielt für viele Informationen im Internet nicht die entscheidende Rolle. Ob eine Freundschaftsbeziehung oder ein Blog-Eintrag nun in Europa ein paar Minuten früher aktualisiert ist, als in Südamerika oder Australien, spielt nun wirklich nicht die entscheidende Rolle. Diese Abkehr vom strengen Konsistenzbegriff, der RDBMS gerade auf verteilten Rechnernetzen viel Laufzeit kostet, spiegelt sich im Konzept des "eventually consistent" und dem alternativen Konsistenzmodell BASE wider.
In der Wissenschaft ist erkannt worden, dass eine Unvereinbarkeit der drei wichtigsten Ziele, Konsistenz (consistency), Verfügbarkeit im Sinne schneller Antwortzeiten (availability), Ausfalltoleranz (partition tolerance) von verteilten Anwendungen bzw. verteilten Datenbanksystemen vorliegt. Bei RDBS steht an forderster Stelle das Ziel der Konsistenz und es werden Abstriche bei den Antwortzeiten in Kauf gekommen. NoSQL-Systeme stellen das Ziel der kurzen Antwortzeiten in den Vordergrund und nehmen vorübergehende Phasen von Inkonsistenz in Kauf evenutally consistency). Das CAP-Theorem beschreibt diese Problematik. Daraus resultiert bei den NoSQL-Systemen eine Abkehr von den relationalen ACID-Eigenschaften ? hin zu dem Konsistenzmodell BASE.
Die Abbildung von Begriffen in Ontologien mit ihren komplexen Beziehungen untereinander, von Freundschafts- oder Geschäftsbeziehungen, von Vorgesetztenhierarchien oder auch von Bauteilen in Stücklisten mittels Relationen hat sich in der Vergangenheit bei RDBS als wenig problemadäquat erwiesen, was sich in inakzeptablen Laufzeiten der rekursiven Join-Anfragen wiederspiegelt. Für das schnelle Durchsuchen graphenbasierte Informationen zeigen sich passgenaue Graphendatenbanken und Graphenmodelle als sehr effizient.
Aufgrund der 7-Tage-24-Std.-Verfügbarkeit von Internet-Anwendungen bleibt den Administratoren kein Zeitfenster mehr für Schemaaktualisierungen (z.B. mittels der ALTER-TABLE-Anweisung), die in relationalen Systemen in der Regel die DB minuten- oder gar stundenlang verlangsamen oder gar ausfallen lassen.

Historie

1979 Ken Thompson entwickelte DBM, eine erste KeyValue-DB.
80er Heute noch beliebte Vorreiter sind Lotus Notes, BerkleyDB, GT.M, die sich jedoch noch durch die Verarbeitung geringer Datenmengen auszeichnen.
1998 Carlo Strozzi (IBM) prägte den Begriff „NoSQL“ im Sinne von "no SQL" für seine zwar relationale DB aber ohne SQL-API.
2000 Zusammen mit Web2.0 kam der Wunsch sehr viel größere Datenmengen zu verarbeiten.
- Google war Vorreiter mit der Entwicklung solcher grundlegender Technologien wie Map/Reduce-Framework (2004), BigTable-DBS ? (2004), GFS ? dem eigenen Hochgeschwindigkeits-Dateisystem.
- Alle übrigen Internet-Größen zogen nach: Yahoo, Amazon, MySpace, Facebook, LinkedIn, …
2006-2009 In dem Zeitraum entstanden alle klassischen NoSQL-Systeme wie z.B. Cassandra, CouchDB, Dynamo/Dynamite, Hbase, Hypertable, Neo4j, MongoDB, Redis, Riak, S3, Scalaris, SonesDB, Voldemort, … Eine wesentlich vollständigere Liste ist bei Prof. Edlich von der Beuth Hochschule für Technik Berlin: Your Ultimate Guide to the Non - Relational Universe!.
2009: NoSQL wird zum gemeinsamen Schlagwort immer mehr im Sinne von "Not Only SQL" und damit treten die Systeme stärker in die öffentliche Wahrnehmung, weg von Image der speziellen Internet-Datenbanken hin zu passenden Lösungen für Probleme auch von Nicht-Internet-Firmen und -Organisationen.

Definition

Bislang gibt es keine einheitliche und streng abgrenzende Definition, dafür ist die Community noch viel zu sehr im Fluss. Hier ein Versuch einer Definition wie sie Edlich, Friedland, Hampe, Brauer in ihrem Buch ([Edlich et al. 2010], S. 2 ff) vorgenommen haben.

Kein relationales Datenmodell
- Postuliert wird eine Vielfalt der Modelle, einfach vor dem Hintergrund, dass das relationale Modell nicht immer für jede Anforderung am besten passt. Ein klassisches Beispiel an dieser Stelle sind graphenbasierte Probleme wie Netzwerke und Topologien irgendeiner Art, die am besten mit Graphenmodellen modelliert und mit Graphendatenbanken realisiert werden. Zu Beginn eines Projekts steht nun die SWOT-Analyse (Strengths/Stärken, Weakness/Schwächen, Opportunities/Chancen, Threats/Bedrohungen) mit der analysiert wird, welches Modell bzw. DBS, relationale, objektrelationale, objektorientierte oder eines der NoSQL-Modelle nun am besten passt.
Eignung für Systeme mit verteilter und horizontaler Skalierbarkeit
- Schnelle Reaktionszeiten auf Anfragen und Manipulationen lassen sich nur mit dem Scale-out-Prinzip erreichen, also mit horizontaler Skalierung durch dynamisches Einbinden/Löschen von Rechnerknoten (Nodes). Die gängige Praxis für RDBS hingegen ist das Scale-up-Prinzip, bei dem ein Rechner immer weiter technisch aufgerüstet wird.
- Da die Systeme fehlertolerant gegenüber Rechnerausfällen arbeiten müssen und können, dürfen Knoten (Rechner) durchaus auch aus einfacherer Hardware bestehen, womit zusätzlich Investitionskosten gespart werden.
Open Source
- Dies ist eher als Protestpostulat zu verstehen, aber sicherlich kein Ausschlusskriterium. Zu einer gründlichen SWOT-Analyse wird es nun gehören, dass für eine Aufgabenstellung ein funktional passendes NoSQL-System unabhängig von der Fragestellung ob Open Source oder nicht zu eruieren ist. Und sich dann zu fragen, ob Open Source nicht doch eingesetzt werden kann. Systeme wie CouchDB, Neo4j und andere Lizenz- und Geschäftsmodelle gehören trotzdem dazu.
Schemafrei oder nur schwächere Schemarestriktionen
- Web2.0-Anwendungen müssen agiler sein – auch bei den Datenstrukturen. Informationen im Web, Dokumente etc. haben kaum gleiche Strukturen, damit müssen Anwendungen und DB-Systeme umgehen können. Konsequenz ist es, die Schemainformationen in die Anwendung (wieder zurück-) zu verlagern.
- Schelle Reaktionszeiten bei Schemaänderungen sind ein Muss. Schemaänderungen können Datenbanksysteme nicht wie bei den RDBS minuten- oder gar stundenlang lahm legen.
Einfache Datenreplikation zur Unterstützung der verteilten Architektur
- Grundidee der Verteilung des Datenbestands auf viele Knoten erfordert eine einfache und schnelle Replikation der Daten, damit Daten auch bei Kontenausfällen noch verfügbar sind. Bei den meisten NoSQL-Systemen ist dies gut gelungen.
- Möglich wird dies jedoch nur durch „abgeschwächte“ Konsistenzanforderung, wie sie die Annahmen des CAP-Theorems und des "evenutally consistency" vorsehen. Praktisch umgesetzt wird sie durch das BASE-Konsistenzmodell.
Einfache API
- SQL war sicherlich einfach, deklarativ, aus sehr ausdrucksstark und vor allem standardisiert.
- Eine einfach API ist sicherlich bei den meisten NoSQL-Systemen noch eine offene Baustelle. Viele APIs sind zwar einfach, aber meist auch nicht so ausdrucksstark (weniger Funktionalität). Die fehlende Funktionalität muss dann die Anwendungsprogrammierung ausgleichen.
- Es werden derzeit viele neue Wege entwickelt, die gerade den Web2.0-Anforderungen gerecht werden.
Kein ACID als Konsistenzmodell
- Die Einhaltung von ACID-Eigenschaften ? verkompliziert und verlangsamt die verteilte Datenhaltung und damit die Skalierbarkeit in RDBS und stellt somit ein zentrales Problem dar.
- "evenutally consistency" und optimistische BASE-Ansatz hingegen basieren auf der Annahme, das Daten in verschiedenen Knoten vorübergehend/kurzzeitig inkonsistent sein dürfen. Und in Internet-Anwendungen gibt es sie, diese Daten, die dies sein können. Die klassischen Geschäftsdaten sicherlich eher nicht - aber dafür gibt es ja weiterhin RDBS.
- Es gibt auch Systeme, die mit ACID, mit BASE oder wahlweise mit beiden ausgeführt werden können.

Grenze zwischen NoSQL und RDBS

Diese Trennung ist nicht trivial. Auch ohne SQL ist die Verwendung relationaler Modelle möglich. Andererseits gibt es auch NoSQL-DB-Systeme, die auf bewährten relationalen DBS aufsetzen, wie InfoGrid, HyperGraph, Riak, memcached, ..., deren Benutzeroberfläche jedoch andere Datenmodelle, Anfragesprachen oder Konsistenzkonzepte zur Verfügung stellt, wie z.B. hybride Lösungen in Form der DBSe HadoopDB und GenieDB. Auch wird versucht, NoSQL-Konzepte in vorhandenen DBMS-Systeme zu integrieren, z.B. RDBS mit Map-Reduce-Modellen u.v.m.

Kategorien von NoSQL-DB-Systemen

Eine Möglichkeit der Kategorisierung ist die des zugrunde liegenden Datenmodells.

Core NoSQL-Systeme
Nachgelagerte NoSQL-Systeme

Als Alternative Kategorisierungsmöglichkeiten bieten sich Eigenschaften an, wie

Verteilt: Hbase, Cassandra, MongoDB, Riak, CouchDB Lounge, Voldemort, Scalaris, ...
Nicht für den Anwender sichtbar verteilt: Redis, Tokyo-Familie, Amazon SimpleDB, ...
Disk- oder RAM-basiert (HSP-Datenbanksysteme, in memory databases):
- Konfigurierbar: Hbase, Cassandra, MongoDB, Hypertable, Redis, …
- Nur Disk-basiert: CouchDB, Riak, …

Zentrale NoSQL-Technologien

Hier einige Ideen und Technologien, die eine sehr wesentliche Rolle in NoSQL-Systemen übernommen haben.

Die NoSQL-Community diskutiert und entwickelt lebhaft und phantasiereich. Ein wirklich wichtiges Anliegen ist die "freie Datenbankwahl", also raus aus den Langzeit-Exklusiv-Verträgen. Jetzt und in Zukunft wird es aufgrund der NoSQL-Entwicklungen mehr denn je notwendig sein, mehr Zeit für die Analyse zu verwenden, welches Datenmodell/DBS für die eigene Aufgabenstellung sinnvoll ist. Die Vielfalt von NoSQL sorgt zumindest dafür, dass es für jedes Problem ein (möglichst) passendes DBS gibt.

NoSQL stellt keine Herausforderung für die „relationale Welt“ sondern eine sinnvolle Erweiterung der DB-Welt. Neue Anforderungen erfordern neue NoSQL-Modelle und -Systeme.

Quellen:

Edlich, Friedland, Hampe, Brauer: „NoSQL – Einstieg in die Welt der nichtrelationalen Web2.0- Anwendungen“, Hanser-Verlag, 2010, ISBN 978-3-446-42355-8

Weiterführende Literatur:

Frey, M.: „Etablierte Datenmodelle der NoSQL-Familie und ihre spezifischen Eigenschaften im Kontext von Cloud-Datenbanken“, Bachelorarbeit, FH Köln, Institut für Informatik, 08/2010
Kossmann, D., Kraska T.: „Data Management in the Cloud: Promises, State- of-the-art and Open Questions“, in „Datenbanken und Cloud-Computing“, Datenbank Spektrum, Band 10 Heft 3, Springer-Verlag, 12.2010, S. 121-129

Weiterführende Links:

Edlich, St.: Your Ultimate Guide to the Non - Relational Universe!, Stand 23.03.2011

Kategorie: NoSQL, Grundlagen, N