Middleware oder Cluster

Einen generischen Ansatz verfolgt die Skalierungs-Middleware Gizzard [7]. Sie operiert zwischen einer Webanwendung, die Datenbankabfragen abschickt, und beliebigen Datenbanksystemen. Diese Vorgehensweise hat den Vorteil, dass sie im Gegensatz zum Consistent Hashing eine heterogene Partitionierung gestattet, sodass sich etwa häufig abgefragte Daten Performance-fördernd segmentieren lassen. Daneben kann man Forwarding-Strategien individuell festlegen.

Außerdem gestattet es Gizzard, Ressourcen dynamisch zum Cluster hinzuzufügen, was dem System Elastizität verleiht. Das System verhält sich sehr robust, da es beim Ausfall einer Partitionsreplik Requests dynamisch umleitet. Für den Fall, dass eine gesamte Partition nicht mehr erreichbar sein sollte, puffert Gizzard die ausstehenden Schreiboperationen in einem Transaktionsjournal.

Das jüngste und aktivste Upscaling-Projekt im Couch-DB-Umfeld ist jedoch Bigcouch [8], das sich stark an die konzeptionellen Ansätze aus dem Amazon Dynamo anlehnt. Dieser Couch-DB-Fork der Firma Cloudant arbeitet ebenfalls als elastischer Cluster und partitioniert die Daten auf Basis von Consistent-Hashing-Algorithmen. Daneben hält die Software View-Indizierung auf jeder Partition parallel vor, was zu deutlichen Performancegewinnen im Vergleich zu Standalone-Systemen führt. Neben der Gesamtanzahl von Knoten innerhalb eines Clusters steuern folgende vier Parameter Bigcouch dynamisch:

• Der Grad der Partitionierung als Anzahl »Q« der Shards eines Clusters.
• »N« , die Anzahl redundanter Kopien eines jeden Dokuments. (Die Empfehlung lautet »N > 2« .)
• Die Anzahl der Kopien, die gespeichert werden müssen, bevor ein Dokument "gespeichert" ist (»W« ). »W« ist damit die Stellschraube für die Konsistenz der Daten. »W=N« bedeutet vollständige Konsistenz, »W=1« führt zu maximalem Durchsatz.
• »R« , die verlangte Anzahl identischer Dokumentrepliken, bevor ein Lese-Request erfüllt ist. Während »R=1« eine minimale Latenz bedeutet, erzwingt »R=N« wiederum eine vollständige Konsistenz aller Dokumentkopien.

Standardmäßig erscheint Bigcouch auf Port 5984 dem Benutzer wie eine einzelne Couch-DB-Instanz. Daneben existiert aber auf Port 5986 die Möglichkeit, zu Administrationszwecken die einzelnen Nodes des Clusters direkt anzusprechen.

Couch DB stellt sich in drei verschiedenen Ausprägungen dar. Einerseits lädt es zum Downscaling auf Mobilgeräten ein, weil es geringe Ansprüche an die Hardware stellt. Zweitens erlaubt die Datenbank die horizontale Skalierung wie in früheren Lotus-Notes-Anwendungsszenarien. Die Web-2.0-Skalierung begegnet hoher Last und sehr großen Datenvolumina.

Der magische "Glue", der diese unterschiedlichen Ausprägungen von Dezentralität möglich macht, besteht in der Fähigkeit von Couch DB, nicht nur Daten, sondern auch das Design von Anwendungen einfach und sehr robust zu replizieren.

Ausblick

Das Couch-DB-Universum zeigt sich dynamisch und innovativ. Mittel- bis langfristig gibt es aber noch einiges Potenzial auszuschöpfen. Die Möglichkeit, beispielsweise mit einem Form-Builder extrem einfach Couch-DB-Anwendungen für kleine und mittlere Unternehmen nutzbar zu machen, könnte einen bedeutenden Schub für Akzeptanz und Verbreitung der Software bewirken.

Kurzfristig ist für die kommende Version 1.1 mit einer verbesserten externen Programmierschnittstelle zu rechnen. Damit soll sich Couch DB auch als Reverse-Proxy konfigurieren lassen und externe Prozesse verwalten können. (mhu)

Der Autor

Sven Pöhler beschäftigt sich mit Linux bereits seit Kernelversion 0.96. Er ist seit vielen Jahren im Bereich Software-Entwicklung und IT-Infrastruktur tätig. Er arbeitet für ein ID-Hochsicherheitsunternehmen.