MySQL vs. PostgreSQL: Erfahrungen aus praktischer Sicht

Immer wenn wir mit der Entwicklung einer neuen Webanwendung beginnen, stellt sich die Frage, wie wir mit den Daten arbeiten sollen. Eine der am weitesten verbreiteten Lösungen sind relationale Systeme. Systeme wie MySQL oder PostgreSQL sind weit verbreitet und haben ebenso viele Anhänger wie Kritiker.

Wenn man im Internet nach den Unterschieden zwischen MySQL und PostgreSQL sucht, wird in fast allen Vergleichen erwähnt, dass MySQL eine bessere Leistung hat und PostgreSQL einen viel größeren Funktionsumfang bietet.

Es ist zwar richtig, dass MySQL im Laufe der Zeit an Funktionalität gewonnen hat, ebenso wie PostgreSQL an Leistung gewonnen hat. Letzteres ist zum Teil auch auf die Fortschritte und Verbesserungen im Hardwarebereich zurückzuführen.

Bei WATA Factory haben wir uns gefragt, wie wichtig diese Unterschiede in der Praxis sind, ohne uns auf Diskussionen einzulassen, wie viele Mikrosekunden Unterschiedes zwischen dem einen oder dem anderen gibt, oder über die Anzahl an fortgeschrittenen Funktionen, die wir im Endeffekt in unserem Alltag nie benutzen.

MySQL: Hauptunterschiede

Mit MySQL können wir für jede Tabelle verschiedene Datenbank-Engines auswählen: InnoDB und MyISAM. Letztere ist diejenige, die MySQL seit seinen Anfängen begleitet hat und für ihren Ruf „schnell“ zu sein, verantwortlich ist.

Die Geschwindigkeit von MyISAM ist größtenteils darauf zurückzuführen, dass es keine referentiellen Integritätseinschränkungen, Trigger oder andere Funktionen hat. Diese Funktionen sind zwar mehr als nützlich, aber sie können Eingabevorgänge oder Aktualisierungen verlangsamen, da sie bei jedem Vorgang überprüft werden müssen. InnoDB hingegen verfügt über solche Funktionen und wäre daher nicht so schnell bei Eingabevorgängen oder Aktualisierungen.

Ein weiterer Aspekt ist die Frage der Blockierungen. Da in MyISAM die Daten durch INSERT-, UPDATE- oder DELETE-Befehle verändert werden, erfolgt eine Sperre auf Tabellenebene. In InnoDB oder PostgreSQL erfolgen Sperren auf Tupel-Ebene. Wenn die Anwendung große INSERT-, UPDATE- oder DELETE-Operationen durchführt, die sich auf eine beträchtliche Anzahl von Tupeln in der Tabelle auswirken, ist MyISAM daher wesentlich effizienter. Bei vielen kleinen gleichzeitigen Operationen hingegen arbeitet InnoDB besser, indem es nur das betroffene Tupel blockiert und so die Nebenläufigkeit verbessert.

Man könnte meinen, dass eine DB-Engine, die wir als relational bezeichnen und die keine Fremdschlüssel bereitstellt, von geringem Nutzen ist und zudem ein Risiko für die Datenintegrität darstellt. Nehmen wir jedoch den Fall einer typischen Business-Intelligence-Lösung, bei der wir ein Sternmodell mit einer zentralen Tabelle mit wenigen Beziehungen haben, die durch massive Prozesse befüllt wird. Es ist möglich, dass eine DB-Engine ohne Fremdschlüssel und mit Tabellensperre ein Vorteil ist, der berücksichtigt werden sollte. Dabei ist zu beachten, dass wir nicht nur die beiden DB-Engines im selben Schema kombinieren können, sondern auch mit anderen transaktionalen Tabellen im selben Schema arbeiten können.

Eine Möglichkeit, die von einigen vorgeschlagen wurde, ist, ein MySQL mit InnoDB für die Entwicklung zu verwenden und dann die Tabellen zu MyISAM zu verschieben, sobald sie in Produktion sind. Dazu müssen Sie sich natürlich sehr genau darüber im Klaren sein, was Sie tun, und den gesamten Prozess sehr sorgfältig kontrollieren. Die Idee ist, die Integrität der Daten während der Entwicklung zu kontrollieren, aber die Abfragen zu beschleunigen, sobald sie in Produktion sind.

