Entwicklung & Design

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

Seite 2 / 3

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.

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.

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.

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.

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.

Bitte beachte unsere 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

Ein Kommentar
flo
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