Open Source-Datenbanken: Die aktuellen Versionen von MySQL und PostgreSQL

Schnäppchenjäger

Rudolf Jansen

Nicht nur in wirtschaftlich schwierigen Zeiten stellt sich bei der Auswahl eines Software-Produkts die Frage, ob viel Geld in ein kommerzielles Produkt investiert werden soll oder ob auch der Einsatz eines Open Source-Produkts die Anforderungen erfüllen kann. Auf dem Datenbankmarkt existieren neben den bekannten kommerziellen Produkten, wie z.B. Oracle oder IBM DB2, auch einige frei verfügbare Konkurrenten. Der vorliegende Artikel stellt mit MySQL und PostgreSQL zwei dieser Open Source-Datenbanken in ihren aktuellen Versionen vor.

Diskussionen über die Vor- und Nachteile von freier Software im Vergleich zu kommerziellen Produkten werden unterschiedlich geführt. Im Bereich Webserver und Servlet-Engine wird das Gespann Apache-Tomcat in der gesamten Branche als klarer Marktführer angesehen. Bei der Frage nach der Auswahl der richtigen Entwicklungsumgebung werden die Diskussionen schon interessanter. Eclipse als prominenter Vertreter der Open Source-Produkte hat viele Anhänger und bringt die Marketing-Vertreter der kostspieligen kommerziellen Produkte häufig in Erklärungsnotstand, wenn es um die Frage geht, warum man viel Geld für ein kommerzielles Produkt ausgeben soll, obwohl ein Open Source-Produkt inklusive der in der zugehörigen Community verfügbaren Erweiterungsmodule doch auch (fast) alle Wünsche erfüllen kann.

Der Datenbankmarkt dagegen scheint zumindest in großen Unternehmen fest in der Hand der kommerziellen Produkte von Oracle, IBM, Microsoft und anderen Anbietern zu sein. Open Source-Produkte haben häufig den Ruf, auf Grund fehlender Features nur eine Art Spielwiese für kleine Projekte zu sein, die sich keine richtige Datenbank leisten können. Die im Folgenden vorgestellten aktuellen Versionen der beiden bekanntesten freien Datenbanken MySQL und PostgreSQL zeigen, dass diese Vorurteile ungerechtfertigt sind. In Abhängigkeit der konkreten Projektanforderungen kann sich ein Blick auf diese Produkte durchaus lohnen.

Neben MySQL und PostgreSQL existieren noch weitere Open Source-Datenbanken. Hypersonic SQL (auch bekannt unter der Bezeichnung HSQLDB ) beispielsweise ist eine komplett in Java geschriebene Datenbank, die unter SourceForgeNet verfügbar ist [1]. In einem vorigen Artikel dieser Datenbankrubrik [2] wurden weitere Java Embedded-Datenbanken vorgestellt, die sich insbesondere durch den geringen Speicherbedarf auszeichnen und somit als Bestandteil einer (Java-)Anwendung eingesetzt werden können. HSQLDB kann auf Grund seiner Größe von knapp 100 KB als extrem kompakt angesehen werden und unterstützt u.a. auch Transaktionen und Stored Procedures. Sie ist allerdings nicht mit den großen kommerziellen Datenbanken sowie den im Folgenden vorgestellten freien Produkten vergleichbar, da sie nicht multithreaded ist und keine Möglichkeiten zur Skalierbarkeit für größere Anwendungen bietet. Auch Borland bietet eine spezielle Version seiner Interbase-Datenbank als freie Version an [3].

Lizenzbedingungen

Im Folgenden werden die aktuellen Versionen der beiden bekanntesten Vertreter der freien Datenbanken MySQL und PostgreSQL vorgestellt. Welche Kriterien sollte man bei einem Vergleich dieser Produkte untereinander sowie beim Vergleich mit kommerziellen Systemen berücksichtigen? Neben den technischen Kriterien wie Stabilität, Performance, Unterstützung der bekannten SQL-Features sowie Zusammenspiel mit anderen Softwaresystemen gehört natürlich auch der finanzielle Aspekt zu einer Produktevaluierung. Auf Grund der freien Verfügbarkeit sammeln MySQL und PostgreSQL hier natürlich zunächst eindeutig Pluspunkte gegenüber Oracle, IBM und Co, die mit ihren Lizenzgebühren eine gewichtige Rolle im Projektbudget spielen.

