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.

Vor ein paar Tagen habe ich die Frage aufgeworfen, ob mein nächstes Projekt eine SQL-basierte oder NoSQL/dokumentenbasierte Datenbanknutzen soll.

Auf der SQL-Seite tritt Postgres - mein aktuelle Favorit unter den Datenbanken - an und auch wenn regelmäßig neue Versionen herauskommen, kann Postgres als "fertig" betrachtet werden.

Recht neu sind CouchDB und MongoDB, zwei dokumentenorientierte Datenbanken, die für diese Seite in das Rennen gingen. Das Ergebnis ist knapper als erwartet ausgefallen.

And the Winner is... MongoDBDie Entscheidung ist eigentlich unfair, denn weder CouchDB noch MongoDB konnten sich im Gesamtbild (Datenbank + Perl-Integration) bei einem typischen Anwendungsfall wirklich durchsetzen. Der Grund, letztendlich doch den MongoDB-Versuch zu wagen, liegt im Reiz des Neuen: Schon die letzten Tage war ich bereit, im Zweifelsfall einer dokumentenorientierten Datenbank eine Chance zu geben und da Postgres nur knapp vor MongoDB lag, werde ich den Versuch wagen.

Dennoch wird die interne Objektstruktur des Projekts so bleiben, dass ein Umstieg auf Postgres mit vergleichsweise wenig Aufwand möglich werden wird, ohne dabei einen Nachteil für MongoDB zu schaffen.

Punkte für Postgres

DBIx::Class und mein Framework sind fertig, die Konstellation hat sich in verschiedenen Projekte bewährt und insbesondere Relationen zwischen Objekten/Tabellen werden aus den Foreign Keys der Datenbank automatisch bis in die Perl-Objekte übernommen. Geschwindigkeit und Skalierbarkeit von Postgres sind mir bekannt, ebenso die kleinen Macken aller Komponenten.

Punkte für CouchDB

Positiv für CouchDB ist die große Flexibilität zu werten, da keine Tabellen und Strukturen definiert werden müssen und die Views - ich zähle das jetzt als Pluspunkt - vordefiniert werden, damit stehen die Daten im Gegensatz zu SQL bei der Abfrage bereits bereit und müssen nicht erst berechnet werden. Ein fertiges, nutzbares ORM-Framework konnte ich nicht finden

Punkte für MongoDB

Die Flexibilität ist - ebenso wie bei CouchDB - als Pluspunkt zu werten. MongoDB liegt näher an einer SQL-Datenbank, auch der Vorteil der CouchDB-Views entfällt. Allerdings ist MongoDB auch bei der Abfrage flexibler einsetzbar und scheint mir näher an der Realität der täglichen Entwicklungsarbeit als CouchDB, die eher wie eine Konzeptstudie aussieht.

Negativ für MongoDB ist ebenfalls zu werten, dass es kein nutzbares ORM-Framework gibt. Mit Mongooseund MongoDBx::Class gibt es zwar Module, allerdings definieren diese effektiv lediglich eine Method zum Speichern und ein paar Methoden zum finden/laden, ihnen fehlt die angenehme Anwendung von DBIx::Class völlig.

Einen dicken Minuspunkt bekommt die Schnittstelle selbst, MongoDB, für die Abhängigkeit von Moose: Ein kleines schlankes Script mit Datenbankzugriff wird damit unmöglich, weil bei jedem Aufruf das Moose-Monster geladen werden muss. Ein Lichtblick ist dabei die Verwendung von Mousean Stelle von Moose selbst, es ist laut eigener Aussage wesentlich schlanker. Der einzige Grund, MongoDB für diese unnötige Abhängigkeit nicht zu disqualifizieren, ist mod_perl: Da die Module beim Apache-Start geladen werden, wird die Ladezeit nebensächlich.

Was kommt als Nächstes?

Zunächst werde ich ein neues ORM-Framework für MongoDB konstruieren. Dieses soll im Zweifelsfall mit möglichst wenig Aufwand gegen DBIx::Class austauschbar sein, wird aber wesentlich schlanker werden.