Zweikampf

Inhaltsverzeichnis

Aus dem Angebot frei verfügbarer relationaler Datenbanken stechen MySQL und PostgreSQL als wichtigste Vertreter hervor: MySQL ist bei vielen Web-Hostern verfügbar, und PostgreSQL macht durch Standardkonformität sowie eine kontinuierliche Weiterentwicklung von sich reden.

In der Vergangenheit konnte der Eindruck entstehen, PostgreSQL sei der ewige Zweite. MySQL war einfach zu installieren und zu bedienen, und dass ihm anfänglich Funktionen wie Transaktionen, Stored Procedures und Trigger fehlten, erleichterte Laien die Einarbeitung. Inzwischen ist die Lage aber nicht mehr so klar.

Dazu hat vor allem der Versionswirrwarr bei MySQL beigetragen. Als Produktivversion gilt zurzeit die Reihe 5.1, 5.0 ist jedoch noch weit verbreitet. Im April 2004 veröffentlichte Sun überraschend eine Version 5.4, die vor allem Performance-Verbesserungen von Google enthielt. Sie schaffte es jedoch nicht zur Produktionsreife. Inzwischen arbeitet Oracle an MySQL 5.5.

Um Klarheit über die aktuelle und mögliche zukünftige Entwicklung bei MySQL zu gewinnen, bat iX einen bei Oracle beschäftigten Fachmann um einen Beitrag (s. iX 9/10 S. 44). Zu Projekten wie dem 2007 angekündigten MySQL 6 und der dafür entwickelten transaktionsfähigen Storage Engine Falcon äußert sich das Unternehmen jedoch nicht. Das lässt nur den Schluss zu, dass diese Vorhaben gestorben sind. Zumal die Arbeit an dem seit 2005 zu Oracle gehörenden InnoDB schnell voranschreitet – zwei Transaktions-Backends aus demselben Haus dürften für das Unternehmen keinen Sinn ergeben.

MySQLs Schwerpunkt ist das Unternehmen

Den Schwerpunkt der Entwicklung legt der neue MySQL-Eigentümer Oracle offenbar auf unternehmensrelevante Funktionen, die dem eigenen Flaggschiff nicht zu viel Konkurrenz machen. So ist keine Rede von einer Weiterentwicklung der seit Langem dahindümpelnden Geofunktionen in MySQL, einer verbesserten Unterstützung von XML oder einer Ausweitung der Volltextsuche auf Storage Engines jenseits des simplen MyISAM.

Storage Engines sind übrigens eine Besonderheit von MySQL. Sie übernehmen die Datenverwaltung im engeren Sinne. MyISAM ist die älteste dieser Engines, sie trug wesentlich zum Ruf von MySQL als rasanter Web-Datenbank bei. Das Tempo kam in erster Linie durch Verzicht auf Funktionen zustande: MyISAM kennt keine Transaktionsverarbeitung, und der unterstützte SQL-Dialekt verzichtete anfangs auf viele professionelle, aufwendigere Konstrukte wie Subqueries oder Views. Inzwischen sind etliche weitere Storage Engines hinzugekommen.

Am bekanntesten dürfte das transaktionsfähige InnoDB sein. Da der Code unter einer Open-Source-Lizenz stand und es für MySQL zunächst keine Alternative gab, blieb diese Engine auch nach der Übernahme des InnoDB-Herstellers durch Oracle Teil der Distribution. Anders erging es dem ebenfalls freien, transaktionsfähigen BerkeleyDB, 2006 von Oracle geschluckt. Es verschwand aus der Liste der Backends. Die ist allerdings immer noch umfangreich: Aus der Engine NDB entstand der MySQL-Cluster, andere Speichersysteme binden externe Quellen („Federated Database“) oder CSV-Dateien an.

Neben dem von Oracle weiterentwickelten MySQL gibt es zwei Abspaltungen: Drizzle, das Brian Aker 2008 initiierte, und MariaDB, betrieben vom MySQL-Gründer Michael „Monty“ Widenius nach seinem Ausscheiden bei Sun. Die Drizzle-Entwickler wollen die Datenbank wieder zurück zu ihren Wurzeln führen, indem sie sich auf den Einsatz im Web konzentrieren. Sie verzichten auf die MyISAM-Storage-Engine und nutzen InnoDB. Eine Windows-Version gibt es nicht, Drizzle benötigt Unix als Unterbau. Es will ähnlich wie PostgreSQL diverse Skriptsprachen zum Schreiben von Stored Procedures erlauben.