Interessanterweise gibt es aber auch Diskussionen, in denen die fehlenden Lizenzen als Kritikpunkt an den freien Datenbanken aufgeführt werden. Ein Teilnehmer des Speaker-Panels bei der letzten W-JAX (2002 in München) vermutete beispielsweise, dass einige große Unternehmen Open Source-Produkte nur deshalb nicht einsetzen, weil sie dann niemanden haben, den sie bei Problemen oder Misserfolg verklagen können. Ziel einer solchen Kritik ist meist die angeblich fehlende Support-Unterstützung, die in den kommerziellen Lizenzen dagegen enthalten ist. Wer aber in der Vergangenheit bereits eine zeitaufwändige und möglicherweise am Ende nicht erfolgreiche Kontaktierung von kommerziellen Hotlines bei ernsten Fehlern über sich ergehen lassen musste, wird die häufig wesentlich schnellere Hilfe in Internet-Newsgroups zu schätzen wissen. Außerdem bieten Open Source-Produkte als zusätzliche Option bei der Fehlersuche immer noch eine eigene Suche im öffentlich zugänglichen Sourcecode an.

Während PostgreSQL mit der BSD-Lizenz eines der klassischen Open Source-Lizenzmodelle zur Verfügung stellt, wählt MySQL einen anderen Weg. Hinter der MySQL-Datenbank steht mit der schwedischen MySQL AB ein Unternehmen mit weltweiten Niederlassungen, das auch die Copyright-Rechte am MySQL-Sourcecode besitzt. Standardmäßig wird MySQL unter der GPL vertrieben, d.h. der Einsatz des Produkts zum Einsatz im eigenen Unternehmen ist frei. Wer MySQL dagegen im Zusammenhang mit eigenen Produkten vermarkten will, muss diese Produkte gemäß GPL-Richtlinie [4] auch offen unter GPL-Lizenz stellen. Da dies bei kommerziellen Produkten meist nicht gewünscht ist, bietet das Unternehmen MySQL auch kommerzielle Lizenzen inkl. Support an. Einzellizenzen pro Datenbankserver für eine beliebige Anzahl von Connections und CPUs kosten zwischen 220 und 440 Euro, abhängig vom erforderlichen Transaktionsverhalten (Stand August 2003). Auf die Unterschiede bzgl. des Transaktionsverhaltens bei unterschiedlichen MySQL-Tabellen wird weiter unten noch näher eingegangen.

Konfrontiert mit diesen fehlenden bzw. geringen Lizenzgebühren ihrer freien Konkurrenten, verweisen Vertreter der kommerziellen Produkte berechtigterweise auch auf die weiteren Kosten, die beim Einsatz von Datenbanken anfallen können. Fragen, die im Vorfeld einer Entscheidung für oder gegen freie Datenbanken gestellt werden müssen, sind beispielsweise:

  • Existiert im Unternehmen bzw. auf dem Personalmarkt genügend Know-how im Umgang mit den freien Datenbanken? Schulungskosten sind in diesem Zusammenhang in die Kalkulation einzubeziehen.
  • Wie steht es um die Dokumentation der Produkte? Open Source-Produkte zeichnen sich zwar häufig durch eine Vielzahl von Programmierern aus, die an der Weiterentwicklung des Produkts arbeiten. Die Erstellung von ausreichender Dokumentation zu alten und neuen Features kann dabei schnell in den Hintergrund geraten.
  • Wie sind die freien Produkte bzgl. Skalierbarkeit zu beurteilen? Stellt sich in einer späteren Betriebsphase heraus, dass ein gewähltes freies Produkt den steigenden Ressourcen-Anforderungen nicht mehr gewachsen ist, so steht möglicherweise ein Austausch durch ein kommerzielles Produkt an. Erneute und damit auf die gesamte Projektlaufzeit gesehen doppelte Entwicklungs- und Testaufwände wären die Folge.

Die folgenden Kapitel stellen den Funktionsumfang von MySQL und PostgreSQL vor. Ein Schwerpunkt liegt dabei auf einer Auflistung von Features, die (noch) nicht unterstützt werden, da sich anhand einer solchen Liste für einige Projekt bereits K.O.-Kriterien für den Einsatz der einzelnen Produkte ergeben.

MySQL 4.1

Der Ursprung von MySQL liegen bei einem im Jahr 1979 in Schweden entwickelten Datenbank-Tool namens Unireg. Daraus entstand dann 1994 MySQL. Zum Zeitpunkt der Erstellung dieses Artikels hatte die Produktions-Version der MySQL-Datenbank die Versionsnummer 4.0.14. Daneben ist allerdings auch die 4.1-Version bereits zum Download verfügbar. Die im Folgenden aufgeführten Features beziehen sich – sofern nicht explizit anders angegeben “ auf diese 4.1-Version.

