Dieser Post wurde aus meiner alten WordPress-Installation importiert. Sollte es Darstellungsprobleme, falsche Links oder fehlende Bilder geben, bitte einfach hier einen Kommentar hinterlassen. Danke.

Es steht mal wieder ein neues Projekt an und ich bin ernsthaft am überlegen, diesmal CouchDB an Stelle von Postgres einzusetzen.

CouchDB mag der erste OpenSource-Vertreter der dokumentenbasierten Datenbanken sein, aber deswegen nicht zwangsweise der Beste. Mike Perham hat in seinem Blog drei Datenbanken miteinander verglichen und meine Entscheidung zugunsten CouchDB beeinflusst.

Bleibt die Frage: Eine relationale SQL-Datenbank oder eine dokumentenorientierte Datenbank.

Vorteile von CouchDBAnno 1999 habe ich mit GDBM - Datenbankdateien angefangen und ihre Vorteile sehr zu schätzen gelernt. SQL-Datenbanken performen zwar besser bei mittelgroßen Datenmengen und Indices, haben allerdings auch viele Nachteile durch ihre feste Tabellenstruktur. CouchDB vereint die Vorteile beider Welten: Keine Einschränkung auf bestimmte Spalten, aber trotzdem ein Datenbankserver, der Daten und Strukturen im RAM cachen kann.

Die Struktur einer dokumentenbasierten Datenbank macht diese auch pflegeleichter - es müssen keine Tabellen erstellt oder Fremdschlüssel gepflegt werden, Lockingprobleme existieren nicht und die Datenkonsistenz ist immer gegeben, da keine Daten verändert werden.

Aktuell muss ich eine zusätzliche Spalte an drei Stellen einpflegen: In der Tabelle der SQL-Datenbank, im DBIx::Class-Schema und in meinem darauf aufbauenden Perl-Modul. Dabei wird das Schema automatisch aktualisiert, aber auch dieser Prozess wird manuell angestossen.

Ist ein Projekt bereits im Einsatz - möglicherweise sogar mit mehreren Installationen -  muß die Datenbankänderung in allen Installationen nachvollzogen werden, denn eine echte Datenbankversionierung wäre noch aufwendiger - so oft ändern sich fertige Projekte bei mir nicht.

Wie von CPAN nicht anders zu erwarten, steht mit DB::CouchDBauch ein auf den ersten Blick angenehm zu nutzendes Interface für die ohnehin einfache HTTP-Schnittstelle der CouchDB zur Verfügung.

Nachteile von CouchDB

Eine dokumentenbasierte Datenbank fördert Chaosprogrammierung. Mit Postgres entwickle ich Projekte meist mit PGAdmin, während die Tabellen entstehen, nimmt das Projekt Formen an, bevor die erste Zeile Code geschrieben ist. Dann werden aus den Tabellen die DBIx::Class-Schemata, Perl-Module, Web-Handler und Web-Templates generiert die - ähnlich Ruby on Rails - alle Grundfunktionen abdecken.

Mit CouchDB würde das Konzept erst beim Programmieren entstehen und würde im Laufe der Zeit zu einer Vielzahl an Keys in den Dokumenten-Hashs führen.

Andererseits habe ich OOP für den DB-Zugriff mittlerweile liebgewonnen und würde wohl auch dabei bleiben, müsste dazu allerdings jede Spalte als Methode im Modul anlegen - und würde damit einen guten Teil Chaosprogrammierung vermeiden.

Auch wenn eine CouchDB-Datenbank keine Tabellen kennt - in der Praxis würde wohl jedes Dokument einen "Type"-Key bekommen und jede Suche wäre wohl auf einen "Type" limitiert. Damit wäre effektiv wieder eine klassische Tabellenstruktur etabliert.

CouchDB kennt keine Relationen. Auch wenn ich Postgres-Foreign-Keys meist nur definiere, um letztendlich die entsprechen Objektverknüpfungen im generierten Perl-Modul zu haben, Relationen würden nach wie vor existieren und müssten manuell auf Perl-Ebene abgebildet werden.

Jeder CouchDB-Zugriff erfolgt über die Dokumenten-ID oder einen View, ich würde also die datenbankseitige Definition der Tabellen mit der Möglichkeit beliebige Abfrage direkt in Perl zu schreiben gegen die Vor-Definition von Abfragen in der Datenbank eintauschen. Der Unterschied würde sich erst in der Praxis wirklich zeigen.

CouchDB arbeitet mit einer HTTP-Schnittstelle, die bei  hohen Zugriffszahlen mit Sicherheit ineffizienter als eine SQL-Datenbank ist bei der im Optimalfall über die ganze Laufzeit des Webservers eine permanente Verbindung zum Datenbankserver genutzt wird. Ob der HTTP-Parser mit dem jeweiligen Overhead des Verbindungsaufbaus tatsächlich langsamer als SQL ist, muß sich zeigen, immerhin überträgt SQL bei jedem Zugriff das Statement als Text zur Datenbank die es dann auseinandernimmt und bei CouchDB findet dieser Teil bereits bei der Definition des Views statt. Die effektive Nutzung vordefinierter Statements und SQL-Prozeduren wird von DBIx::Class wirkungsvoll verhindert.

Fazit

Ich bin noch nicht sicher, die neue Projektidee ist klein und kompakt genug, um einen CouchDB-Versuch zu wagen, allerdings werde ich vorher noch ein paar Tests durchführen, insbesondere zur Speicherung komplexer Hash-Trees mit eingebetteten Array- und Hash-Referenzen

Eines hat sich gestern bei der Test-Installation von CouchDB auf meinem Entwicklungs-Netbook gezeigt: Das Ubuntu-Paket funktioniert nicht sauber, denn das Paket "erlang-nox" wird nicht automatisch als Dependency installiert, ist jedoch anscheinend notwendig. Auch die beim Start des Datenbankservers notwendigen Verzeichnisse werden bei der Installation nicht erstellt (darunter /var/log/couchdb), sie müssen aus /etc/couchdb/*.ini rausgesucht und von Hand erstellt werden.

Auf die Geschwindigkeit beider Datenbanken - Postgres und CouchDB - bin ich bewusst nicht eingegangen, denn bei heutiger Standard-Hardware hat jede Maschine genug Power um fast jedes Projekt zu stemmen, wenn es halbwegs sauber programmiert ist und das setze ich bei mir einfach mal voraus.

a href=p