Anzeige
Anzeige
UX & Design

Relationale Datenbanken bekommen Konkurrenz: NoSQL – Neues Denken in der Datenbankwelt

Es herrscht Aufbruchstimmung in der Welt der Datenbanken. Nach mehr als 30 Jahren Dominanz der relationalen Datenbanken schicken sich unterschiedlichste Lösungen an, ihnen den Platz streitig zu machen. NoSQL bietet neue Denkansätze für Datenbanken unterschiedlicher Art.

8 Min.
Artikel merken
Anzeige
Anzeige

NoSQL ist ein Statement und beschreibt eine neue Generation von Datenbanken, die mit den Traditionen der relationalen Dinosaurier brechen. Die Idee ist nicht neu, und einige Konzepte gehen zurück bis in die frühen achtziger Jahre. Objektorientierte Datenbanken als geistige Vorläufer einiger NoSQL-Datenbanken konnten sich aber nicht durchsetzen.

Anzeige
Anzeige

Warum dennoch der ganze Aufwand? Oracle, Sybase, MySQL und Konsorten verrichten schließlich seit Jahren zuverlässig ihre Dienste in allen möglichen Bereichen. Das ist zwar richtig, doch sie sind nicht unbedingt das richtige Tool für jeden Zweck. Gerade mit dem Anwachsen des Datenaufkommens im Internet sind neue Wege gefragt, die auch umfassenderen und loseren Datenstrukturen gerecht werden. Relationale Datenbanken leben von einem festen Schema und schränken Daten entsprechend ein.

Ohne Schema

Die neue Generation von Datenbanken zielt dementsprechend vor allem auf die Nöte und Bedürfnisse des Webs. Unstrukturierte Daten bedürfen des Verzichts auf ein festes Schema und dessen Constraints und benötigen Unterstützung simpler Datenstrukturen wie Hashes und Arrays, deren Modellierung mit relationalen Datenbanken immer wieder zu unschönen Workarounds führt.

Anzeige
Anzeige

Viele NoSQL-Vertreter stellen gewisse Möglichkeiten zur Verfügung, um eine Art Schema zu definieren, gemeinhin hat sich jedoch durchgesetzt, ein einfaches Datenformat wie JSON oder einfach Hashmaps zu verwenden, um Daten zu speichern. Man spricht nicht mehr von Zeilen in einer Tabelle, man spricht von Dokumenten, die keinem Schema unterliegen und trotzdem alle Teil der gleichen Datenbank sein können.

Anzeige
Anzeige

Eventual-Consistency

Die wichtigste Erkenntnis der neuen Datenbanken ist, dass strikte Datenkonsistenz in verteilten Systemen nicht oder nur sehr bedingt möglich ist. Wer bereits Kontakt mit MySQLs Replikation hatte, kennt das Problem. Wird ein Eintrag im Master geschrieben, ist er nicht sofort auf den Slaves verfügbar. Der Verzug ist meist kaum spürbar und wird auch nur ungern in Applikationen berücksichtigt, aber die Gefahr, dass er länger als nur ein paar Millisekunden beträgt, besteht.

Post-relationale Datenbanken sehen diesen Umstand nicht unbedingt gelassen, erkennen ihn aber als Notwendigkeit an, wenn Daten über mehrere Nodes verteilt sind. Konsistenz ist meistens nicht ohne Nachteile zu hundert Prozent erreichbar. Je verteilter die Systeme, desto mehr sorgen Netzwerkverbindungen und geografische Entfernung dafür, dass man für strikte Konsistenz einen hohen Performance-Preis zahlt.

Anzeige
Anzeige

Eventual-Consistency [1] ist vor diesem Hintergrund eine Alternative. Werden Daten auf einen Node geschrieben, ist unbestimmt, wann genau sie auf anderen Nodes verfügbar sind. Gibt es keine konkurrierenden Updates, wird aber davon ausgegangen, dass die Änderung auf alle Nodes propagiert wird.

MapReduce statt SQL

SQL ist zwar standardisiert und durchaus eine nützliche und flexible Abfragesprache, allerdings recht ungeeignet, wenn es um verteilte Daten geht. Besonders wenn Sharding oder Partitioning über mehrere Nodes gefragt ist, wird es mit SQL eher mühsam.

MapReduce, ein Prinzip, nach dem Daten zuerst für Abfragen aufbereitet und die Ergebnisse aggregiert werden, ist sehr verbreitet in der Welt von NoSQL. Im Map-Schritt werden aus einer Sammlung von Attributen die interessanten (beispielsweise Tags eines Blog-Posts) herausgepickt, in einem View abgelegt und dann im Reduce-Schritt aggregiert, was meistens in eine Art Aufsummierung der im Map-Schritt gesammelten Ergebnisse mündet.

Anzeige
Anzeige

Die Fülle an Tools, die bereits im NoSQL-Bereich existieren, lässt sich grob klassifizieren in:

  • Key-Value-Stores
  • dokumentenorientierte Datenbanken
  • Graph-Datenbanken
  • Column-Stores