Die Popularität von MySQL beruht vor allem auf dem sehr verbreiteten Einsatz der Datenbank in Web-Anwendungen. Die nach ihren Bestandteilen Linux, Apache, MySQL und PHP benannte LAMP-Kombination kann wohl als die Standard-Konfiguration für Web-Anwendungen angesehen werden. Insbesondere die Integration von MySQL-Anweisungen in PHP-Programme macht dieses Gespann für eine typische Anforderung innerhalb von Web-Anwendungen interessant, nämlich für schnelle Abfrageergebnisse. Viele Web-Anwendungen sind gekennzeichnet durch keine oder vergleichsweise wenige Datenbankänderungen über die Website. Stattdessen werden über das Web meist Abfragen auf großen Datenbeständen durchgeführt. Die Antwortzeit auf eine Abfrage, also die Zeit, die bis zum Erscheinen der ersten Datensätze auf der Website vergeht, ist das entscheidende Kriterium für die Auswahl der passenden Datenbank für diese Art von Web-Anwendungen. Und genau dieses Kriterium ist einer der großen Vorteile der MySQL-Datenbank. Ein Blick auf die verfügbaren ToDo-Listen für zukünftige Versionen auf den MySQL-Websites [5] verdeutlicht den Grundsatz, auf den die MySQL-Entwickler großen Wert legen: Neue Features dürfen unter keinen Umständen die Performance von Abfragen verschlechtern.

Das Ansehen von MySQL leidet in der allgemeinen Diskussion etwas darunter, dass der Funktionsumfang von MySQL geringer ist als der von kommerziellen Datenbanken und auch geringer als der von PostgreSQL. Die MySQL-Entwickler gehen hier aber bewusst nach dem Motto weniger ist oft mehr vor. Bei einer Vielzahl von Funktionen, die möglicherweise nur von wenigen Anwendern eingesetzt werden, besteht die Gefahr, dass die Performance des Gesamtsystems unter dieser Menge von Features leidet, da bei allen Datenbankoperationen dann mehr Optionen überprüft werden müssen. MySQL hat sich daher bisher auf die Kernfunktionen konzentriert, die speziell in Web-Anwendungen gefordert werden. In diesem Zusammenhang sind auch die Einführung eines Query Caches sowie die Unterstützung von Prepared Statements an Version 4.01 zu sehen.

Einer der am häufigsten genannten Nachteile von MySQL ist die angeblich fehlende Unterstützung von Transaktionen. Diese Aussage ist falsch. Dazu ist ein Blick auf das Speicherkonzept von MySQL erforderlich. MySQL-Tabellen können eine der drei folgenden Speicheroptionen besitzen:

  • MyISAM-Tabellen,
  • BerkeleyDB (BDB)-Tabellen,
  • InnoDB-Tabellen.

Die Standard-Variante MyISAM bietet keine Transaktionsunterstützung und ist daher insbesondere für Read-Only-Web-Anwendungen geeignet, für die eine Transaktionskontrolle einen nicht benötigten Overhead bringen würde. BDB- und InnoDB-Tabellen sind dagegen transaktionsfähig und ermöglichen auch den Einsatz von Foreign Keys. Diese beiden Tabellentypen unterscheiden sich in der Art des Sperrens von Datensätzen. Während eines UPDATE-Befehls innerhalb einer Transaktion muss der geänderte Bereich für andere Transaktionen gesperrt werden, damit die Konsistenz des Datenbestandes immer gewährleistet wird. Erst mit der Beendigung der ändernden ersten Transaktion entweder über ein COMMIT oder ein ROLLBACK wird der gesperrte Bereich wieder freigegeben. In BDB-Tabellen werden immer ganze Seiten gesperrt, d.h. alle Datensätze, die auf demselben Speicherblock liegen wie der gerade geänderte, werden gesperrt. InnoDB-Tabellen dagegen ermöglichen ein zeilenweises Sperren analog zu den kommerziellen Konkurrenten von MySQL, d.h. nur die geänderte Zeile der betroffenen Tabelle ist gesperrt. Die Speicheroption kann für jede Tabelle innerhalb einer MySQL-Datenbank einzeln angegeben werden. Somit ist es beispielsweise möglich, Read-Only-Tabellen aus Performance-Gründen als MyISAM-Tabellen zu speichern, für andere Tabellen aber die Transaktionsunterstützung von InnoDB-Tabellen zu nutzen. Weitere Features, die MySQL 4.1 unterstützt sind:

  • Subselects,
  • SELECT FOR UPDATE-Befehle,
  • geografischer Datentyp GEOMETRY.

