In diesem Artikel vergleichen wir aktuelle relationale Datenbank-Management-Systeme (DBMS), insb. entsprechende Open-Source-Systemen (OSS).

Inhalt:

Übersicht relationaler Datenbank-Systeme

Bei Software-Neuentwicklungen stellt sich u.a. auch die Frage nach dem einzusetzenden Datenbank-Management-System (DBMS). Da eine einmal eingesetzte Datenbank in klassischen und / oder größeren IT-Umfeldern i.d.R. nicht mehr so schnell ausgetauscht wird, sollte man sich gut überlegen, auf welches System man setzt. Nach Klärung der grundsätzlichen Frage ob eine relationale oder eine noSQL-Datenbank zum Einsatz kommen soll, steht anschließend die konkrete Entscheidung für eines der zahlreichen Systeme an.

Verbreitung der Systeme

Um sich einen ersten Überblick zu verschaffen, aber auch um eine bewusste Entscheidung für oder gegen eines der Systeme treffen zu können, ist es hilfreich, die Verbreitung der Datenbanken heranzuziehen. Die quantitative Näherung an das Thema hilft auch, das Teilnehmerfeld für die i.d.R. aufwendigere qualitative Bewertung entsprechend einzugrenzen. Darüber hinaus lässt sich von der Verbreitung eines Systems auch ein Rückschluss auf die Support-Fähigkeit ziehen: je verbreiteter ein System ist, desto eher werde ich im Problemfall jemanden finden, der mir helfen kann. Außerdem kann auch die Zukunfts-Fähigkeit auf dieser Basis ähnlich taxiert werden.

Marktanteile sind häufig aber nur für kommerzielle Systeme zu finden und dort meist auch nur eingeschränkt. Installationszahlen lassen sich für einige Systeme finden, aber nicht für alle und die Erhebung dieser Werte ist nicht immer transparent.

Eine alternative Methode, auch nicht perfekt, so aber doch bspw. für Programmiersprachen mit dem TIOBE Index oder RedMonk Ranking mittlerweile akzeptiert, ist die Auswertung von entsprechenden Nennungen im Internet. Hierbei werden Suchmaschinen wie Google, Bing, Yahoo, etc., aber bspw. auch Stellenanzeigen auf LinkedIN und Diskussionen auf Stack Overflow o.ä. ausgewertet; die Häufigkeit der Nennung lässt einen objektiven Rückschluss auf die Verbreitung einer Technologie zu.

Auch für Datenbanken hat sich hierzu mittlerweile mit db-engines.com ein entsprechendes Angebot etabliert, deren Ranking und Filterung wir in diesem Artikel ebenfalls als Basis nehmen. Dort werden regelmäßig über 200 DBMS entsprechend ausgewertet, davon über 100 relationale Datenbanken:

db-engines.com Datenbank-Ranking

Lizenztyp: Kommerziell vs. Open Source

Der erste »echte« Entscheidungspunkt dürfte in vielen Vorhaben das Lizenzmodell sein. Soll es ein kommerzielles Lizenzprodukt wie Oracle, DB/2 oder Microsofts SQL Server sein oder ein Open-Source-System wie PostgreSQL, MySQL/MariaDB oder SQLite?

Bei der Entscheidung für eine kommerzielle Datenbank greifen i.d.R. eher organisatorisch/strategische denn technologische Faktoren, da diese Systeme nunmehr alle seit über 25 Jahren im Markt bestehen und als ausgereift gelten können. Hier zählen meistens eher Aspekte wie z.B. eine bestehende Vertragsbeziehung zu entsprechenden Anbietern, vorhandene Lizenzen oder insb. auch im Unternehmen vorhandenes Know-how um das jeweilige Produkt. Im Falle des MS SQL Servers ist bspw. auch immer wieder die Integrationstiefe ein entscheidendes Kriterium: sind bereits viele Microsoft-Produkte im Einsatz und / oder wird auf Basis Microsoft-Technologien entwickelt, so greift man auch gerne zur entsprechenden Datenbank. In Anbetracht der Produktreife und organisatorisch häufig anzutreffenden Rahmenbedingungen ein nachvollziehbarer Schritt, wobei beim MS SQL Server damit das Betriebssystem im Gegensatz zu den anderen DBMS dann allerdings gleich auch festgeschrieben ist, da der SQL Server als einziges der betrachteten Systeme nur unter Windows läuft.