Key-Value-Stores

Manchmal reicht es, einen Schlüssel mit nur einem Wert zu versehen und zu speichern. Der Schlüssel kann dabei ein beliebiger String sein, genauso wie der Wert. Diesem Prinzip folgen die Key-Value-Stores. Klingt simpel, ist aber extrem gut skalierbar und eignet sich für überraschend viele Bereiche einer Webanwendung.

Wegbereiter war hier vor allem Amazon, die mit einem Dokument zu ihrem intern verwendeten Tool Dynamo [2] die Inspiration für viele der hier vorgestellten Tools lieferten. Ein nennenswertes Derivat ist Dynomite [3], eine in Erlang geschriebene Implementierung von Dynamo sowie Project Voldemort [4], ein von LinkedIn entwickeltes System.

Anzeige
Anzeige

Etwas aus der Reihe tanzt Redis [5]. Zwar auch auf dem Key-Value-Prinzip basierend, bietet es eine ganze Riege von einzigartigen Features. Es versucht aber eher, eine Lösung für vielfältigste Szenarien zu sein, als sich auf reine Key-Value-Storage zu beschränken. Neben einfachen Strings können Werte in Redis auch Listen oder Sets (in Zukunft auch Hashes) sein, auf denen atomare Operationen wie Push, Pop, Sortierung und noch viele mehr ausgeführt werden können.

Tokyo Tyrant [6] bietet einige interessante Add-Ons wie Stored-Procedures in Lua, ist aber eine In-Process-Lösung und ohne den Zusatz von Tokyo Cabinet in verteilten Umgebungen kaum brauchbar.

Scalaris [7] ist hingegen einer der wenigen Key-Value-Stores, die sich Strong-Consistency über das Paxos-Protokoll geschrieben haben, allerdings bietet es von Haus aus keine Persistenz-Mechanismen, sondern greift beispielsweise auf Berkeley DB zurück. Auch Amazons S3 fällt in diese Sparte, selbst wenn es nur eine einfache Möglichkeit ist, Daten webgerecht abzulegen. Letzten Endes werden Daten auch nur über einen Key abgelegt.

Anzeige
Anzeige

Dokumentorientierte Datenbanken

Auch wenn sie meist dem gleichen Prinzip von Key und Value folgen, peilen dokumentorientierte Datenbanken unstrukturierte Daten an, meist mit JSON oder einem Derivat beschrieben. Es darf auch hier und da gern XML sein, was aber eher bei den schon etwas gesetzteren XML-Datenbanken der Fall ist, die von der Philosophie her ähnliche Ziele verfolgen.

Die grundlegende Idee geht zurück auf Lotus Notes, wo sich das Prinzip von unstrukturierten, aber in sich vollständigen Dokumenten zuerst eingebürgert hat. Der bekannteste Vertreter der Gattung hat sich auch einiges von dieser Philosophie abgeschaut und mit Erlang und JSON verheiratet. Das Ergebnis ist CouchDB [8], eine verteilte Datenbank, die vor allem durch zwei Merkmale herausragt.

Replikation ist ein First-Class-Feature in CouchDB – man kann jede Datenbank zu jeder anderen replizieren. Damit Konflikte erkannt werden, erhalten Dokumente in CouchDB eine Revision, die sowohl bei Replikation als auch bei Updates mit der aktuellsten Version des Dokuments abgeglichen wird. Ist sie nicht gleich, gibt es einen Konflikt, der in einer Queue zur Abarbeitung durch den Endnutzer landet.

Anzeige
Anzeige

Der zweite Grund, warum CouchDB hervorsticht, ist seine unverkennbare Nähe zum Web. Es baut fast ausschließlich auf bewährte Komponenten auf, allen voran HTTP, JSON und JavaScript. JavaScript findet in der MapReduce-Implementierung von CouchDB Verwendung. Die eingebettete Engine erlaubt es gar, ganze Applikationen in CouchDB zu betreiben.

Riak [9], auch in Erlang geschrieben, verfolgt die gleichen Prinzipien wie CouchDB, unterstützt aber Datenverteilung im Stile von Dynamo. Für CouchDB ist ein ähnliches Feature in Planung, bis dahin aber über das Add-On CouchDB Lounge [10] einsetzbar.

Riak kennt lose Verbindungen zwischen einzelnen Dokumenten in Form von Links [11]. Jedes Dokument kann eine Liste von ihnen enthalten. Verlinkte Dokumente können so ohne zusätzliche Roundtrips des Clients in einer Anfrage mit ausgeliefert werden [12].

Anzeige
Anzeige

Während CouchDB und Riak wohl am konsequentesten in der Abkehr von traditionellen Datenbanken sind, versucht MongoDB [13], den Weg des geringsten Widerstands zu gehen. Es baut auf bewährten Mechanismen auf und vereint Teile der traditionellen Datenbanken mit den Vorteilen der post-relationalen.

