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.

Früher war die Sache einfach: Eine Textdatei oder später ein tie-Call und die Daten waren gespeichert. Heute kämpfen verschiedene Datenbanken um die Vorherrschaft - aber eine wirklich gute Option scheint es nicht zu geben, man kann nur das kleinste Übel wählen.

mySQL

Die Datenbank mit vermutlich den meisten Usern - und Bugs. Ich wehre mich immer gegen die Annahme das die Anzahl der Nutzer etwas über die Qualität eines Produktes aussagen würde - mySQL ist das beste Beispiel. Mittlerweile werden zwar auch Transactions und selektive Locks unterstützt - aber nur zum Preis erhöhten Managementaufwands für Cluster. Datenverlust ist früher oder später völlig normal (man könnte meinen es wäre ein Amazon Cloud Service). Ich möchte lieber nicht wissen, wie viele Jahre mich mySQL-Bugs schon gekostet haben. Sie werden dann meist irgendwo auf der Homepage versteckt und als "Feature" angepriesen.

Große Datenmengen hält man am Besten von mySQL fern, wobei "groß" Definitionssache und hier eher als "groß für mySQL-Verhältnisse" zu verstehen ist - denn die Probleme fangen schon bei relativ wenigen Daten an. Ist man gezwungen einen Cluster mit myISAM-Tabellen zu betreiben, können auch einfache Queries schnell mal einen ganzen Server locken inklusive aller dort vorhandenen Datenbanken.

Management-Tools? Bitte einmal kräftig lachen. MyPHPadmin ist zwar weit verbreitet, kommt aber an eine ein echtes Datenbank-Management genau so wenig heran wie die GUI-Tools MySQL Query Browser und MySQL Administrator.

Die Dokumentation lässt ebenfalls stark zu wünschen übrig, fast alles ist zwar dokumentiert, aber weder die deutsche noch englische Fassung kann man als "gut" bezeichnen. Viele Details werden zwar erwähnt, eine wirkliche Beschreibung der Anwendungsfälle und Funktion sucht man allerdings vergeblich. Oh, und wie lange mySQL noch umsonst bleibt (von "kostenlos" möchte ich hier nicht sprechen), steht auch in den Sternen seit alles Oracle gehört.

Postgres bzw. PostgreSQL

Eigentlich eine feine Sache: Eine Open-Source-Datenbank (weitgehend) auf dem Level einer Enterprise-Lösung. PgAdmin III bewegt sich durchaus auf einer Stufe mit Sybase Central oder den einschlägigen Microsoft-Tools. Die Datenbank ist stabil, relativ sicher bei Servercrashs (bisher hatte ich noch keinen Datenverlust) und gut dokumentiert. Eigentlich bin ich vollkommen zufrieden und selbst der eigene Task pro erstellter Datenbank ist auf Grund des geringen Ressourcenbedarfs durchaus verkraftbar.

Die Installation unter Ubuntu hat durchaus Nachholbedarf aber richtig schön wird es erst bei Upgrades: Diese müssen manuell durchgeführt werden (wenigstens gibt es ein passendes Script im Installationspaket) was für mich absolut unverständlich bleibt. Ist es so schwierig das hauseigene Upgradescript (gerne nach Nachfrage beim Benutzer) automatisch laufen zu lassen und dem einfachen Anwender damit Sucherei bei Google und im schlimmsten Fall einen unerwarteten DB-Stillstand zu ersparen?

Ohne die Upgrade-Probleme wäre Postgres für mich die derzeit beste Lösung, so ist es zusätzlicher Managementaufwand (wenn auch normalerweise nicht viel) der bei kleinen Projekten erst einmal gerechtfertigt sein muss.

Sybase Adaptive Server Enterprise (ASE) und Sybase iAnywhere

Der ASE ist mir lieber, iAnywhere habe ich vor Jahren ausprobiert und damals war sie stabil und recht einfach, wenn man allerdings die Möglichkeiten der kostenlosen ASE Express Edition sieht, fehlt einfach einiges (was andere Anbieter allerdings überhaupt nicht anbieten).

Der Sybase ASE läuft problemlos: Ein Arbeitstier das für große Datenbestände und viel Leistung gemacht ist. Die Einschränkungen der kostenlosen Version sind für (fast) alle Projekte vollkommen ausreichend. Die Dokumentation ist sehr gut (was sollte man von einer eigentlich teuren Enterprise-Lösung auch anderes erwarten) und auch nach Servercrashs repariert sich Vieles von selbst, wenn da nicht das Identity-Problem wäre - allerdings ist das auch eher kosmetischer Natur.