Mittlerweile stehen fast genauso viele OSS Datenbanken wie kommerzielle Varianten zur Verfügung und immer mehr Organisationen entscheiden sich gegen den Einsatz eines kommerziellen DBMS:

db-engines.com Trend Open-Source Datenbank-Systeme

Hinsichtlich der organisations-internen Gründe für ein kommerzielles System lässt sich von außen keine echte Entscheidungshilfe geben, so dass wir uns hier auf die Open-Source Datenbanken konzentrieren.

Auswahl der Open-Source DBMS

Selektiert man die Top-15 der relationalen Datenbank-Management-Systeme bei db-engines.com nach Open-Source-Systemen, ergibt sich Stand Mai 2015 folgende Auswahl bzw. Top-5 der relationalen OSS Datenbanken, welche wir näher beleuchten werden:

  1. MySQL
  2. PostgreSQL
  3. SQLite
  4. MariaDB
  5. Firebird

Bewertungskriterien

Zur Bewertung der Datenbanken kommen neben den voran genannten eher organisatorischen und strategischen Kriterien (Lizenzmodell, Kosten, Zukunfts- und Support-Fähigkeit) insb. die folgenden technischen Kriterien zum Einsatz. Es handelt sich dabei um eine (nicht vollständige) Auswahl von Faktoren, welche sich in Projekten als relevant herausgestellt haben und welche für eine erste Näherung ohne Kenntnis eines genauen Szenarios hilfreich sein könnten:

  • Footprint - wie viel Speicher und / oder CPU benötigt die Datenbank?
  • SQL-Standard - inwieweit werden welche SQL-Standards eingehalten?
  • Features - gibt es besondere Features, besonders viele oder fehlen welche?
  • Performance - wie schnell erfolgen die Zugriffe in einem kleinen, mittleren und großen Test-Szenario (Kunden, Produkte, Rechnungen via JDBC anlegen und abfragen).
  • Admin-Aufwand - wie eingängig / leicht ist Installation und Wartung der Datenbank? Hierzu gehört bspw. auch das Thema Dokumentation des Systems.

Bewertung der ausgewählten Open-Source DBMS

MySQL

Das relationale Open-Source Datenbankmanagementsystem mit der weltweit weitesten Verbreitung ist seit 1995 am Markt und liegt seit Februar 2015 in der Version 5.6.23 vor.

Nach der Übernahme von Sun durch Oracle ist die Datenbank nur noch für nicht-kommerzielle Einsatzzwecke Open Source. Darüber hinaus ist eine kommerzielle Lizenz verfügbar, wobei die Lizenz-Situation Oracle – GPL sehr undurchsichtig ist. Bei der Entscheidung für MySQL im professionellen Einsatz erscheint eine kommerzielle Lizenz angebracht. Neue Features kommen teilweise gar nicht mehr in die Open Source Version und einige Funktionen (Monitoring, etc.) sind nur in der kommerziellen Lizenz enthalten.

Die Zukunftsaussichten von MySQL sind schwer einzuschätzen. Die Verbreitung ist nach wie vor immens, aber es ist unklar, was Oracle mittel- bis langfristig mit dem Produkt vor hat. Außerdem ist die Unterstützung aus der Open-Source Community seit der Übernahme von Oracle rückläufig.

Hinsichtlich unterstützter Betriebssysteme, etc. gibt es nahezu keine Einschränkungen, wobei das System seine Wurzeln in der Unix-Welt hat und die Unterstützung für Windows dementsprechend und naturgemäß etwas hinter her ist.

Der Footprint ist mit rund 100 MB für eine initiale Installation (unter Unix) nebst leerer Datenbank überschaubar.

Aufgrund der weiten Verbreitung sind sowohl die Administrations-Tools entsprechend ausgereift als auch die Dokumentation auf einem guten Niveau. Als Server-System erfordert die Administration einer MySQL natürlich etwas mehr Aufwand bzw. ist komplexer als bspw. ein SQLite.

Es wird sowohl Master-Master- als auch Master-Slave-Replikation »built-in« unterstützt.

