Genau genommen führt die Bezeichnung NoSQL als Abgrenzung von SQL zu Missverständnissen. NoSQL steht nicht für "kein SQL", sondern für "Not only SQL", also nicht nur SQL. Dadurch ist der Begriff zwar einprägsam, aber unklar. Unter "Not only SQL" fällt wohl letztlich jeder Mechanismus für die Verwaltung von Daten.

Die NoSQL-Bewegung ist eine Reaktion auf die Herausforderungen, vor denen das Daten-Management in den nächsten Jahren steht:

• Die Datenmengen wachsen exponentiell.

• Daten sind immer stärker vernetzt. Dazu gehören der Hypertext im Web, Blog-Inhalte oder User Generated Content. Da viele Anwender immer und überall online sind, produzieren sie, beispielsweise in Social Networks, immer mehr Daten selbst, statt sie nur abzurufen.

• Die Daten sind immer weniger strukturiert. Konnten sie früher in Tabellen repräsentiert werden, fällt dies heute zum Beispiel bei User Generated Content zunehmend schwerer. Auch bei der Suche nutzt man jetzt Text-Indizes und nicht mehr bestimmte Werte in Tabellenspalten.

• Die Integration durch eine gemeinsame Datenbank nimmt ab. Stattdessen setzten sich Techniken wie Web-Services für die Integration durch. Jedes System hat seine eigene Datenbank.

• Durch die Cloud werden noch mehr Daten zentral gehalten, Systeme müssen daher stärker skalieren. Dafür sollten primär viele weniger leistungsstarke Rechner genutzt werden, die in der Cloud typischerweise zur Verfügung stehen. Klassisch nutzt man aber gerade für relationale Datenbanken eher wenige und dafür leistungsstarke Maschinen.

• Durch die Verfügbarkeit von kostengünstigen Hochgeschwindigkeits- sowie mobilen Internet-Zugängen werden zunehmend hohe Anforderungen in Bezug auf Datendurchsatz und Hochverfügbarkeit an Internet-Plattformen gestellt.

Im Video: Einführung in NoSQL-Datenbanken

Zum Video: Datenflut bereitet NoSQL den Weg

Keine vollständige Ablösung

Aufgrund dieser Herausforderungen gibt es genügend Bereiche, die durch neue Techniken abgedeckt werden können, ohne dass relationale Datenbanken dort unbedingt abgelöst werden müssten. Da häufig strategische Entscheidungen zugunsten bestimmter relationaler Datenbanken getroffen werden, ist ihre vollständige Ablösung ohnehin eher unwahrscheinlich.

Es gibt völlig unterschiedliche Konzepte, die unter der Bezeichnung NoSQL beworben und vermarktet werden. Die wichtigsten sind:

• "Key/Value Stores" speichern unter einem Schlüssel einen einzigen Wert ab. Dieses Modell ist ausgesprochen einfach. Es hat den Vorteil, dass die Daten sehr leicht auf mehrere Rechner verteilt werden können. Der Nachteil ist allerdings, dass man komplexere Datenstrukturen kaum sinnvoll abbilden kann.

• "Document Stores" können mit Dokumenten umgehen. Die Daten müssen keinem vordefinierten Schema entsprechen, aber Anfragen nach Datensätzen mit bestimmten Eigenschaften werden unterstützt. Diese Datenbanken sind vor allem für wenig strukturierte Daten nutzbar und von einem objektorientierten System aus auch einfach zu verwenden.

• "Wide-Column"-Ansätze bieten die Möglichkeit, in einer Zeile viele Daten zu speichern. Dabei können auch neue Spalten eingeführt werden.

• "Graphendatenbanken" speichern Knoten und Beziehungen zwischen Knoten. Sie sind nützlich, um beispielsweise die Beziehungen in einem sozialen Netzwerk abzuspeichern, und können Anfragen wie "Wie viele Bekannte zweiten Grades hat der Nutzer?" leicht bearbeiten.

Für diese verschiedenen Typen von NoSQL-Datenbanken sollen nun einige Beispiele genauer betrachtet werden.

MongoDB