Widenius’ MariaDB soll in allen wesentlichen Aspekten kompatibel zur jeweiligen MySQL-Version bleiben, bringt jedoch mit Aria (das bis vor Kurzem „Maria“ hieß) eine eigene Storage Engine mit. Sie verhält sich bei Stromausfällen und ähnlichen abrupten Betriebsunterbrechungen robust. Gegenüber dem Ahnen soll MariaDB vor allem einen höheren Durchsatz schaffen. Einen Schwerpunkt legen die Entwickler auf die schnelle und gründliche Behebung von Fehlern.

Der Standard ist das Ziel

Größere Nähe zum SQL-Standard gehört nicht zu den öffentlich verkündeten MySQL-Zielen. Das ist bei PostgreSQL anders: Seine Entwickler haben früh großen Wert darauf gelegt, dass die Datenbank der Norm entspricht. Allerdings sprach sie am Anfang ihres Daseins, das als „Postgres“ begann, noch kein SQL. Damals benutzte der als Forschungsprojekt entstandene Server „PostQUEL“, eine Weiterentwicklung des vom älteren Ingres stammenden „QUEL“. Schon Postgres kannte einige Verfahren der Objektorientierung, etwa Datentypen mit Vererbung.

1995 erschien mit Postgres95 die erste SQL-fähige Weiterentwicklung, inzwischen sind die Entwickler bei PostgreSQL 9.0 angelangt (s. iX 9/10 S. 48). Benutzerdefinierte Datentypen und Vererbung gibt es immer noch. Hinzugekommen sind außerdem unter anderem Geo-Datentypen und -Funktionen, Stored Procedures in Skriptsprachen wie Perl und Python sowie mit Version 9 erstmals integrierte Replikation und Hot Standby.

Anfänglich legte PostgreSQL die Hürden für Anfänger relativ hoch: Sie mussten den Quellcode selbst übersetzen und sich durch eine spröde Dokumentation kämpfen. Inzwischen gibt es auch für Windows fertige Installationspakete, viele Linux-Distributionen enthalten ebenfalls ein PostgreSQL-Paket. Eine andere „Hürde“ jedoch blieb bestehen – die Standardkonformität. Während MySQL es Laien einfach macht, eine Anwendung zusammenzuklöppeln, indem es in vielen Fällen Fehler vergibt und durch etwas „Sinnvolles“ ersetzt, zeigt sich PostgreSQL hartleibig.

Laisser-faire und erzieherische Strenge

Wer dort ein illegales Datum wie „0000-00-00“ oder „2010-2-31“ eingibt, bekommt erbarmungslos eine Fehlermeldung. MySQL hingegen akzeptiert derlei in seiner Default-Einstellung klaglos und speichert in beiden Fällen „0000-00-00“ als Datum. Diese Großzügigkeit reicht bis hin zu Tabellen, in deren NOT NULL-Spalten MySQL in bestimmten Situationen den Wert NULL einträgt, ohne zu murren. Wer es strenger möchte, muss dies dem Server per Startparameter sagen. PostgreSQL-Nutzer haben diese Wahl nicht, sie müssen immer korrektes SQL produzieren. Zum Ausgleich stehen ihnen Standardfunktionen zur Verfügung, etwa die SEQUENCE, die sich bei MySQL als auto_increment-Parameter beim Erzeugen einer Tabelle verkleidet.

PostgreSQL selbst gibt es unabhängig vom Einsatzzweck unter einer freien Lizenz; eine US-Firma bewirbt ihren kommerziellen Ableger als „Oracle-kompatibel“. MySQL hingegen wird von Oracle sowohl als freien „Community Server“ als auch in einer kostenpflichtigen Enterprise-Variante vertrieben. Sein Entwicklungsprozess verlief in den letzten Jahren so chaotisch, dass sogar Michael Widenius schon einmal vom Einsatz einer bestimmten Version abriet – sie enthalte noch zu viele Fehler. Bei PostgreSQL scheint es ruhiger zuzugehen, außerdem ist die Trennung zwischen Wartungs- und Feature-Release klarer. Zur Zukunft des Konkurrenten verrät hoffentlich der Vortrag „MySQL – Strategie und Roadmap“ auf der Konferenz „Oracle Open World“ im September Näheres.

iX-Link: www.ix.de/ix1009042

In der Printausgabe iX 9/10 lesen Sie außerdem einen Artikel dazu, wie es MySQL bei Oracle geht und einen, der die neue PostgreSQL-Version 9 vorstellt. (ck)