Ich habe mal wieder darüber nachgedacht, ob es nicht Zeit wäre, von MySQL auf Postgres umzusteigen. Bei den diesjährigen Chemnitzer Linux-Tagen habe ich ein interessantes Gespräch mit einem der Postgres-Leute gehabt. Seitdem laufen beide Datenbanken auf meinem Laptop und warten darauf, eingehend verglichen zu werden.Allein die Aufstellung der Testaufgabe und Umgebung beeinflusst jedoch dermaßen die Performance, dass ich davor zurückschrecke, die Geschwindigkeit mit ein paar naiven Query-Loops gegeneinanderzustellen. Aus Erfahrung mit MySQL weiß ich, dass Tuning der Datenbankparameter mehr als 50%  ausmachen können, geschweige denn das Tabellendesign und die richtige Wahl der Indizes – hier liegen einfach Welten drin.

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 !