MongoDB (von "humongous") ist eine in C++ geschriebene Open-Source-Datenbank der Firma 10gen nach AGPL-Lizenz, die für die meisten gängigen Plattformen bereitgestellt wird. MongoDB fällt in die Kategorie der Document Stores. Der Vorteil dieser Datenbanken ist, dass Dokumente sowohl dem natürlichen Objekt als auch dessen Repräsentation in einer objektorientierten Sprache entsprechen können und eine Transformation weitestgehend entfällt. Des Weiteren ist MongoDB schemalos, das bedeutet, dass die Dokumente und deren Aufbau nicht festgelegt sind. Felder und Datentypen können sich bei jedem Dokument ändern.

Eine MongoDB-Instanz enthält eine beliebige Anzahl von Datenbanken. Dabei beinhaltet eine Datenbank wiederum eine beliebige Anzahl von Collections. Eine Collection ist vergleichbar mit einer Tabelle aus einem RDBMS. In einer Collection werden die Dokumente abgelegt. Dokumente sind vergleichbar mit Zeilen einer relationalen Tabelle. Das Dokument besteht aus einer beliebigen Anzahl von Feldern. Der entscheidende Unterschied zu einer relationalen Datenbank ist, dass ein Dokument nicht nur eine flache Folge von Feldern ist, sondern eine hierarchische Struktur besitzen kann. Ein Dokument kann weitere "embedded" Dokumente oder Referenzen auf andere Dokumente enthalten. Zusätzlich besitzt jedes Dokument die ObjectID. Dabei handelt es sich im Normalfall um eine 12-bytige im MongoDB-Cluster eindeutige ID. Fortlaufende Sequenzen und UUIDs sind auch als ID möglich. In der nachfolgenden Abbildung ist ein Beispiel-Dokument mit einem embedded Dokument sowie Referenzen auf weitere Dokumente dargestellt.

MongoDB speichert und überträgt die Dokumente im BSON-Format. BSON ist ein binäres JSON-ähnliches Datenformat. Bei JSON (JavaScript Object Notation) handelt es ich um eine mit XML vergleichbare Datenrepräsentation, die vor allem im JavaScript-Umfeld genutzt wird, siehe auch http://de.wikipedia.org/wiki/JavaScript_Object_Notation. Zusätzlich zu den normalen JSON-Datentypen (String, Integer, Boolean, Double, Null, Array und Objekt) werden noch weitere Datentypen, wie zum Beispiel Datum, ObjectID oder binäre Daten unterstützt.

Die Datenbank stellt eine umfangreiche Query Language zur Verfügung. Dabei werden die Queries als JSON-(BSON)Objekte dargestellt. Verschiedene Vergleichs- und Meta-Operatoren, Regular Expressions und JavaScript Expressions können zur Suche benutzt werden. Um die Abfragen zu beschleunigen, sollten wie bei RDBMS Indizes angelegt werden.

Um in verteilten Umgebungen eine hohe Performance zu gewährleisten, unterstützt MongoDB keine komplexen Transaktionen. Stattdessen bietet die Datenbank atomare Operationen auf einzelne Dokumente sowie einige weitere Mechanismen wie "Update if Current", "Insert if Not Present" oder "two-phase commit" für das gemeinsame Ändern von mehreren Dokumenten.

Ausfallsicherheit durch Replica Sets

Die Ausfallsicherheit wird bei MongoDB durch sogenannte Replica Sets sichergestellt. Ein Replica Set besteht dabei mindestens aus zwei Knoten. Es gibt dann einen Master und beliebig viele Slave-Knoten, wobei der Master-Knoten die schreibenden Operationen bearbeitet und die Slaves für Lese-Operationen genutzt werden. Bei Ausfall eines Servers erfolgt ein automatischer Failover, sowohl bei lesenden als auch schreibenden Operationen. Sollte z.B. der Master-Knoten ausfallen, so wird automatisch der Slave-Knoten zum neuen Master-Knoten, der sich zuletzt mit dem ausgefallen Master-Knoten synchronisiert hat. Neue oder wiederhergestellte Knoten werden automatisch als Slave-Knoten mit aufgenommen.