Die gängigen SQL-Standards werden eingehalten, wobei lt. Eigenaussage nicht sklavisch deren Einhaltung gefolgt wird und im Zweifelsffall die Einhaltung des Standards auch anderen Prioritäten (Performance, Features, etc.) geopfert wird.

Aus der Vielzahl von Features besticht insb. die Möglichkeit, verschiedene sog. Storage-Engines zu nutzen. Dadurch lassen sich bspw. Daten in unterschiedlichen Formaten (CSV) oder auf anderen Servern (FEDERATED) verarbeiten. Die ursprüngliche Storage-Engine (myISAM) ist extrem schnell, unterstützt dafür aber keine Transaktionen. Diese bringt wiederum die sog. INNODB mit.

Dadurch sind allerdings auch Performance-Vergleiche der MySQL mit Vorsicht zu genießen: vor Version 5.5 war myISAM die Standard-Storage-Engine, die natürlich ohne den »Ballast« des Transaktions-Handlings schneller ist als eine transaktionale Datenbank. Weitere Performance-Betrachtungen sind aufgrund der sich aus der Lizenz-Situation ergebenden, eher abschlägigen Bewertung nicht erfolgt.

MySQL ist technisch sehr ausgereift mit dem interessanten Feature der verschiedenen Storage Engines und das nach wie vor am weitesten verbreitete Open-Source DBMS. Leider ist es mittlerweile quasi ein kommerzielles System und dazu mit etwas ungewisser Zukunft.

PostgreSQL

Das freie objektrelationale Datenbankmanagementsystem PostgreSQL liegt seit Februar 2015 in der Version 9.4.1 vor. Es unterliegt einer BSD- oder MIT-ähnlichen Open-Source Lizenz. Das System geht auf Vorläufer in den frühen 1980ern an der University of California in Berkeley zurück und ist offiziell 1989 erschienen.

Hinsichtlich unterstützter Betriebssysteme, etc. gibt es auch bei der PostgreSQL nahezu keine Einschränkungen; auch dieses System hat seine Wurzeln in der Unix-Welt, wodurch die Windows-Unterstützung ggf. nicht ganz so »rund« wirkt.

Erst ab 2008 / mit Version 8.x wurde die Replikation überhaupt in den Kern-Umfang der PostgreSQL aufgenommen; bis dahin wurde auf »externe« Tools / Add-ons (Slony, pgPool, Continuent, Londiste) für die Replikation gesetzt. Dies merkt man der PostgreSQL auch heute noch an: die überwiegenden bzw. ausgereifteren Replikations-Mechanismen finden sich nicht im Standard-Distributions-Umfang, sondern sind über zusätzliche Tools abgebildet, insb. Master-Slave- (asynchron als auch synchron) und Multi-Master-Replikation (asynchron; synchron nur in Enterprise-Edition).

2008 ist zwar schon etwas her, aber scheinbar ist das Thema entweder zu komplex oder wird nur halb-herzig verfolgt. Einzig das sog. »Transaction Log Shipping« ist mittlerweile als »built-in« Mechanismus für Replikations-Ansätze vorhanden. Hierbei können warm und hot standby Server durch Lesen des sog. write-ahead Logs permanent (asynchron und synchron) auf dem Laufenden gehalten werden. Hot standby Server können dann wiederum auch als Quelle für zumindest Lese-Operationen anderer Systeme auf diesem dann gemeinsamen Datenbestand dienen.

Es bleibt der Eindruck, dass man sich hier nur dem Markt-Druck gebeugt hat und jetzt auch »mal was zur Replikation« macht, aber eigentlich nach wie vor diesbzgl. auf die Zusatz-Tools setzt.

Allen genannten Replikations-Ansätzen ist gemein, dass sie max. bis auf Tabellen-Ebene herunter gehen; eine Replikation auf Spalten-Ebene ist unter PostgreSQL mit Zusatz-Tools möglich.

Der vom Kern-Entwickler-Team ausgegebene Fokus von PostgreSQL ist auf der Integration mit bzw. Migration von / zu anderen Datenbanken sowie der Einhaltung des SQL-Standards.

Besonders zu nennende Features der PostgreSQL sind zum Einen die Vererbung, womit Tabellen als Erweiterung bestehender Tabellen definiert werden können und zum Anderen die mit Version 9.3 eingeführte Erweiterung des SQL-Standards MED, um externe Datenquellen aus der Datenbank heraus ansprechen zu können. Daten im JSON- und XML-Format können mittlerweile von der PostgreSQL auch direkt verarbeitet werden.

