heute habe ich mir vorgenommen, die Datenbank-Schiene in voller Länge mitzunehmen. Los gings es mit Neuigkeiten in Postgresql 8.5, welches nun auch als Version 9.o firmiert. Da die Zeit mit 30 Minuten sehr kurz angesetzt war, ging es Schlag auf Schlag um neue Features, Bugfixes und Erweiterungen.

Nun läuft gerade “Sphinx- Improving weaknesses in MySQL”, welches auf Englisch gehalten wird. Ich müsste mich also konzentrieren statt zu bloggen, aber was tut man nicht alles für seine Community.

Daneben habe ich kurz den FSFE-Stand besucht und meine Shopping-Lüsten gepflegt und werde nachher noch LAX und weitere Stände anlaufen. Während eines Tee-Gespräches mit einem Hannoveraner Linux-Freak habe ich von einem Leipziger Hackerspace in Plagwitz (Westwerk) erfahren – sehr witzig.

Also: Ich habe bisher zwei Vorträge gehört, der zweite davon war über die Exchange-Alternative Zarafa. Die Präsentation war unterhaltsam und emotional vorgetragen, so was macht immer Spaß! Der OpenVPN-Vortrag war knackevoll und auch gespickt mit Features. Was definitiv gut ist: Die Software, über die referiert wird, auch zu benutzen. Dann steckt man voll im Thema drin und es fällt leichter, die News oder Probleme rauszuhören und nachzuvollziehen, Und braucht auch kaum Fragen zu stellen – der Nachbar hat oft die gleiche!

Weiter gehts für mich nach einer kleinen Stärkung mit BIND9 und später Dovecot, dazwischen schwanke ich noch mit IT-Service-Management und Single-Sign-On per Kerberos her. Letzteres kenne ich bereits aus einer Schulung, da wird wohl nix neues kommen.

Das Programm ist mal wieder so fett gespickt, da weiß man gar nicht, welchen Vortrag man sich aussuchen soll: IPv6, OpenVPN, Postfix, Ardour, MySQL, Postgresql, OpenOffice, DNSSEC, Knoppix, Kernel, Kerberos – es ist ja wirklich alles da…

Außerdem verwenden wir für 90% unserer Daten MyISAM-Tabellen, die sich jedoch nur schwer mit Postgres vergleichen lassen. Da sollte man schon InnoDB verwenden und auf dieselben Features zurückgreifen, zum Beispiel Transaktionen, Referentielle Integrität oder Row Level Locking, welches ich mal mit zeilenbasiertes Sperren übersetzen möchte.

Es gibt jedoch eine Menge Sites, die aus ihren eigenen Tests die eine oder andere Datenbank stets als schneller evaluiert haben, zB Drupal. Man sollte da einfach mal nach “MySQL Postgres” googlen. Man kann dabei aber schnell ins religiöse Halblicht reingezogen werden. Die Tests werden meist von Advocacies und Flamewars begleitet, die dann meistens die Tests selbst als ungenügend kritisieren oder alles für alte Banane abtun, da Version X.Y.4a ihres Lieblingsprodukts ja alle genannten Kritikpunkte wegsprenge.

Richtig ist: Features und Konsistenz bedürfen nun mal Rechenzeit. Je nachdem, wie gut das DBMS programmiert ist, wählt es für jede der Aufgaben den minimalen Mechanismus im Sinne der zugrundeliegenden Architektur. Daraus ergeben sich für die ein oder andere Funktion verschiedene Laufzeiten. Im großen und ganzen sollte die Summe jedoch recht ausgeglichen sein.

Beide Datenbanken haben in den letzten Jahren durch den Hype von Open Source Software im Business-Umfeld offensichtlich stark zugelegt. Nicht zuletzt, weil die Anzahl der Installation und damit auch Anforderungen an diese und das Bug-Reporting ordentlich anstiegen. Dass die Daten gut verpackt und fehlerfrei so rauskommen, wie man diese einmal reingeworfen hat, das kann man beiden System also ohne Zweifel voraussetzen.

Wichtig im Sinne eines stressfreien Einsatzes erscheinen mir daher eher solche Dinge wie Installationshandling, Rechteverwaltung, Unterstützung häufiger Datenmanipulationsaufgaben oder In- bzw. Export von Daten.  Für Profis eventuell noch wichtig: Replikation, Failover oder Backup. Am meisten interessiert sicherlich das Gros der Leute, ob die PHP-Anbindung sauber funktioniert und alle Aufgaben einwandfrei unterstützt werden.

Wenn man mehrere parallele Threads laufen hat, zB bei gleichzeitigen Zugriffen auf eine gut besuchte Webseite mit vielen Datenbankoperationen, zählen sicherlich auch noch  andere Performance-Werte:

• Die Anzahl der konkurrierenden Zugriffe
• der dabei entstehende Speicherbedarf (“memory footprint”)
• das initiale Delay einer Abfrage.

Allerdings sind das Sphären, in denen die meisten DBA zu Replikation greifen werden. Wenn ein Server so am Anschlag ist, dann gibt man ihm doch am besten einen Partner zur Hand.

Deshalb habe ich beschlossen, es vorerst bei MySQL zu belassen. Ich werde also erst einmal schauen, was InnoDB mit Row Level Locking und Referenzieller Integrität für mich noch an Vorteilen zu bieten hat. Hier allein lassen sich schon Performance-Vergleiche anstellen und deren Ergebnisse im Alltag effektiv nutzen.

Erst dann kommt dann Postgres dran – zunächst wird es mir ums Handling gehen und später um die Performance – und zwar genau an den auch für InnoDB geeigneten Stellen. An dieser Stelle wird davon zu lesen sein.

Stay tuned !