MongoDB unterstützt mittels Sharding die horizontale Skalierung. Hauptvorteil der horizontalen Skalierung gegenüber der vertikalen Skalierung ist die fast beliebige Skalierbarkeit und wesentlich höhere Kosteneffizienz. Technisch umgesetzt wird dies durch die Partitionierung der Daten über mehrere Server hinweg, den sogenannten Shards. So wird durch ein Shard festgelegt, welcher Server für welchen Datenbereich verantwortlich ist. Um dieses Wissen für einen Client transparent zu gestalten, richtet dieser seine Anfragen nicht direkt an einen Shard, sondern an einen mongos-Prozess, der als Router fungiert und die Anfrage an das entsprechende Shard weiterreicht. Die Metadaten der Sharding-Konfiguration - also u.a. welcher Shard auf welchem Server liegt - werden dabei durch einen Config Server verwaltet. Die Ausfallsicherheit eines Shards wird durch die oben beschriebenen Replica Sets gewährleistet. Die verteilte und parallele Verarbeitung großer Datenbestände unterstützt MongoDB durch eine Implementierung des MapReduce-Verfahrens.MongoDB bringt von Hause aus eine Begrenzung der Dokumentgröße auf 16 GB mit sich. Um dennoch große Binärdateien verarbeiten zu können, implementiert MongoDB die GridFS Spezifikation. Eine Binärdatei wird dabei für den Client transparent auf mehrere Pakete aufgeteilt und von MongoDB verwaltet.

Das MongoDB Ökosystem ist recht vielfältig. Es stehen verschiedenste Administrations Tools wie z.B. der Mongo Explorer zur Verfügung. Eine große Anzahl von Bibliotheken (Open Source nach Apache-Lizenz) zum Ansprechen der Datenbank in verschiedenen Programmiersprachen werden offiziell von MongoDB unterstützt. Diese APIs bieten bereits eine Abstraktion vom binären BSON-Format. Aufbauend auf diesen Treibern werden von der Community weitere Sprach- und Framework-spezifische Bibliotheken bereitgestellt. Diese ermöglichen beispielsweise ein einfaches Mapping von Objekten der jeweiligen Programmiersprache in MongoDB-Dokumente, wie z.B. der Java POJO Mapper Morphia.

Im Video: NoSQL-Datenbanken - MongoDB

Zum Video: Datenflut bereitet NoSQL den Weg

HBase

HBase ist die in Java geschriebene Datenbank von Hadoop, einem Open-Source-Projekt der Apache Software Foundation. Das Hadoop-Projekt beinhaltet verschiedene zusammenhängende Technologien zur robusten Verarbeitung großer Datenmengen in Computerclustern. Das Datenmodell von HBase ähnelt Googles BigTable, weswegen HBase auch als BigTable-Klon bezeichnet wird. Wie Googles BigTable arbeitet HBase mit starker Konsistenz, so dass, wie bei einer relationalen Datenbank, zu jedem Zeitpunkt alle Benutzer die gleiche Sicht auf die Daten haben. Das Datenmodell basiert auf Tabellen - ebenfalls wie bei relationalen Datenbanken: Eine HBase-Tabelle ist eine sortierte Liste von Zeilen, die im Gegensatz zum relationalen Modell aus einer variablen Anzahl von Spalten bestehen. Fachlich zusammenhängende Spalten werden aus Performance-Gründen zu Spaltenfamilien gruppiert und in separaten Dateien gespeichert. Dieses Modell ist wesentlich einfacher als das relationale Modell, aber gleichzeitig mächtiger als ein Key-Value-Store, so dass auch komplexe Datenmodelle abgebildet werden können, ohne dabei zu große Kompromisse bezüglich der Performance einzugehen.

Genaugenommen speichert HBase seine Daten nicht selbst, sondern bedient sich der Funktionen des verteilten Dateisystems HDFS (Hadoop Distributed File System). Durch die redundante Speicherung und Verteilung der Daten auf verschiedene Server ist HBase durch HDFS tolerant gegenüber Hardware-Ausfall. HBase speichert eine konfigurierbare Anzahl von Versionen der Datensätze. Bei jedem Schreibvorgang wird eine neue Version hinzugefügt, man spricht von inkrementellen Updates. Zu alte oder zu viele Versionen können automatisch gelöscht werden. HBase ist ein sortierter Datenspeicher: Die Zeilen in den Tabellen sind nach ihrem Zeilenschlüssel sortiert, die Spalten in den Zeilen nach ihrem Namen und die eigentlichen Datensätze in den Spalten nach ihrer Version. Diese Sortierung erlaubt sehr schnelle index-basierte Lese- und Schreiboperationen.

HBase eignet sich gut zum Speichern von Zählern

