Administrativer Blick auf NoSQL Datenbanken

Installation und Konfiguration

Die Installation erfolgt über den Installer, der von der CouchDB Webseite heruntergeladen werden kann, bzw. auf Linux über das Paketmanagement. Nach der Installation ist unter http://localhost:5984/_utils/ die Administrationsoberfläche zu erreichen.

Beim ersten Öffnen der Oberfläche wird man gefragt, ob man einen Single-Node oder einen Cluster aufsetzen möchte. Die Cluster Konfiguration braucht die Freigabe der Ports 9100 bis 9200 und einige Einstellungen in der lokalen Erlanginstallation. Erlang ist eine Programmiersprache für hochverteilte Systeme, die Ericsson in den 80igern für die Entwicklung ihrer Telefonnetzkomponenten kreierte.

Die Single-Node Konfiguration ist deutlich einfacher, sie beschränkt sich auf das Anlegen eines Adminusers.

Nach dem Einrichten ist es oft ratsam die Binding-Adresse auf die öffentliche IP des Gerätes zu ändern und CORS zu aktivieren.


CouchDB hat eine sehr gute Performance selbst bei schwacher Hardware, sodass Hosting von CouchDB Instanzen relativ günstig ist, bzw. beim Kunden nur wenig Ressourcen bindet.

In der Datenbank Übersicht lassen sich neue Datenbanken erstellen und vorhandene verwalten.

Die Actions, die jede Datenbank zur Verfügung stellt sind Replikation, Rechte verwalten und Löschen, dazu erhält man die Anzahl an Dokumenten und die Größe der Datenbank auf dem Datenträger.

Ausfallsicherheit, Replikation und Skalierbarkeit

CouchDB besitzt selbst keine Mechanismen, die die Ausfallsicherheit herstellen. Das muss administrativ erfolgen, zum Beispiel über einen Loadbalancer. Durch die Master-Master-Replikation und den Einsatz eines Load-Balancers ist Hochverfügbarkeit möglich.

Eine Replikation lässt sich in der Datenbankübersicht konfigurieren, durch einen Klick auf den Button wird man in den Konfigurationsdialog geführt.

Hier hat man die Möglichkeit eine lokale oder auch eine entfernte Datenbank als Quelle anzugeben, beim Ziel hat man die Auswahl zwischen bestehenden lokalen und entfernten, sowie neuen lokalen und entfernten Datenbanken. Um eine entfernte Replikation zu konfigurieren muss man einen im Zielsystem entsprechend berechtigten Account angeben.

Als Option kann man den Typ der Replikation auswählen, dies kann entweder eine einmalige oder eine kontinuierliche Replikation sein.

Die Master-Master-Replikation, die für Hochverfügbarkeit gebraucht wird, lässt sich realisieren, indem in beiden Knoten Replikationen eingerichtet werden, die jeweils in die andere Maschine schreiben.

Die schnelle Replikation der Daten auf die Slaves erlaubt eine sehr gute Skalierbarkeit von CouchDB Instanzen.

Zugriffssteuerung

CouchDB unterscheidet nur zwei Arten von Permissions: Datenbankzugriff und Datenbankadministration, wer Zugriff auf eine Datenbank hat kann alle Daten in ihr lesen. Außerdem hat CouchDB ein Usersystem, dass nicht mit einem Active Directory kompatibel ist. Für die Authentifizierung kann man mit einem Reverse Proxy arbeiten, zum Beispiel kann NGNIX die Kommunikation mit dem Active Directory übernehmen und die Anfragen an CouchDB weiterleiten.

Über Validierungsfunktionen kann man im Design Dokument /DatenbankName/_design/_auth steuern welcher User welches Objekt bzw. welche Eigenschaften ein User schreiben kann. Die Funktion hat als Parameter das zu validierende Dokument, dessen aktuellen Stand in der Datenbank, den UserContext und ein Objekt um auf das Security Backend von CouchDB zuzugreifen.

Um Leserechte zu realisieren muss man Dokumente mit unterschiedlichen Usern, die sie lesen können in unterschiedlichen Datenbanken gespeichert werden. Leseberechtigungen auf Dokumentenebene, wie im SharePoint gibt es nicht.

Backups

Die empfohlene Methode Backups von einer CouchDB zu machen ist sie in eine andere CouchDB zu replizieren, dies entweder regelmäßig über einen Webrequest anzustoßen, oder als kontinuierliche Replikation einzurichten.

Über das Dateisystem lassen sich ebenfalls Backups machen. Hierzu kann der Ordner, der die Datenbankdateien enthält kopiert werden. Da CouchDB auf ein Append Only Storage setzt ist dies jederzeit möglich, außer wenn die Datenbank kompaktiert wird.