Management? Wer einmal mit Sybase Central gearbeitet hat, wird schwerlich mit etwas anderem zufrieden sein, einzig die Ladezeit der großen Java-GUI ist nicht berauschend.

Der Grund warum ich mittlerweile Postgres dem ASE vorziehe liegt in der Installation: Als High-End-Enterprise-Lösung muss die Software nicht überall laufen, die notwendigen Pakete müssen vor der Installation selbst rausgesucht und installiert werden. Mit FreeTDS steht zwar eine freie Schnittstelle zur Verfügung, die aber einige Probleme mit sich bringt, der Sybase-eigene OpenClient ist frei von solchen Dingen, allerdings auch nur manuell installierbar. Eine ASE-Installation kann mit etwas Übung trotzdem noch einen halben Tag in Anspruch nehmen - weit entfernt vom einfachen "apt-get install mysqld oder apt-get install postgresql" - ohne Vorkenntnisse kann die Installation allerdings auch gerne mal eine Woche dauern.

CouchDB

Wie damals schon beschrieben ist CouchDB für mich eher eine Konzeptstudie. Die Datenbank ist toll - wenn der Einsatzzweck passt, aber eben nicht als Ersatz für eine klassische relationale Datenbank.

Größter Minuspunkt: Jedes Dokument muss bei jeder Änderung komplett neu gesendet und geschrieben werden.

Die interne automatische Versionierung und mächtige Map-Reduce-Zugriffe machen CouchDB dennoch zu einer sehr guten Option für den passenden Anwendungsfall. Mich wundert nach wie vor dass Wikipedia/Mediawiki nicht auf CouchDB-Basis arbeitet, denn beide Konzepte würden perfekt zueinander passen.

MongoDB

Ähnlich wie Postgres: Eine tolle Datenbank und durchaus als Ersatz für eine klassische SQL-Datenbank zu gebrauchen (aber bitte nicht versuchen die alten vergilbten Strukturen eins zu eins zu übernehmen, das klappt nicht). Die Geschwindigkeitsnachteile bei großen Datenmengen kommen bei vielen Projekten gar nicht zum tragen, dafür glänzt eine innovative Clusterstruktur.

Leider gibt es - wie bei Postgres - nicht nur Positives: Bei einem Crash ist der MongoDB-Datenbankserver grundsätzlich "down" und möchte manuell repariert werden. Wieso kann er nicht selbst feststellen "hey, ich wurde nicht sauber runtergefahren, dann sollte ich jetzt vielleicht meinen Reparaturmodus starten", das könnte man sogar im Standard-Ubuntu-Startscript abbilden - mit ein paar Minuten Aufwand.

Ich habe mittlerweile ein kleines Script auf meinem Standard-MongoDB - Server liegen mit dem die Datenbank fast automatisch repariert wird:

#!/bin/bashsudo -u mongodb /usr/bin/mongod --config /etc/mongodb.conf --repairsudo start mongodb

Natürlich gibt es keine Garantie dass nicht weitere Probleme die Reparatur verhindern, aber das hatte ich bisher erst ein einziges Mal.

Die Dokumentation ist nicht schlecht, aber an einigen wenigen Stellen noch verbesserungsfähig.

Wer MongoDB aus der Distribution (sei es Ubuntu oder Debian) installieren möchte, kann gleich danach die neuste Version von der Homepage laden, denn die Distributionsversionen sind meist hoffnungslos veraltet und bei einer so neuen Software fehlen dann gleich ein paar wichtige Features.

Memcached

Nein, Memcached ist keine Datenbank! Wollte es nie sein und wird es nie sein, sondern ein Cache, der seine Sache sehr gut macht. Warum ich ihn hier aufführe? Mindestens ein Mal pro Monat bekomme ich einen tollen, innovativen und interessanten Vorschlag - wie man Memcached als Datenbank missbrauchen benutzen könnte.

Was nun?

Manchmal wünsche ich mir meine guten, alten Textfiles oder tie-Datenbanken zurück, denn viele Probleme gab es damals einfach nicht, dafür aber andere die wiederum heute nicht mehr auftreten.

Ich werde wohl weiter bei Postgres und MongoDB bleiben, über die Upgrademöglichkeiten bzw. fehlende Autoreparatur fluchen - oder gibt es ernsthafte (kostenlose) Alternativen?