Der Einsatz von HBase ist sinnvoll, wenn die Spalten relativ klein sind und viele inkrementelle Updates durchzuführen sind. Zur Speicherung großer Binärdaten ist die direkte Nutzung von HDFS besser geeignet. Während HDFS für Anfragen mit geringer Latenz optimiert ist, setzt HDFS auf hohen Datendurchsatz. Aufgrund der Sortierung der Schlüssel sind Scanning und sequenzielles Lesen performanter als wahlfreie Punktanfragen. Am schnellsten sind die Schreiboperationen. Deswegen eignet sich HBase zum Speichern von Zählern. Auf Basis der Zähler können Echtzeitanalysen erstellt werden. Für relationale Datenbanken ist das Hochzählen teuer, denn der Zähler muss gelesen, modifiziert und geschrieben werden. Weil inkrementelle Updates so effizient sind, können auch sehr viele Zähler gleichzeitig verwendet werden. Beispielsweise kann der Aufruf einzelner Artikel in einem Online-Magazin gezählt werden, um in Echtzeit zu erfahren, welche Artikel in der vergangenen Stunde am populärsten waren. Die Spalten einer Tabelle sind nicht festgelegt und können sich zwischen einzelnen Zeilen unterscheiden. Dieses schemalose Datenmodell eignet sich sehr gut für unstrukturierte oder semi-strukturierte Daten. HBase ist besonders gut für Datensätze geeignet, bei denen nicht alle Felder mit Werten belegt sind. Felder ohne Werte benötigen nämlich keinen Speicherplatz.

Hadoop MapReduce und Hive können in Kombination mit HBase verwendet werden, um Analysen und komplexe Anfragen durchzuführen, die dann auf alle Knoten im Cluster verteilt werden. Konfigurationen können kommandozeilenbasiert mit der HBase Shell durchgeführt werden. Wahlweise kann die Thrift RPC-API, die unterschiedliche Programmiersprachen unterstützt, oder die JSON RESTful-API über HTTP verwendet werden, um auf HBase zuzugreifen. HBase ist Teil der aktiven Hadoop Community und wird zügig weiterentwickelt. Unternehmen wie Facebook, eBay und NAVTEQ setzen HBase erfolgreich ein. Eine spezielle Hadoop Distribution sowie Support für Unternehmen, die Hadoop produktiv einsetzen wollen, wird von Cloudera angeboten. Weiterführende Informationen zu HBase bietet die Projektseite http://hbase.apache.org/.

Im Video: NoSQL-Datenbanken - CouchDB

Zum Video: Datenflut bereitet NoSQL den Weg

Redis

Redis ist ein in C geschriebenes Open-Source-Projekt mit einer liberalen Lizenz und unterstützt die meisten gängigen Plattformen. Es läuft als Server-Prozess mit einem sehr einfachen Protokoll. Bibliotheken zum Ansprechen des Servers gibt es für zahlreiche Programmiersprachen. Redis fällt in die Kategorie der Key-Value-Stores, wobei die Werte auch komplexere Typen wie Listen, sortierte oder unsortierte Mengen oder auch Maps sein können. Dadurch sind auch komplexere Strukturen abbildbar.

Auf Schnelligkeit getrimmt

Außerdem eröffnen sich weitere Möglichkeiten für die Lösung typischer Probleme bei der Implementierung großer Systeme: So kann eine Liste auch sehr einfach eine Warteschlange implementieren. Man legt die Aufgaben in die Liste, und die Bearbeiter holen sich jeweils das oberste Element.

Redis ist vor allem auf hohe Geschwindigkeit ausgerichtet: Die Daten werden meistens im Speicher gehalten und asynchron auf die Platte geschrieben oder auch auf andere Server repliziert. Dadurch erreicht Redis eine sehr hohe Performance: Beim Lesen lassen sich die Daten direkt aus dem RAM auslesen, und beim Schreiben blockiert der Zugriff auf die Festplatte das System nicht, weil er asynchron im Hintergrund ausgeführt wird. Durch Replikation lässt sich der Lese-Durchsatz weiter erhöhen, indem zusätzliche Server für Lese-Operationen zur Verfügung gestellt werden.