Dokumente in MongoDB werden in BSON gespeichert, einer Art binärem JSON-Format, das noch um einige native Typen erweitert wurde. MongoDB bietet Live-Queries, was die Nähe zu relationalen Datenbanken begründet. Damit diese allerdings performant laufen, sind auch bei MongoDB Indizes auf den gefragten Attributen notwendig.

MongoDB ist in C++ geschrieben und greift für Persistenz der Daten auf dessen Support für Memory-Mapped-Files zurück. Da diese keine hundertprozentige Konsistenz der Daten garantieren, ist ein Einsatz von MongoDB ohne eine entsprechende Live-Replika nicht ohne Risiko von Datenverlust.

CouchDB hingegen hängt Daten immer nur an seine B-Tree-Indizes an, womit jederzeit Konsistenz gewährleistet ist. MongoDB hat sich trotz seiner potenziellen Schwächen bewährt und kommt erfolgreich in einigen umfangreicheren Produktivumgebungen zum Einsatz. Auch Amazon fällt mit SimpleDB [14] in diese Kategorie, ist aber eher mit einer großen Excel-Tabelle als mit den oben genannten Vertretern vergleichbar.

Graph-Datenbanken

Geistig sind Graph-Datenbanken sehr nah an Objekt-Datenbanken. Ihre Stärke liegt in der direkten Abbildung von Relationen zwischen einzelnen Einträgen und der Möglichkeit, diese Referenzen ohne Performance-Verlust zu traversieren. Der bekannteste Vertreter ist Neo4j [15]. Es vereint die Vorteile von dokumentorientierten Datenbanken mit denen von Objekt-Datenbanken. Daten können unstrukturiert sein, sind aber über Relationen extrem performant traversierbar.

Ein weiterer Vertreter aus Deutschland ist Sones GraphDB [16], im Gegensatz zu den meisten hier vorgestellten Tools nicht Open Source. Während das Hauptaugenmerk auf C# als Anwendungssprache liegt, können Entwickler auch über eine SOAP- oder REST-API mit der Datenbank arbeiten. Anfragen werden in GQL formuliert, einem SQL-ähnlichen Dialekt.

Column-Stores

Column-Stores bauen auf der Philosophie auf, dass man Muster hat, denen zufolge man auf bestimmte Teile von Datensätzen zugreift. Da man oft nur einen Teil benötigt, wäre es effizienter, diese Daten zusammenhängend abzulegen, um Zugriffe so performant wie möglich zu machen.

Im Gegensatz zu relationalen Datenbanken sind Zugriffe auf bestimmte Attribute erstens versioniert und erfolgen zweitens direkt über eine Art sortierte Hashmap mit mehreren Keys: ID, Spalte und Version. Der Zugriff erfolgt so direkt und ohne den relationalen Umweg über Tabelle, ID und dann Spalte, was enorme Auswirkungen auf die Lese-Performance haben kann.

Über Familien von Spalten kann man forcieren, dass miteinander verwandte Attribute gemeinsam und effizient gespeichert und verteilt werden. Googles BigTable [17] baut als kommerzielles Produkt auf diesem Prinzip auf, während Facebooks Cassandra [18] den Ansatz mit den Verteilungsmechanismen von Dynamo verheiratet.

NoSQL und Ich

Es ist nicht einfach, eine konkrete Empfehlung auszusprechen, wie man die neuen Tools in Projekten einsetzen kann. Während zum Beispiel Redis durch seine Flexibilität recht vielfältig einsetzbar ist (Click-Tracking, Worker-Queue etc.) und Dokument-Datenbanken wie CouchDB sich für Webanwendungen vielfältigster Art anbieten, sind Tools wie Cassandra sehr spezialisiert auf bestimmte Anwendungsfälle. Aber gerade das macht die neue Generation von Datenbanken so interessant.

Sie wollen nicht für alle Fälle passen, sondern suchen sich einen Teil heraus und versuchen, diesen so performant und schmerzfrei wie möglich zu machen. Es lohnt sich, die einzelnen Tools im Detail anzuschauen, sie auszuprobieren und Erfahrungen mit ihnen zu sammeln. Fast alle werden produktiv eingesetzt, die meisten sind gar Open Source und werden von einer aktiven Community gestützt. Auch wenn relationale Datenbanken definitiv nicht am Ende sind, so ist das Ende von allgemeingültigen Lösungen nicht mehr weit. Die Zukunft gehört den spezialisierten Tools.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Kommentare (1)

Community-Richtlinien

flo

Ein Fakt im Thema Graph-Datenbanken hat sich geändert!

sones GraphDB ist Open Source, den Code gibt es unter: GitHub

Weitere Informationen rund um die GraphDB unter: sones wiki

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Kommentar abgeben

Melde dich an, um Kommentare schreiben und mit anderen Leser:innen und unseren Autor:innen diskutieren zu können.

Anmelden und kommentieren

Du hast noch keinen t3n-Account? Hier registrieren

Anzeige
Anzeige