In unseren Performance-Untersuchungen war die PostgreSQL den anderen Server-Datenbanken hinsichtlich Zugriffszeiten z.T. deutlich überlegen.

Der Footprint einer anfänglichen Installation nebst leerer Datenbank ist mit rund 70 MB sehr überschaubar.

Die PostgreSQL ist extrem gut dokumentiert - hier spürt man die Reife des Systems. Als Server-System hat die Datenbank einen etwas höheren Administrationsaufwand. Das Filesystem wirkt etwas komplizierter als bspw. bei einer MariaDB / MySQL, dies ist aber vermutlich nur eine anfängliche Auffälligkeit.

Die PostgreSQL ist sicherlich das ausgereifteste Open-Source DBMS hinsichtlich Integration mit anderen Datenbanken und Einhaltung des SQL-Standards. Dadurch ist sie natürlich z.B. besonders dort interessant, wo es um den häufigen Austausch mit unterschiedlichen anderen Datenbanken geht. Bei speziellen Anforderungen hinsichtlich Replikation sollten die verfügbaren Zusatztools diesbzgl. genau geprüft werden.

SQLite

Das freie relationale Datenbankmanagementsystem liegt seit April 2015 in der Version 3.8.9 vor. Das System ist gemeinfrei, also in der sog. public domain und seit 2000 verfügbar.

Mit rund 300 kByte ist die SQLite das kleinste der betrachteten DBMS, es handelt sich allerdings auch um keinen klassischen DB-Server, sondern um eine Bibliothek, welche dem einbindenden (»embedded«) Prozess (»in-process«) eine extrem schnelle, transaktionale SQL Datenbank-Engine bereitstellt.

Die bringt natürlich gewisse Einschränkungen mit sich: Der Zugriff mehrerer Prozesse auf eine Tabelle ist parallel nicht möglich, Replikation wird nicht unterstützt und es gibt bspw. keine Benutzer-Verwaltung.

Andererseits findet sich die gesamte Datenbank in einer einzigen Datei; der Administrationsaufwand geht also gegen Null.

Aufgrund der nicht vergleichbaren Architektur wurden keine weiteren Performance-Betrachtungen unternommen.

SQLite kommt in Mobiltelefonen und als Browser-DB zum Einsatz, aber bspw. auch in Apples Mail und Skype. Dadurch ist sie mittlerweile auf nahezu allen Systemen bereits vorhanden. Gerade im Zusammenspiel mit HTML5 für offline-fähige Web-Applikationen ist sie auch eine interessante Wahl.

Die SQLite ist eine sehr leicht-gewichtige, schnelle und die einzig wirklich freie Datenbank; wer mit den Einschränkungen leben kann findet in ihr für kleine Persistierungsaufgaben das ideale System.

MariaDB

Bei der MariaDB handelt es sich um eine »echte« Open-Source Abspaltung von MySQL durch deren früheren Hauptentwickler. Nach der Oracle-Übernahme wollte er eine verbesserte, insb. wieder Community-getriebene, dabei aber binärkompatible Alternative zur MySQL bieten. Das relationale Datenbankmanagementsystem ist 2009 erschienen und liegt seit Februar 2015 in der Version 10.0.17 vor. Es unterliegt einer GPL2 Open-Source Lizenz.

Die Kompatibilität der beiden Datenbanken geht soweit, dass »unterhalb« der MariaDB bspw. nach wie vor noch eine Vielzahl der ursprünglichen MySQL-Programme am Werk sind: mysqld zum Starten des MySQL-Server-Prozesses, mysqladmin als Administrations-Tool und mysql als Zugrifss-Client auf die Datenbank und die MySQL Workbench, um nur einige Beispiele zu nennen. Damit finden sich MySQL-erfahrene Nutzer und Admins mit der MariaDB sofort zurecht und alles zur MySQL o.g. lässt sich hier 1:1 übertragen: es handelt sich um ein Unix-basierendes System, welches auf allen gängigen Betriebssystem-Plattformen läuft und bietet sehr interessante Features, u.a. eben auch die Storage Engines.