Wenn so viele Daten zu verwalten sind, dass sie nicht mehr in den Speicher passen, kann eine Redis-eigene Virtual-Memory-Verwaltung die Daten auch auf die Platte auslagern. Darüber hinaus ist es möglich, ähnlich wie in einem Cache, die Daten mit einer Lebensdauer (Time to Live = TTL) auszustatten, nach der sie aus der Datenbank verschwinden.

Redis arbeitet mit Master-Slave-Replikation. Das heißt, es gibt einen Master-Server für Lese- und Schreiboperationen und beliebig viele Slave-Server. Diese können lediglich Leseoperationen abarbeiten und werden ständig mit dem Master synchronisiert. Bei einem Failover übernimmt einer der Slave-Server die Rolle des ausgefallenen Masters. Aufgrund dieser Master-Slave-Rollenaufteilung kann Redis starke Konsistenz garantieren.

Sharding soll folgen

Eine Cluster-Funktion mit Sharding ist für Redis geplant. Bei Sharding handelt es sich um ein Verfahren zur Aufteilung von großen Datenmengen auf mehrere Datenbank-Server. Ein Beispiel sind Kunden, die je nach Region auf einem anderen Server gespeichert oder nach Kundennummer aufgeteilt werden. Durch Sharding kann es mehrere Master geben, die für jeweils einen Teil der Daten verantwortlich sind. Außerdem wird an der Möglichkeit gearbeitet, in der Datenbank Skripte in der Sprache Lua auf die Daten anzuwenden. Unter http://try.redis-db.com besteht die Möglichkeit, eigene Erfahrungen mit der Datenbank ohne Installation zu sammeln.

Im Video: NoSQL-Datenbanken - Redis

Zum Video: Datenflut bereitet NoSQL den Weg

Apache Cassandra

2007 begann Facebook mit der Entwicklung einer proprietären Lösung zum Speichern und Suchen von Benutzernachrichten für die Inbox-Suche. Das war die Geburtsstunde von Cassandra, das inzwischen zu den Top-Level-Projekten der Apache Software Foundation gehört. Die neue Datenbank sollte auf kostengünstigen Commodity-Servern laufen und inkrementell skalierbar sein, um dem wachsenden User Generated Content langfristig Herr zu werden.

Cassandra gehört zur Familie der Wide Column Stores und lässt sich als hochskalierbarer, schlussendlich konsistenter, verteilter und strukturierter Schlüssel-Wert-Speicher beschreiben. Hochskalierbar bedeutet, dass ein Cassandra-Cluster durch Hinzufügen weiterer Server horizontal skaliert werden kann. Auf diese Weise sind riesige Datenmengen auch mit Commodity-Hardware verwaltbar. Hochverfügbarkeit wird durch Replikation und Verteilung der Daten auf mehreren Servern garantiert. Dabei kann der Ort für die Replikate so gewählt werden, dass diese sich in verschiedenen Rechenzentren befinden. Schlussendlich konsistent (eventually consistent) bedeutet, dass innerhalb eines begrenzten Zeitfensters nicht immer alle User die gleiche Sicht auf die Daten haben. Dadurch kann eine bessere Performance gewährleistet werden.

Cassandra unterstützt verschiedene Konsistenzstufen für Lese- und Schreiboperationen, um den Spagat zwischen Konsistenz und Performance für den jeweiligen Anwendungsfall zu meistern. Das System wurde in Java entwickelt und kann daher auf praktisch allen Plattformen eingesetzt werden. Client-Bibliotheken auch für andere Programmiersprachen wie Python, PHP und C# sind vorhanden. Die Daten werden in Form von mehrfach ineinandergeschachtelten Schlüssel-Wert-Paaren gespeichert. Das Datenmodell ist strukturiert, aber schemalos und daher sehr flexibel. Durch die Integration der Apache-Hadoop-Technik unterstützt Cassandra ebenfalls Map- Reduce zur nebenläufigen Verarbeitung großer Datenmengen im Computer-Cluster.

Mehrfach praxiserprobt

Cassandra verwendet wie Redis Sharding und Replikate, aber es gibt keine Unterscheidung zwischen Master- und Slave-Servern. Mit diesem Ansatz wird die Schreib-Performance verbessert, starke Konsistenz kann jedoch nicht garantiert werden. Während Redis auf Konfliktvermeidung ausgelegt ist, arbeitet Cassandra mit Mechanismen zur Konfliktauflösung.

