Pluspunkt Replikation

Wie schon erwähnt ist die Replikation eins der herausragenden Features von Couch-DB. Zwar verfügen auch klassische relationale Datenbanken über Replikation, aber bieten kein einfaches Interface, um mit Konflikten umzugehen, die auftreten können, wenn an beiden Enden der Replikation Änderungen stattfinden. Einrichten lässt sich die Replikation im Webinterface oder wieder mit einem REST-Aufruf. Der API-Endpunkt hierfür heißt "_replicate". Die beiden wichtigen Parameter in den JSON-Daten lauten "source" und "target":

curl -X POST -H "Content-Type: application/json" http://192.168.2.112:15984/_replicate -d '{"source": "movies", "target": "http://192.168.2.114:15984/movies"}'

Kommt es zu Konflikten, löst CouchDB sie einfach auf, indem es beide Versionen des problematischen Dokuments abspeichert. Generell wird ja bei Änderungen gemäß dem CouchDB zugrunde liegenden Speichermodell MVCC (Multi-Version Concurrency Control) sowieso eine neue Version eines Dokuments erzeugt, um konkurrierende Zugriffe zu vermeiden, die nur mit Locks abzusichern sind. Allerdings bekommt der Anwender normalerweise vom Konflikt nichts mit. Hier muss der Entwickler sicherstellen, die Datenbank auf eventuell vorhandene Konflikte zu prüfen und dem Anwender einen Dialog zu präsentieren, in dem er auswählen kann, wie er mit dem Konflikt umgehen möchte.

Sicherheit und Performance

Am sichersten ist eine CouchDB-Installation zweifellos, wenn sie gar nicht über das Internet erreichbar ist, sondern eine Anwendung die Datenbank nur über die Localhost-Verbindung verwendet. Sollen beispielsweise JavaScript-Webclients direkt aus dem Browser auf die Datenbank zugreifen können, müssen Sie unter Umständen Sicherheitsmaßnahmen wie die Same-Origin-Policy abschalten, die dafür sorgt, dass nur Rechner aus derselben Domain die Datenbank kontaktieren dürfen. Dazu aktivieren Sie in der CouchDB-Konfiguration die CORS-Option (Cross-Origin Resource Sharing). Hier können Sie entweder Wildcards oder einzelne Hosts eintragen, die auf die Datenbank zugreifen dürfen. Die restriktivste Option ist hierbei die beste.

Hinsichtlich der Performance gibt es viele Aspekte zu beachten. Das beginnt schon bei der ID der Dokumente, für die es mehrere Optionen gibt. In der Default-Konfiguration verwendet CouchDB zufällige UUIDs, was aber dazu führt, dass beim Upload vieler Dokumente die interne Speicherstruktur immer wieder umgeschrieben werden muss. Weniger Overhead erzeugt hier die Verwendung der fortlaufenden IDs. Die CouchDB-Dokumentation empfiehlt generell, die IDs (fortlaufend) in der eigenen Anwendung zu erzeugen, aber dies erfordert logischerweise höheren Programmieraufwand.

Eine andere Stellschraube, an der Admins drehen können, um die Performance zu verbessern, ist beispielsweise der zugrunde liegende Storage. Schnellere Disks und Dateisysteme oder Striped RAIDs können helfen, aber die Dokumentation hat noch einen besonderen Trick auf Lager, der sich auszuprobieren lohnt. Die Erlang-VM kann auf Wunsch Dateioperationen parallel in mehreren Threads ausführen, was sich mit der Kommandozeilenoption "+A" erreichen lässt. Dazu fügen Sie diese Anweisung in die Datei "/usr/local/etc/ defaults/couchdb" ein:

export ERL_FLAGS="+A 4"

Für mehr Schreibperformance sorgt eine Anweisung in der CouchDB-Konfiguration, die gleichzeitig die Datensicherheit etwas verringert. Mit "delayed_commits" wartet der CouchDB-Server eine Zeit lang, bis er die Änderungen auf die Festplatte schreibt. Mehr Informationen dazu und zu weiteren Maßnahmen sind im Performance-Kapitel der Dokumentation zu finden. Für größere Installationen gibt es auch Hinweise dazu, wie Sie die Ressource Limits, etwa für offene Netzwerkverbindungen und Files, erhöhen.

Andere Stellschrauben, an denen ein CouchDB-Admin drehen kann, sind die Compaction-Einstellungen, die festlegen, wann und wie alte Datenbank-Objekte entsorgt werden. Normalerweise speichert die Datenbank nämlich immer neue Revisions von Dokumenten ab. Auch wenn ein Datensatz "gelöscht" wird, ist er eigentlich noch da, einschließlich diverser Vorgängerversionen. Compaction reduziert den immer weiter wachsenden Speicherbedarf der NoSQL-Datenbank.