Darüber hinaus entwickelt sich die MariaDB dank Ulf Michael Widenius und der Community sehr dynamisch weiter und bietet mittlerweile spannende weitere Features. So gibt es zusätzliche Storage Engines, um bspw. Daten direkt in XML oder JSON speichern zu können (CONNECT) bzw. auch, um eine Art »row-based Replication« zu ermöglichen (ebenfalls CONNECT) sowie auch, um direkt eine Cassandra (NoSQL)-DB anzusprechen. Vielleicht kein dauerhaft vernünftiges Setup, aber für bswp. Migrations-Szenarien äußerst interessant.

Es werden diverse Replikationsansätze »built-in« unterstützt: Master-Slave, synchron/asynchron/semi-synchron und Multi-Source, wobei synchron der Enterprise Edition vorbehalten ist. Es kann single-threaded oder auch multi-threaded mit parallelen Worker-Threads und dann bis zu 10-fach besserer Performance repliziert werden.

Die Replikation erfolgt bei der MariaDB über das sog. »binary log«. Wenn selbiges aktiviert ist, können Replikationspartner darüber jegliche Veränderungen sowohl der Datenstruktur (»data definition«) als auch der Inhalte (»data manipulation«) nachvollziehen.

Dabei können ganze Datenbanken, einzelne Tabellen oder auch einzelne Datensätze (»row-based«) repliziert werden.

Spaltenweise Replikation wird nicht direkt unterstützt, es existieren bei der MariaDB aber zwei Lösungsansätze hierfür: per Script oder der Storage Engine CONNECT.

Mit der Storage Engine CONNECT können verteilte Datenbanken per MySQL oder ODBC angesprochen, als ob die Tabellen in der lokalen Datenbank vorlägen. Die Tabellen können dabei bspw. auch als JSON oder XML vorliegen. Auf die per CONNECT angebundenen verteilten Tabellen besteht Lese- und Schreibzugriff, wobei letzteres wg. der in diesem Fall langsameren Indexbildung mit Vorsicht zu genießen ist. Es kann auch nur auf ein Sub-Set der Spalten (»vertical partitioning«) bzw. alternativ auch nur auf ein Sub-Set der Daten (»sharding« / »horizontal partitioning«) zugegriffen werden. Wobei beachtet werden muss, dass diese Storage Engine für Anwendungen im Umfeld BI / DWH (Online Analytical Processing »OLAP«) gedacht ist. Ihre Eignung für klassische Datenbank-Anwendungsfälle (Online-Transaction-Processing »OLTP«) ist zu überprüfen.

Außerdem sei noch erwähnt, dass mit Version 10 die meisten Änderungen an der Tabellenstruktur (»DDL«) online, also im laufenden Betrieb der Datenbank möglich sind; hiermit fällt ein großer Vorteil der Schema-losen Datenbanken weg!

Die zusätzlichen Features machen sich mit rund 115 MB in einem etwas größeren Footprint der MariaDB bemerkbar und die Doku wirkt noch nicht so reif wie bspw. bei einer PostgreSQL oder auch MySQL; häufig landet man bei der Suche auch nach Dokumentation für die MariaDB dann auch wieder auf den Oracle-Seiten zur MySQL.

Die Zugriffszeiten auf normalen Systemen / mit SSDs sind vergleichbar zur PostgreSQL, bei kleineren Systemen und insb. bei Einsatz von HDDs bleibt die Performance hinter der PostgreSQL zurück.

Die Zukunftsaussichten der MariaDB sind gut. Das System ist zwar noch vergleichsweise neu und damit auch noch nicht so etabliert, es gibt aber eine starke Community und immer mehr große und zugkräftige Organisationen wie bspw. Wikipedia oder auch Google ersetzen ihre MySQL-Installationen durch eine MariaDB aufgrund der Lizenz-Situation mit Oracle.

Die MariaDB ist quasi die »junge Wilde« unter den betrachteten relationalen OSS Datenbanken. Sie ist wie eine MySQL, aber bringt mehr und interessantere Features mit und ist ein »echtes« Open-Source-System.

Firebird

Die historischen Wurzeln des relationale Open-Source Datenbanksystems Firebird gehen zurück bis ins Jahr 1981 zum kommerziellen Vorgänger InterBase aus dem Hause Borland, aus dem es im Jahre 2000 abgespalten wurde. Aktuell liegt das DBMS in der Version 2.5.4 vom 30. März 2015 vor und steht unter einer IDPL-Lizenz (abgeleitet aus der Mozilla Public License).

