Freie Datenbanken im Unternehmenseinsatz: Ein Vergleich

Auch im Bereich der Datenbanken beginnt Open-Source-Software, sich ihren Platz im Markt zu erobern. Mit Firebird, Ingres, MaxDB, MySQL und PostgreSQL buhlen fünf Kandidaten um die Gunst der Anwender.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 23 Min.
Von
  • Jutta Horstmann
  • Dr. Oliver Diedrich
Inhaltsverzeichnis

Leicht gekürzter Vorabdruck aus dem Open Source Jahrbuch 2006. Der Text steht unter der Creative-Commons-Lizenz (Namensnennung - Weitergabe unter gleichen Bedingungen 2.5) und darf unter Nennung der Autorin und Beibehaltung der Lizenz auch in veränderter Form weitergegeben werden.

2005 war ein aufregendes Jahr bei den Open-Source-Datenbanken. Neue Versionen von MySQL (5.0) und PostgreSQL (8.0, 8.1) warteten mit wesentlichen Funktionserweiterungen auf. Oracle gelang mit dem Kauf von Innobase der Zugriff auf eine wichtige Komponente von MySQL: den InnoDB-Tabellentyp. Sun startete kommerziellen Support für PostgreSQL. Mit Bizgres steht seit diesem Jahr ein vollständiger Open-Source-Business-Intelligence-Stack zur Verfügung. Und schließlich wurde im November in Frankfurt die erste internationale Konferenz zum Thema Open-Source-Datenbanken veranstaltet.

Dieser Artikel vergleicht die Big 5 (Firebird, Ingres, MaxDB, MySQL, PostgreSQL) mit Blick auf ihren Einsatz im Rahmen großer Unternehmensanwendungen. Dabei soll es nicht darum gehen, eine Rangliste zu produzieren. Der Ansatz ist vielmehr, dass für jede Aufgabe das passende Werkzeug verwendet werden sollte: Die Entscheidung für ein bestimmtes Datenbankmanagementsystem (DBMS)muss sich an den Anforderungen des jeweiligen Einsatzszenarios orientieren.

Gerade in Unternehmen mit wenig Erfahrung mit Open-Source-Software stehen viele Entscheider diesem Softwareentwicklungsmodell skeptisch gegenüber. Man befürchtet informellen Support, mangelnde langfristige Planung, ein kompliziertes Wirrwarr unterschiedlicher Lizenz-Modelle, unklare Haftbarkeiten und erhöhten administrativen Aufwand. Speziell Open-Source-Datenbanken wird ein Mangel an Features im Vergleich zu den proprietären Pendants wie Oracle oder MS SQL Server unterstellt. Und nicht zuletzt stellt sich die Frage nach der Verfügbarkeit von Applikationen, die in der Lage sind, mit Open-Source-Datenbanken zusammenzuarbeiten.

Einige dieser Befürchtungen sind leicht zu entkräften. So gibt es für alle fünf großen Open-Source-Datenbanken Anbieter kommerziellen Supports: MySQL AB für MySQL, Computer Associates und Ingres Corp. für Ingres, IBPhoenix (international) und HK-Software (Deutschland) für Firebird, SAP AG und MySQL AB für MaxDB und eine große Auswahl internationaler Firmen (darunter Fujitsu und Sun) für PostgreSQL (im deutschsprachigen Raum beispielsweise credativ und Cybertec). Und die Entwickler der jeweiligen Software direkt per IRC, Mail, Foren oder Bug-Tracker ansprechen zu können, ist für viele AnwenderInnen hilfreicher als die Nutzung einer Telefon-Hotline.

In eine ähnliche Richtung gehen Fragen der Gewährleistung und Haftbarkeit. Bei den drei Datenbanken, die Firmen gehören (MySQL, Ingres, MaxDB), ist auf jeden Fall genauso viel (oder wenig) Haftung wie bei Closed-Source-Software zu erwarten. Was die langfristige Planung anbelangt, so finden sich auf den Webseiten fast aller Open-Source-Datenbanken ausführliche Roadmaps.

Das Thema Lizenzierung ist schon etwas komplizierter. Die fünf großen Open-Source-Datenbanken lizenzieren alle auf unterschiedliche Weise: Firebird verwendet die eigene Interbase Public License (IPL), Ingres die Computer Associates Trusted Open Source License (CATOSL), MySQL und MaxDB duale Lizenzierung (GPL und kommerziell) und PostgreSQL steht unter der BSD-Lizenz.

Das Vorurteil eines erhöhten administrativen Aufwandes und geringerer Benutzerfreundlichkeit bei Open-Source-Software bestätigt sich im Datenbankbereich nicht: Neben sehr ausgereiften Kommandozeilen-Werkzeugen bringen alle fünf Datenbanken selbstverständlich auch Tools mit grafischen Oberflächen mit. Meist sind sie sogar einfacher zu administrieren als ihre proprietären Gegenparts.

Zwei Argumente gegen den Einsatz von Open-Source-Datenbanken wiegen jedoch schwer. Zum einen ist dies die Frage nach der Unterstützung durch Software-Hersteller. Also: Kann ich das Datenbankdesign-Tool oder die Business Intelligence Suite, die ich bisher mit proprietären Datenbanken genutzt habe, weiter einsetzen? Die Antwort lautet immer noch oft: Leider nein.

Und zweitens muss man den Umfang an unterstützten Features erwähnen. Obwohl alle fünf Open-Source-Datenbanken einen sehr großen Funktionsumfang mitbringen, gibt es doch immer wieder Anforderungen, bei denen einzelne oder sogar alle passen müssen. Materialized Views, eine Technik, die im Data-Warehouse-Bereich genutzt wird, um die Bereitstellung von Daten auf komplexe Abfragen zu beschleunigen, stellt zum Beispiel keines der Projekte zur Verfügung.

Die Argumente für Open-Source-Datenbanken sind dieselben wie für Open-Source-Software im Allgemeinen: niedrige Kosten und die Vorteile des Open-Source-Softwareentwicklungsmodells. Kostenberechnungen sind allerdings kompliziert, weil man nicht nur die Lizenzkosten, sondern auch die mit dem Einsatz und der Administration der Software verbundenen Arbeitskosten mit berücksichtigen muss. MySQL zum Beispiel nimmt in einem White Paper für sich in Anspruch, weniger als halb so viel Kosten zu verursachen wie der Einsatz einer Closed-Source-Datenbank.

Aber neben niedrigeren Kosten hat Open-Source-Software einen weiteren ganz entscheidenden Vorteil: der offene Quellcode. Der Einsatz von Open-Source-Datenbanken in einem Unternehmen bringt die folgenden Vorteile mit sich:

  • Teilhabe an einer weltweiten Community inklusive direktem Zugang zu den EntwicklerInnen, zu umfassender Dokumentation und Support.
  • Unabhängigkeit von einzelnen Anbietern und Produkt-Lebenszyklen.
  • Ein hohes Sicherheits-Niveau aufgrund ständiger Überprüfung des Codes durch eine internationale Entwicklergemeinschaft und schnelle Fehlerbeseitigung.
  • Flexible Anpassungen und Erweiterungen der Software entsprechend der eigenen Anforderungen, indem fehlende Funktionen selbst (oder von beauftragten EntwicklerInnen) hinzugefügt werden.