Cassandra wird von Unternehmen wie Facebook, Twitter, Cloudkick und Rackspace erfolgreich eingesetzt und stellt damit seine Zuverlässigkeit und Reife unter Beweis. Weitere Informationen zu Cassandra gibt es unter http://cassandra.apache.org.

CouchDB

CouchDB steht für "Cluster of unreliable Commodity Hardware Database". Bei diesem seit 2005 laufenden Projekt handelt es sich um einen Document Store. Der Vorteil dieser Datenbank ist, dass Dokumente sowohl dem natürlichen Objekt als auch dessen Repräsentation in einer objektorientierten Sprache entsprechen können. Ferner muss der Aufbau der Dokumente vor der Speicherung nicht bekannt sein, denn es handelt sich bei CouchDB um eine schemalose Datenbank.

Keine Schreib-Lese-Blockaden

Die Dokumente werden im JSON-Format verwaltet. Dabei versieht die Datenbank jedes JSON-Objekt mit einem eindeutigen Schlüssel und mit einer Versionsnummer. Mit Hilfe der Versionsnummer verwaltet CouchDB die konkurrierenden Zugriffe. Dazu wird die Versionsnummer bei jeder Änderung eines Dokuments erhöht. CouchDB erkennt beim Schreiben die Konflikte und meldet sie dem jeweiligen Client. Die bei anderen Systemen durch Locking entstehenden Schreib-Lese-Blockaden treten somit nicht auf. Dieses System, Multi-Version Concurrency Control genannt, wird auch bei der Replikation verwendet, um Konflikte zu entdecken und zu beheben.

Um auf Dokumente nicht nur anhand des Schlüssels zuzugreifen, verbindet CouchDB den dokumentenorientierten Ansatz mit der von Apache Hadoop bekannten MapReduce-Technik. Diese Abfragen werden bei CouchDB als "View" bezeichnet. Eine Abfrage stellt dabei eine Sicht auf die Daten dar und verändert diese nicht. Sie besteht aus einer Map- und aus einer optionalen Reduce-Funktion. Beide werden in Javascript beschrieben und können in CouchDB hinterlegt werden. Permanente Views werden, im Gegensatz zu temporären Views, als Design-Dokumente bezeichnet, die von CouchDB indiziert werden. Ein performanter Zugriff ist somit gewährleistet. Das Ergebnis der Views sind Schlüssel-Werte-Paare. Dabei besteht sowohl der Schlüssel als auch der Wert aus einem JSON-Dokument.

Der Zugriff auf Daten erfolgt über eine HTTP-REST-Schnittstelle. Für viele Programmiersprachen sind zusätzlich Bibliotheken verfügbar. Die Administration erfolgt per HTTP-REST oder über die Web-Oberfläche Futon. Mit dem in CouchDB integrierten Javascript-Web-Framework CouchApp lassen sich Web-Anwendungen erstellen, die direkt in der CouchDB laufen. Ein zusätzlicher Web-Server entfällt dabei.

Schwach ausgeprägte Konsistenz

CouchDB verfügt über einen inkrementellen Replikationsmechanismus mit schwacher Konsistenz und bidirektionaler Konfliktbehandlung: Konflikte durch Änderungen an einem Objekt auf verschiedenen Servern werden erkannt und behandelt. Dabei bleiben alle Versionen erhalten. Die Replikation lässt sich sehr einfach für fortlaufende Replikation einrichten oder ad hoc verwenden. Horizontale Skalierung durch Sharding beherrscht CouchDB nicht. Nur durch zusätzliche Produkte, die als Proxy zwischen Client und Datenbank arbeiten, kann Sharding realisiert werden. Das Open-Source-Projekt BigCouch bietet ebenfalls eine skalierbare Lösung für CouchDB an.

Die Datenbank ist zum größten Teil in der Programmiersprache Erlang geschrieben und für die meisten Plattformen verfügbar. Sogar auf einem Android-Smartphone oder auf einem iPhone kann eine CouchDB-Instanz betrieben werden. Auch Cloud-Angebote wie Cloudant und Iris Couch lassen sich nutzen.

CouchDB als Download sowie weitere Informationen zum Thema bieten die Apache Software Foundation (http://couchdb.apache.org) und die Firma Couchbase Inc. (http://www.couchbase.com). (ph)

Im Video: NoSQL-Datenbanken - CouchDB

Zum Video: Datenflut bereitet NoSQL den Weg