Derzeit in den 4er-Versionen noch nicht unterstützt werden allerdings Views, Stored Procedures und Triggers. In vielen Projekten wird das als K.O.-Kriterium gegen den Einsatz von MySQL sprechen. Über Views lassen sich auf der Basis von bestehenden Tabellen neue tablenähnliche Sichten auf den Datenbestand einrichten. Vor allem in großen Unternehmen mit bestehenden und damit oft unveränderbaren Datenbank-Schemas sind Views ein gängiges Mittel, um innerhalb von neuen Anwendungen eine passende Tabellenstruktur anzulegen ohne Altanwendungen ändern zu müssen. Stored Procedures werden häufig für komplexere Dateneinfüge-Operationen eingesetzt. Ein konsistenter Datenbestand wird gewährleistet, indem ein (Schreib-)Zugriff auf die Daten nur über Stored Procedures erlaubt wird. Diese Prozeduren werden meist vom Datenbank-Designer angelegt und laufen direkt in der Datenbank ab. Trigger als Spezialform von Stored Procedures ermöglichen automatische Konsistenz-Checks und Folgearbeiten nach Datenänderungen. Alle drei Konzepte sind also fester Bestandteil von Enterprise-Anwendungen. Dies hat nun auch MySQL eingesehen und kündigt für Folgeversionen die Unterstützung von Views (ab 5.1), Stored Procedures (ab 5.0) und Triggern (ab 5.1) an. Die Syntax von Stored Procedures soll laut Angaben auf der MySQL-Website ähnlich zu der von Oracle PL/SQL sein.

Neben einer Administration über Kommandozeilentools gibt es auch grafische Verwaltungstools für MySQL-Datenbanken. Zu nennen ist dabei vor allem das MySQLCC (MySQL Control Center)-Tool, das wie die Datenbank wahlweise unter GPL-Lizenz oder auch mit kommerzieller Lizenz eingesetzt werden kann. Es steht derzeit für Windows-, Unix- und Linux-Plattformen zur Verfügung. Eine Portierung für Mac OS ist vorgesehen. Das ältere MySQLGUI-Tool steht ebenfalls noch zum Download bereit. Weitere Arbeiten an diesem Tool werden aber aufgeschoben, da alle Anstrengungen derzeit dem MySQLCC-Tool gelten.

PostgreSQL 7.3.4

Ende der achtziger Jahre entstand die erste Postgres-Version an der Universität von Berkeley. Nach einer kurzzeitigen Einstellung der weiteren Arbeit am Produkt nach Version 4.2 im Jahr 1993 wurde eine Folgeversion im Jahr 1994 unter dem Namen Postgres95 veröffentlicht. Eine Rückkehr zur ursprünglichen Versionsreihenfolge begann dann mit Version 6.0 unter dem heute noch aktuellen Namen PostgreSQL. Die aktuelle Version 7.3.4 von PostgreSQL wurde Ende Juli freigegeben [6].

Im Vergleich zum Open Source-Konkurrenten MySQL zeichnet sich PostgreSQL durch eine umfassendere Unterstützung des SQL-Standards sowie generell durch mehr Features aus. Insbesondere die oben erwähnten Techniken Views, Stored Procedures und Trigger, auf die MySQL-Benutzer derzeit noch verzichten müssen, bietet PostgreSQL schon an. Weitere technische Fähigkeiten von PostgreSQL sind:

  • Referenzielle Integrität,
  • native Schnittstellen für ODBC, JDBC, C, C++, PHP, Perl, TCL, ECPG, Python und Ruby,
  • Sequences,
  • Vererbung,
  • Outer Joins,
  • Subselects,
  • benutzerdefinierte Datentypen,
  • Unterstützung des ACID-Prinzips (Atomicity, Consistency, Isolation, Durability) zur Transaktionsverarbeitung. Hierzu verwendet PostgreSQL die MVCC (Multi-Version Concurrency Control)-Strategie, bei der jeder Transaktion eine eigene Kopie des aktuellen Zustands der Datenbank (Snapshot) zur Verfügung gestellt wird. Während PostgresSQL auf fast allen Unix-Varianten verfügbar ist, läuft die Datenbank unter Windows nur in der Cygwin-Umgebung. MySQL dagegen kann als native Windows-Applikation bzw. als Dienst unter NT/2000/XP eingesetzt werden.

