Request-basiert

Abbildung 3 zeigt exemplarisch eine solche Anwendungsarchitektur. Ein Nutzer, der eine Änderung in der Replik der Applikation auf dem Berliner Server umsetzen möchte, erstellt dafür ein Request-Dokument in der Request-Datenbank. Die Anwendungskonfiguration (in der Config-DB) bestimmt, dass alle Änderungen der Daten ausschließlich auf dem Münchener Server umzusetzen sind. Das Request-Dokument repliziert auf den Münchener Server, wo der Request ausgeführt wird.

Da sich derzeit in Couch DB Leseberechtigungen nur datenbankweit vergeben lassen, ist es sinnvoll, derartige Konfigurationsinformationen in einer separierten Konfigurationsdatenbank abzulegen, die dann ebenso Teil der replizierenden Anwendungssuite wird.

Nicht direkt ein Designprinzip, aber dennoch dazu geeignet, die Wahrscheinlichkeit von Datenkonflikten zu verringern, sind Maßnahmen zur möglichst schnellen Verbreitung von Änderungen. Bewährt hat sich hierfür die Hub-Spoke-Topologie: Die Clients (Spokes, Speichen) replizieren jeweils mit einer Zentralinstanz (Hub, Nabe). Die Hubs gleichen ihren Datenbestand untereinander mit hoher Frequenz ab, sodass auch topologisch entfernte Clients Änderungen schnell erfahren.

Hintergrundprozesse

Couch DB galt anfänglich als nur für kleine bis mittlere Anwendungs-Setups geeignet. Ein typisches Szenario war das private Adressbuch, das zwischen Smartphone, Notebook und heimischem PC hin und her repliziert. Durch Umsetzung der oben genannten Designprinzipien lassen sich aber auch komplexere Anforderungen bedienen. Jedoch spätestens wenn Eskalationen, SLAs und Notifikationen Teil der Anforderungen werden, sind zeitgesteuerte Hintergrundprozesse notwendig. Bedauerlicherweise existiert in Couch DB bisher kein interner Scheduler, um Hintergrundprozesse anzustoßen. Natürlich lässt sich beispielsweise unter Linux der Cron-Daemon als Scheduler benutzen, die Nachteile eines solchen Designbruchs sind jedoch Plattformabhängigkeit, nicht konsistente Berechtigungen und die Unmöglichkeit, derartige anwendungsrelevante Konfigurationen in die Replikation einzubeziehen.

Weniger die Dezentralität von Anwendungen als vielmehr die massive Skalierung sind der Fokus einiger interessanter Projekte im Ökosystem rund um Couch-DB. Es existieren bereits verschiedene Lösungen und Ansätze, um horizontale Skalierung über mehrere Knoten zu verwirklichen.

Couch-DB-Lounge [5] ist ein Framework zur Partitionierung per HTTP-Reverse-Proxy und basiert auf dem Webserver/Proxy Nginx. Es umfasst ein Nginx-Modul sowie einen Python-Daemon und arbeitet als Consistent Hashing-Ring über alle Dokumente. Mit Hilfe der Datei »shards.conf« lässt sich die Datenpartitionierung (Sharding) definieren. Daten-Failover mit verschiedenen Nodes ist möglich.

Eine weitere Möglichkeit für die Partitionierung bietet Pillow [6]. Es stammt von dem Norweger Knut Hellan, der in dem überschaubaren Softwareprojekt insbesondere seine eigenen Anforderungen an die Fähigkeit zum automatischen Resharding umgesetzt hat.

couchapp generate Anwendung

cd Anwendung/
couchapp generate show Funktion

couchapp push http://localhost:5984/Anwendung