Apache CouchDB Eine Datenbank für das Web

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

QUNIS GmbH

Confluent Germany GmbH

Mit der Open-Source-Datenbank CouchDB speichern Entwickler ihre Daten über JSON-Dokumente. Der Zugriff kann über einen Webbrowser mit HTTP erfolgen. Die gespeicherten Dokumente lassen sich mit JavaScript transformieren. Der Vorteil der Datenbanklösung ist, dass diese auch mit modernen Apps zusammenarbeiten kann und mobil funktioniert.

Apache CouchDB orientiert sich grundsätzlich an Google BigTable und stellt eine schemafreie, dokumentenoriente Datenbankstruktur zur Verfügung. Als Datenspeicher dienen JSON-Dokumente, der Zugriff erfolgt über HTTP und REST, angebunden über den Standardport 5984. Lizenziert wird die Datenbank über die Apache-Lizenz.

Big Data mit der Google Cloud Platform

So funktionieren Datenanalysen mit BigTable und Co.

CouchDB ist grundsätzlich schemafrei. Erst nachdem Daten in der Datenbank abgelegt wurden, können diese strukturiert werden. Das ist bei dem dokumentenorientierten Ansatz auch sinnvoll. CouchDB steht als Windows-Version zur Verfügung, aber auch für die Installation auf Mac OS X und Linux-Servern. Die Verwaltung der Datenbank erfolgt über ein Web-Interface. Die Installation ist in Sekunden abgeschlossen, sodass sich Entwickler recht schnell einen Überblick über die Möglichkeiten der Datenbank verschaffen können.

Vorteile der dokumentenorientierten Datenbank-Speicherung

Der dokumentenoriente Speicheransatz in CouchDB hat durchaus seine Vorteile. Im Vergleich zu gedruckten Daten in Unternehmen, zum Beispiel einer Rechnung, lassen sich dadurch in einem Datensatz alle relevanten Daten abspeichern. Denn eine Rechnung enthält die Adresse des Käufers, die Kundennummer, die Produktnummer des verkauften Produktes, den Preis, das Datum der Lieferung sowie zahlreiche weitere Informationen, welche der entsprechenden Transaktion deutlich zugewiesen werden können. Ähnliches gilt für Visitenkarten. Auch hier sind alle Informationen zu einer Person an einer zentralen Stelle gespeichert. Speichern Unternehmen eine Visitenkarte zum Beispiel in CouchDB, so enthält auch hier der Datensatz alle relevanten Informationen.

Wenn auf diesem Weg auch die Daten in einer Datenbank gespeichert werden, lassen sich in einem Datensatz alle relevanten Informationen einer Transaktion abrufen und verarbeiten. Vor allem in Big-Data-Umgebungen können dadurch wesentlich effizienter Daten gespeichert und verarbeitet werden. Sobald Unternehmen ähnliche Daten speichern, in diesem Beispiel also Visitenkarten und Rechnungen, sind die Dokumente ähnlich aufgebaut, unterscheiden sich nur im Inhalt der Daten. Daher ist die dokumentenorientierte Speicherung in CouchDB beim Speichern ähnlicher Daten sehr leistungsstark.

Bei der Speicherung in herkömmlichen, relationalen Datenbanken, werden die entsprechenden Informationen in verschiedenen Zeilen und Tabellen gespeichert. Benötigt ein Anwender alle Daten zu einer bestimmten Person, oder in diesem Beispiel Rechnung, dann muss die Datenbank diese erst zusammentragen. Das ist beim Einsatz von CouchDB nicht notwendig.

Stabiler Zugriff, auch bei starker Last

Eine der Stärken von CouchDB liegt außerdem darin, dass auch bei sehr hoher Last alle Anfragen beantwortet werden. Auch wenn die Anfragen an einen Server stark ansteigen, löscht CouchDB keine veralteten Anfragen, sondern beantwortet diese nacheinander. Es kann daher durchaus passieren, dass die Leistung der Anfragen etwas nach unten geht, dennoch werden keinerlei Anfragen an den Server abgelehnt. Bei diesem Vorgang gehen also keine Informationen verloren. Sinkt die Last wieder, steigt die Leistung des Servers an, da er Anfragen wieder schneller beantworten kann.

CouchDB verwendet MapReduce, um die Ergebnisse eines View zu berechnen. Der Zugriff auf Dokumente und Views erfolgt in CouchDB auf Basis von Schlüsseln oder Schlüsselbereiche. Das führt dazu, dass die Zugriffsgeschwindigkeit deutlich erhöht wird. Außerdem erhalten Entwickler dadurch die Möglichkeit, Daten auf verschiedene Cluster-Knoten zu partitionieren. Dennoch besteht auch hier weiterhin die Möglichkeit, jeden Clusterknoten getrennt zu verwenden. Dieser Sachverhalt ist besonders wichtig, da Google BigTable, Hadoop und andere Big Data-Lösungen nach dem gleichen Prinzip vorgehen.

