Ich hatte gestern Abend das Vergnügen, von Jan Lehnhardt eine Präsentation über die CouchDB zu sehen. Man denkt sich natürlich gleich: «Yet another database engine». Aber das stimmt so nicht, denn CouchDB ist keine typische relationale Datenbank wie MySQL, sondern basiert auf Dokumenten. Jeder, der schon einmal etwas mit Lotus Notes gemacht hat, weiß wovon ich rede. Man hat pro Datensatz ein Dokument (ähnlich wie die Zeile in einem RDBMS), welches wiederum Attribute mit Werten beinhaltet. Diese Attribut-Wert-Paare sind als JSON-Arrays im Dokument gespeichert.

Am Beispiel eines registrierten Users auf einer Website sähe das dann so aus:

{  
  "username": "MyUsername"  
  "password": "EncryptedPassword"  
  "enabled": 1  
}

Diesen Inhalt gibt die Datenbank dann auch genauso zurück und jede halbwegs aktuelle Programmiersprache kann das JSON dann von Haus aus dekodieren. Der Zugriff auf die Datenbank ist so simpel, dass es wirklich jede Programmiersprache unterstützt, die TCP kann, da man über HTTP mit einer REST-API darauf zugreift. Man ruft also URLs mit den HTTP-Methoden GET, POST, PUT oder DELETE auf und kann damit entsprechende Abfragen tätigen.

Dies erzeugt bei lokalen Datenbank nicht so viel Overhead, kann aber durch das HTTP/REST wunderschön gecached werden. CouchDB selbst ist in Erlang geschrieben und ist damit sogar in 10 Jahren, wenn wir mehrere hundert Prozessorkerne im Server haben, noch up-to-date, wo andere Datenbanksysteme zwecks der Lastverteilung noch mächtig nachholen werden müssen.

Ähnlich wie bei Lotus-Notes kann man die Datenbank auch verteilt betreiben und replizieren, da alle Dokumente versioniert sind und die Datenbank sehr gute Replikationsalgorithmen dafür hat. Durch diese Versionierung hat man sogar Konfliktdokumente, wenn mal ein Datensatz von mehreren System geändert wurden und dann drüberrepliziert werden. Dies ist vielleicht im Web nicht so der Alltag aber lösbar und eigentlich auch etwas, was man will. Denn diese Konfliktdokumente werden auch versioniert und man hat keinen Datensatzverlust. Man kann sich für diesen Zweck Mergescripts schreiben, die solche Probleme dann automatisch lösen, denn wenn auf einer DB nur der Username und auf einem anderen Server nur das Passwort geändert wurden, sollte das kein Problem für ein Script darstellen, da man ja schauen kann, was sich seit der letzten Version wirklich geändert hat.

Diese Replikationen muss man allerdings im Gegensatz zu anderen DBMS manuell anstoßen. D.h. man lässt sich von CouchDB an ein Script Bescheid geben, dass Datensätze geändert wurden, und dieses Script kann dann je nach belieben z.B. nach 1000 Transaktionen die Replikation zu anderen DB-Servern anstoßen. Das hat Vor- allerdings auch Nachteile. Das kann aber jeder bei Projektbeginn bedenken und ein anderes System benutzen 🙂

Natürlich hat man bei solchen dokumentbasierten Datenbanken das Problem, dass man ja nicht immer den Key kennt, nachdem man in der Datenbank nach einem Datensatz sucht. Dafür gibt es in CouchDB Views. Diese darf man aber nicht so recht mit Views aus RDBMS vergleichen, sondern eigentlich ist es ein Index auf der Datenbank, den man abfragen kann. Diese Indexe/Views werden per JavaScript-Syntax festgelegt und lazy aktualisiert. Es gibt in der CouchDB eine Storage- sowie eine Index-Engine. Diese Index-Engine fragt einfach regelmäßig den Storage (oder bei Aufruf des Views), ob sich was geändert hat und ergänzt dann den Index. So kann es dann auch schon mal vorkommen, dass ein Index ein bisschen hinter dem Datenbestand hinterherhinkt, aber auch das kann man bei der Programmierung bedenken, z.B. wenn man nach dem Einfügen einfach mal den View aufrufen lässt. Dies wird sich in zukünftigen Versionen bestimmt noch einfacher lösen lassen, denke ich, ist aber derzeit für die Schreibgeschwindigkeit ein Plus, da nicht beim Schreiben, wie bei MySQL, direkt auch alle Indexe der entsprechenden Spalten mit aktualisiert werden müssen, was z.B. bei UNIQUE-Indexen und großen Datenmengen eine wirkliche Strapaze ist.

Da kommen wir auch gleich mal zu einem kleinen Nachteil.
Solche UNIQUE-Indexe gibt es in dokumentbasierten DBMS nicht. Dies muss man schon selbst in die Hand nehmen, was meist von den eh besser skalierbaren Webservern gemacht werden kann. Auf der CouchDB-Homepage wird auch von vornherein gesagt, dass es kein Ersatz für eine RDBMS ist, womit die Entwickler natürlich nicht ganz unrecht haben. Es gibt für jeden Einsatzzweck das beste Tool und kein DBMS ist für alles das Beste, auch nicht CouchDB. Allerdings bietet diese derzeit knapp 7,5k Codezeilen-Datenbank (ohne die JavaScript-Engine, diese stammt von Mozilla) sehr viele Vorteile, wenn man einen erweiterten Key-Value-Speicher benötigt. Außerdem hat es durch den Erlang-Hintergrund wirklich sehr großes Potenzial, was die Skalierbarkeit angeht.