Datenbanken Online Lexikon TH Köln, Campus Gummersbach
Aktuelle Änderungen - Suchen:

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.

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:

Kategorie: NoSQL, Grundlagen, N