Welche der beiden vorgestellten Produkte soll nun als Open Source-Datenbank eingesetzt werden? Diese Frage lässt sich nicht durch eine klare Empfehlung für ein Produkt beantworten. Die Liste der angebotenen Funktionen spricht zunächst klar für PostgreSQL. Insbesondere die (derzeit noch) fehlende Unterstützung von Stored Procedures und Triggern durch die 4er-Versionen von MySQL wird in vielen Enterprise-Projekten bereits als entscheidendes Argument gegen MySQL gelten. Nicht umsonst hat PostgreSQL den Ruf, bzgl. Funktionsumfang und SQL-Standard-Unterstützung näher an den großen kommerziellen Datenbanken zu sein als MySQL. Wie oben bereits beschrieben, kann diese Konzentration auf wenige Features aber bei konkreten Projektanforderungen auch ein Vorteil von MySQL sein. Dies zeigt auch ein Blick auf Benchmark-Ergebnisse, bei denen beide Datenbanken verglichen werden. Naturgemäß haben unterschiedliche Benchmarks auf Grund der differierenden Ausgangssituationen meist auch verschiedene Ergebnisse im Performance-Bereich. Ein Performance-Vorteil von MySQL gegenüber PostgreSQL bei kleinen und mittleren Projekten mit einem Schwerpunkt auf Lese-Operationen ist allerdings fast immer zu erkennen. Je größer die Projekte werden und je mehr Zusatzfunktionen benötigt werden, desto mehr gewinnt PostgreSQL dann aber an Bedeutung.

Auf Grund des technischen Vorsprungs von PostgreSQL bringt ein Blick auf Nutzerzahlen und verfügbare Dokumentation ein etwas überraschendes Ergebnis. Hier hat nämlich MySQL die Nase vorn. Während genaue Nutzerzahlen auf Grund der freien Verfügbarkeit der Produkte schwer zu bekommen sind, zeigt eine Buch-Suche auf den deutschen Amazon-Seiten ein klares Bild: Zum Zeitpunkt der Erstellung dieses Artikels ergab eine Suche nach deutschsprachigen MySQL-Titeln 71 Treffer, während PostgreSQL nur 6 Treffer aufweisen konnte. Bei englischsprachigen Ausgaben ergab sich ein ähnliches Bild. Diese große Nutzerzahl ist sicher auf die enorme Popularität im Zusammenspiel mit PHP bei Web-Anwendungen zurückzuführen.

Fazit

In kleinen und mittleren Web-Projekten ist der Einsatz von Open Source-Datenbanken bereits gängige Praxis. Insbesondere MySQL erfreut sich im Zusammenspiel mit PHP hier großer Beliebtheit. Der größere Funktionsumfang von PostgreSQL bringt dieses Produkt in die Nähe der kommerziellen Datenbanken. Für die Zukunft verspricht vor allem MySQL auf Grund der angekündigten technischen Erweiterungen in den 5er-Versionen, dem Zusammenschmelzen mit der SAP DB sowie der heute schon großen Nutzerzahl zu einem durchaus ernstzunehmenden Konkurrenten für die großen kommerziellen Systeme von Oracle, IBM und Microsoft zu werden.

Zwischen MySQL und PostgreSQL herrscht sicher ein gesundes Konkurrenzverhältnis. Ein solcher Konkurrenzkampf wird aber im Open Source-Bereich bei weitem nicht so vehement geführt wie bei den kommerziellen Systemen. Beispielhaft sei hier ein Vergleich von MySQL und PostgreSQL erwähnt, der von MySQL zur Verfügung gestellt wird [8]. Dieser enthält natürlich zunächst eine detaillierte Auflistung der Vorteile von MySQL. Ebenfalls enthalten sind aber auch die Punkte, bei denen PostgreSQL die Nase vorn hat. Ein ähnlicher objektiver Vergleich im kommerziellen Bereich ist nur schwer vorstellbar, beispielsweise in Form von Angaben zu IBM DB2-Stärken auf den Oracle-Websites oder ernstgemeintem Lob für IBM in einer Keynote von Oracle-Chef Larry Ellison auf einer hauseigenen Konferenz.

Links und Literatur

Geschrieben von
Rudolf Jansen
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.