Kurz gesagt, wenn wir MySQL in unserer Entwicklung verwenden wollen, sollten wir uns überlegen, ob wir wirklich die Vorteile von MyISAM nutzen wollen. Wenn nicht, ist es vielleicht besser, sich für andere Engines zu entscheiden.

PostgreSQL und seine Funktionen

Obwohl MySQL mehr und mehr Funktionalitäten integriert hat und weiterhin integriert, stimmt es, dass PostgreSQL sich von Anfang an als ein vollständigeres und freieres relationales Datenbankmanagementsystem hervorgetan hat. Für viele gilt sie als das Orakel der freien Software.

Unter seinen Funktionalitäten sticht PL/pgSQL hervor, das dem PL/SQL von Oracle sehr ähnlich ist. Durch die Verwendung dieser Sprache können wir die für prozedurale Sprachen typische Komplexität in unser SQL einbringen: Schleifen, Konditionale, Funktionen… Die Trigger, um ein Beispiel zu nennen, können sehr komplex werden.

Auf der SQL-Ebene enthält PostgreSQL auch Window-Funktionen, die komplexe SQL-Abfragen ermöglichen, die besonders in statistischen Anwendungen nützlich sind. Ebenso können wir mit dem Regelsystem (Rules) die Ausführung von Abfragen und Datenmanipulationsbefehlen feinabstimmen, indem wir die Art und Weise ändern, in der der Befehl von der Datenbank-Engine verarbeitet wird.

Es gibt noch weitere bemerkenswerte Aspekte wie die Verknüpfung zwischen Tabellen und materialisierten Ansichten. Eine ausführliche Darstellung würde jedoch viele weitere Artikel erfordern.

Also haben wir mit PostgreSQL eine breitere Palette von Möglichkeiten bei der Entwicklung einer neuen Anwendung, so dass wir weniger eingeschränkt sind als bei der Verwendung von MySQL, was bei Projekten, bei denen lang- oder mittelfristig eine evolutionäre Wartung vorgesehen ist, sehr interessant ist.

MySQL vs. PostgreSQL bei WATA Factory

Bei WATA Factory evaluieren wir für jedes einzelne Projekt, welche Datenbank-Engine verwendet werden soll, abhängig von Faktoren wie z.B. ob es sich um ein langfristiges Projekt handelt, der Art der Anwendung oder der Anzahl der gleichzeitigen Benutzer, um nur einige Faktoren zu nennen.

Für praktische Zwecke, wenn es keine besonderen Leistungsanforderungen gibt, wie es bei den meisten der von uns zu entwickelnden Anwendungen der Fall ist, bevorzugen wir PostgreSQL, das sehr interessante Funktionalitäten bietet, die für die Zukunft nützlich sein könnten, ohne dass es für praktische Zwecke große Unterschiede gibt.

Wir haben uns aber auch mit der Entwicklung von Projekten auf Basis von CMS wie Drupal, WordPress oder Joomla beschäftigt.

In diesen Fällen ist es natürlich immer am besten, das von der Community, die diese CMS entwickelt, empfohlene System zu verwenden, was normalerweise MySQL ist.

Dies liegt daran, dass diese Art der Entwicklung in der Regel besonderen Anforderungen in Bezug auf die Positionierung oder SEO unterliegt, so dass ein MySQL mit MyISAM eine gute Alternative sein kann.

Obwohl in der Drupal-Dokumentation angegeben wird, dass MySQL und PostgreSQL unterstützt wird, kommt es vor, dass bei der Installation von Modulen von Drittanbietern diese hauptsächlich in MySQL entwickelt und getestet wurden. Abhängig von der Drupal-Version und den Modulen, die wir auf unserer Website verwenden, ist die Auswahl, die uns wahrscheinlich weniger Kopfzerbrechen bereiten wird, MySQL.

Wenn wir die Software von Drittanbietern entwickeln, ist es durchaus möglich, dass wir eine Engine wie MySQL verwenden, die leicht anpassbar und erweiterbar ist. Andererseits, wenn wir später entscheiden, dass unser Produkt beide Datenbanksysteme unterstützen soll, wäre es einfacher, von MySQL auszugehen und es an PostgreSQL anzupassen als umgekehrt.