Mit CouchDB haben Entwickler auch die Möglichkeit, Datenbank-Instanzen zu erstellen, die auf eine niedrige Leistung ausgelegt sind. Das ist zum Beispiel dann sinnvoll, wenn die Clients, die mit der Datenbank arbeiten, über langsamere Internetleitungen miteinander verbunden sind. Grundsätzlich besteht sogar die Möglichkeit, eine Instanz der Datenbank auf einem Tablet oder einem Smartphone zu betreiben. Sinnvoll ist das vor allem für mobile Anwender, die auch offline Zugriff auf wichtige Daten erhalten müssen. In diesem Zusammenhang ist auch die Replikation interessant, die wir in diesem Beitrag ebenfalls behandeln.

Daten in CouchDB ändern – Multi-Version Concurrency Control

Speichern Unternehmen ihre Daten in relationalen Datenbanken, dann werden beim Schreiben von Daten die entsprechenden Zeilen gesperrt. Das soll verhindern, dass Anwender sich gegenseitig Daten überschreiben. Das Problem liegt dann darin, dass viele Clients darauf warten müssen, bis andere Clients ihre Arbeit mit der Datenbank, beziehungsweise der entsprechenden Zeile, beendet haben. Beim Einsatz von CouchDB werden keine Zeilen blockiert.

Hier arbeitet die Datenbank mit dem sogenannten Multi-Version Concurrency Control (MVCC). Durch diese Technik ist es nicht mehr notwendig, dass Zeilen gesperrt werden, wenn mehrere Anwender gleichzeitig auf diese zugreifen. Vor allem bei hoher Last, also wenn viele Anwender gleichzeitig auf die Daten zugreifen, ist das ein echter Vorteil. Denn CouchDB kann weiterhin parallel anfragen beantworten, ohne einzelne Clients zu benachteiligen.

MVCC arbeitet mit der Versionierung der gespeicherten Dokumente. Speichern Anwender in einem Dokument neue Daten, dann legt CouchDB eine neue Version des entsprechenden Dokumentes an. Wenn zum Beispiel ein Anwender ein Dokument liest, während ein zweiter Anwender das Dokument bearbeitet, erstellt CouchDB für den zweiten Anwender eine neue Version des Dokumentes.

Sobald die Bearbeitung abgeschlossen ist, wird diese Version an die Datenbank angehängt. Greift jetzt ein dritter Anwender auf das Dokument zu, erhält er lesenden Zugriff auf die neue Version. Die erste Anfrage kann aber weiterhin mit der ursprünglichen Version des Dokumentes arbeiten. In dieser Infrastruktur können also alle drei Anwender uneingeschränkt leistungsstark mit der Datenbank arbeiten.

Replikation der Daten möglich

Die Datenbanken in CouchDB lassen sich natürlich auch replizieren. Dadurch haben Entwickler die Möglichkeit, Daten auf verschiedene CouchDB-Server zu synchronisieren. Das erlaubt auch den Aufbau eines Clusters. Hier besteht die Möglichkeit zum einen eine Hochverfügbarkeit zu erreichen, zum anderen aber auch einen gewissen Lastenausgleich. Auch eine Spiegelung der Daten über geografisch verteilte Standorte ist problemlos möglich. Dadurch lassen sich auch Geo-Cluster erstellen.

Geht während der Replikation die Datenverbindung verloren, dann muss die Replikation nicht neu starten, sondern startet exakt an dem Datensatz, an dem die Replikation abgebrochen wurde. Das ist ideal für eine internetbasierte Replikation. Die Replikation baut ebenfalls auf HTTP auf. CouchDB ist darüber hinaus in der Lage, auf allen Knoten Änderungen zu speichern und diese mit den anderen Knoten zu synchronisieren.

Bei der Anbindung von Clients an replizierte Datenbank-Server, auf Basis von CouchDB, haben Entwickler die Möglichkeit festzulegen, ob der Zugriff auf die Daten konsistent oder verfügbar sein soll. Bei der konsistenten Anbindung von Clients wird sichergestellt, dass alle angebundenen Server über identische Daten verfügen. Denn wenn die Daten nicht konsistent bereitstehen, besteht die Möglichkeit, dass der Client, der mit Server A verbunden ist, andere Daten erhält als ein Client, der mit Server B verbunden ist. Natürlich dauert die Synchronisierung der Daten einige Zeit, sodass in einer solchen Infrastruktur nicht zahlreiche Anwender leistungsstark arbeiten können – zum Beispiel bei der Verarbeitung von Big Data.

Sollen die Clients verfügbar verbunden werden, spielen konsistente Daten keine Rolle. Hier besteht durchaus die Möglichkeit, dass ein Client etwas andere Daten angezeigt bekommt, als ein anderer Client. Allerdings ist dadurch die Verfügbarkeit gegeben und es ist bei manchen Umgebungen besser, wenn die Daten etwas veraltet sind, als dass ein Benutzer gar keine Daten sieht. Welche Option hier sinnvoll ist, müssen Entwickler selbst entscheiden. Vor allem in Umgebungen, bei denen die Leistung zählt, also vor allem bei der Verarbeitung von Big-Data-Informationen, ist es selten sinnvoll, dass ein Datenbank-Knoten auf die Synchronisierung wartet, nur um auf den letzten Stand zu sein.

(ID:43944771)