Firebird unterstützt diverse Betriebssysteme (Unix-Derivate sowie Windows), hat seine Wurzeln offensichtlich in der Windows-Welt und verfügt dabei aber über zahlreiche Treiber und Bibliotheken. Das DBMS bietet alle grundlegenden Funktionen, die für den Aufbau und die Nutzung einer relationalen Datenbank erforderlich sind.

Replikation wird nur über Fremdprodukte oder bspw. Eigenentwicklungen mittels der sehr flexiblen User Defined Functions (UDFs) ermöglicht. Der SQL-Standard wird an einigen Stellen, bspw. bei Transaktionen verletzt und durch die flexiblen UDFs wird man sich ggf. schnell von der Firebird »abhängig« machen. Hier hat uns der nette Hinweis in der Dokumentation gefallen, dass man, nur weil man eine Schaufel in die Hand bekommt, ja nicht unbedingt selbst sein Grab schaufeln muss. Joins über mehrere Datenbanken werden nicht direkt, sondern nur über Umwege unterstützt.

Mit rund 30 MB und einer sehr einfachen Dateistruktur hat die Firebird für ein vollwertiges Datenbank-System, welches sowohl als Server-System als auch »embedded« betrieben werden kann, einen erstaunlich kleinen Footprint. Sie ist sehr leicht zu administrieren, die Performance bricht bei 250.000 Datensätzen allerdings um den Faktor fünf im Vergleich zur PostgreSQL und MariaDB ein.

Bei all den technologisch durchaus interessanten Punkten sind die Zukunftsaussichten der Firebird allerdings schwierig. In einer Studie von Ende 2014 wird sie im Quadranten »The Past« eingestuft und im Ranking von db-engines.com weist sie bereits einen klaren Abwärtstrend auf. Außerdem darf man sich hier auch vom Platz 5 nicht täuschen lassen: die Verbreitung in Deutschland oder auch Europa ist weitaus geringer; im Ranking profitiert die Firebird von der historisch starken Nutzung in Russland und Südamerika. Eine Anfrage bei Gulp brachte Stand Mai 2015 ganze 37 Spezialisten im deutschsprachigen Raum zu Tage, die Firebird-Know-How lt. Eigenaussage haben. In Kundenprojekten fanden wird dieses System erst einmal vor. Wir kennen auch nur einen Experten auf diesem Gebiet in Deutschland, dessen Verfügbarkeit und Konditionen ein dauerhaftes Support-Modell allerdings fraglich erscheinen lassen. Ob die kleine russiche Entwickler-Community hier verlässlicher ist, vermögen wir nicht zu beurteilen. Auf der Roadmap für Version 3 und 4 der Firebird und damit vermutlich bis 2020 sind nach unserer Einschätzung keine großen technologischen Anpassungen oder Ideen, wie bspw. die NoSQL-Integration einer MariaDB, erkennbar. Was auch durch unsere diesbzgl. Anfrage bei den Kern-Entwicklern in Russland bestätigt wurde.

Die Firebird ist technologisch gesehen eine gute relationale Datenbank; wenn der Fokus auf einem kleineren System, in einer Windows-nahen Infrastruktur und ohne innovative Anforderungen ist. Insb. die Support-Situation als auch die Zukunftsaussichten der Datenbank sind allerdings schwierig.

Fazit

Die Top-5 Open-Source DBMS sind interessante Datenbanken mit teils nicht vergleichbarem Funktionsumfang bzw. Fokus. Nichtsdestotrotz ergeben sich drei Favoriten: Wenn ein kleines »embedded« DBMS gefordert ist, bietet sich SQLite an. Wer auf der sicheren Seite bzgl. seiner Datenbank-Wahl sein möchte und Wert auf Einhaltung des SQL-Standards und Integrationsfähigkeit legt, sollte sich die PostgreSQL genauer anschauen. Wem Funktionsvielfalt und innovative Features sowie Replikation bei seinem DBMS wichtig sind, der ist mit der MariaDB gut bedient.

Der Vergleich der DBMS in der tabellarischen Übersicht sowie weitere Details, insb. bzgl. Replikation und Performanceverhalten gerne auf Anfrage.