MariaDB als strategische Entscheidung
Dieser Artikel diskutiert den Einsatz von MariaDB anstelle von MySQL gerade auch unter strategischen Aspekten. Bei MariaDB handelt es sich um einen grundsätzlich zu MySQL kompatiblen Fork. Die Diskussion wird sich an folgenden drei Punkten orientieren: Dual-Vendor-Strategie, Lizenzierung und dem technischen Vergleich.
Dual-Vendor-Strategie mit MariaDB
Viele - gerade größere - Kunden nutzen neben Oracle auch MySQL als Datenbank. Einige setzen mit Absicht auf ein weiteres Datenbanksystem - der sogenannten Dual-Vendor-Strategie folgend - so dass das Unternehmen nicht von einem einzigen Zulieferer abhängig ist. Der (Mit-)Kauf von MySQL durch die Sun-Übernahme hat MySQL für viele neue Firmen durchaus interessant gemacht und neue Kundenkreise eröffnet. Gerade weil MySQL nun zum Portfolio von Oracle gehört. Firmen wiederum, welche MySQL unter dem Aspekt des Dual-Vendors betrieben, können durch einen Wechsel auf MariaDB (da grundsätzlich kompatibel) die Installationen ersetzen und ausbauen, ohne die Strategie aufzugeben oder nach einem anderen (nicht kompatiblen) Produkt Ausschau zu halten.
Lizenzierung von MySQL und MariaDB
Das Thema der Lizenzierung ist komplex. Für Leser, die bei Lizenzierungsmodellen wie jenen von Oracle keine Bedenken haben, ist es vielleicht irrelevant. Der folgende Abschnitt muss vor dem Hintergrund verstanden werden, dass der Autor ein OpenSource-Evangelist ist. So vertritt er die Annahme, dass die Verwendung von OpenSource-Software eine gute Strategie ist, da diese sich als investitionssicherer erweisen als Produkte, die vom Gusto eines Herstellers abhängig sind – sei es in Bezug auf Preisgestaltung, Weiterentwicklung oder gar Einstellung des Produkts.
OpenSource-Lizenzen beziehen sich auf die Verwendung des Quellcodes. Ein wichtiger Aspekt ist hier, dass durch die Installation und den Betrieb der Software keine Lizenzkosten entstehen. MySQL existiert unter einer Dual-Lizenz: Sowohl unter der GPL (einer OpenSource-Lizenz), als auch unter einer proprietären.
Die GPL verlangt, dass Modifizierungen am Code bei einem Vertrieb des geänderten Produkts weiterhin unter der GPL stehen. Das beinhaltet den Zugang zum Quellcode. Einzig Oracle als der Inhaber des Copyrights ist in der Lage, MySQL unter einer anderen proprietären Lizenz (hier das Enterpriseprodukt) zu vertreiben. Dieses Lizenzmodell legt fest, ob überhaupt Instanzen installiert und betrieben werden dürfen. Lizenzmodelle im Rahmen von OpenSource beschränken sich auf den Support von Installationen und sind als Angebote zu sehen. Die Verwendung von Software, die unter GPL (OpenSource) steht, wird generell nicht reglementiert.
Neben dem freien Betrieb der Software unter GPL ermöglicht diese Lizenz vielen Anbietern, Support für diese Software zu liefern. Gerade der freie Zugang zum Quellcode erlaubt anderen Marktteilnehmern Bugfixing und Optimierungen in den Sourcen.
Betrachten wir MySQL und MariaDB unter dem Lizenz-Aspekt. MariaDB selbst ist ein Fork von MySQL, steht damit unter der GPL. Auch MySQL ist unter der GPL, aber auch proprietär mit Erweiterungen verfügbar.
Wird die GPL-Version von MySQL eingesetzt, spielt es unter dem Topik der Lizenzierung erstmal keine Rolle ob MariaDB oder MySQL verwendet wird. Interessant wird die Diskussion dann aber unter zwei Gesichtspunkten: Während MariaDB die Lizenz (GPL) nicht ändern kann, besteht diese Beschränkung für Oracle keineswegs. Eine diesbezügliche Vereinbarung mit der EU, welche bei der SUN-Übernahme geschlossen wurde, terminiert am Ende des Jahres. Dies bedeutet aber nicht zwangsläufig ein Ende neuer GPL-Versionen von MySQL. Macht aber auf die vorher erwähnte Abhängigkeit von dem Gusto des Herstellers aufmerksam.
Wird derzeit eine MySQL-Enterprise-Version verwendet, so ist für den Betrieb eine Lizenz erforderlich. Ein Wechsel zu MariaDB hätte eine Migration zur Folge. Der Vorteil läge darin, dass für den Betrieb der Datenbanken keine Kosten für Lizenzen entstehen. Auch kann man sich auf dem Markt umschauen, von wem die Installation supportet werden soll. Die Enterprise-Version von MySQL enthält proprietäre Erweiterungen, wie z.B. Audit Plugin und Connection Pooling. Kunden, die sich aufgrund dieser Features für die Enterprise-Version entschieden haben, sollten wissen, dass sich Erweiterungen mit dem gleichen Funktionsumfang auch im Portfolio von MariaDB und damit unter der GPL befinden. So könnte alleine die Verwendung solcher Erweiterungen einen Einsatz von MariaDB begründen.
Im Rahmen der Lizenzdiskussion sollte noch erwähnt werden, dass viele der großen Linux-Distributionen – nämlich die zu RHEL und SUSE-Familie gehörenden – mittlerweile MariaDB anstelle von MySQL als Standard ausliefern. Bei Debian und Ubuntu werden sowohl MariaDB als auch MySQL mitgeliefert. Grund war unter anderem, dass Teile der Bugdatenbank, wie auch die dann passenden Regressionstests, nicht mehr zugänglich sind. Klar scheint zu sein, dass auf Seiten der Community der Trend zu MariaDB geht. Als nettes Bonnement ist zu sehen, dass Oracles Linuxdistribution Unbreakable Linux auch mit MariaDB ausgeliefert wird. Auch wenn diese eher der 100%-Binärkompatibilität zu RHEL geschuldet ist.
Bemerkenswerterweise bietet MariaDB Client-Libraries unter der LGPL an. Dies dient vor allem der Rechtssicherheit. Die herkömmlichen MySQL Client-Libraries stehen – wenn nicht als kommerzielle Lizenz – unter der GPL. So ist es fraglich, ob Programme, welche gegen diese Libraries gelinkt sind, auch unter der GPL stehen. Dies führt dazu, dass Hersteller proprietärer Produkte, die sich die MySQL Client-Libraries linken, eine Lizenz von MySQL/Oracle erwerben. Dies ist mit den unter der LGPL stehenden Client Libraries von MariaDB nicht mehr notwendig.
Technischer Vergleich MySQL und MariaDB
Beim Vergleich von MariaDB und MySQL gilt es zwei Bereiche zu unterscheiden. Mit der Corefunktionalität ist die grundsätzliche Funktionsweise – wie von der GPL-Version von MySQL zur Verfügung gestellt – gemeint. Es ist nicht zu übersehen, dass Oracle eine Menge Energie in MySQL steckt. So ist Oracle federführend bei der Entwicklung der Default Storage Engine InnoDB. Sie gehört auch zu Oracle. Replikation und der Optimizer erfahren viel Aufmerksamkeit. Im Großen und Ganzen werden viele Teile – auch der Kompatibilität wegen – in MariaDB übernommen. Dies gilt insbesondere für InnoDB. Hier nutzt MariaDB zwar XtraDB, welches selbst ein Fork von InnoDB ist, als default. Die Unterschiede sind hierbei nicht essentiell. Zudem erlaubt MariaDB auch das Starten mit InnoDB anstatt der XtraDB Engine.
Größer sind die Unterschiede beim Optimizer. Da quasi das gesamte ehemalige MySQL Optimizer-Team bei MariaDB ist, wird hier viel Eigenes entwickelt. Auch die Implementierung der GTID (Globale Transakions IDs) ist in MariaDB eine gänzlich andere als bei MySQL, wie auch MariaDB schon die Replikation von verschiedenen Masters auf einen Slave und (echte) parallele Replikation beherrscht.
Zudem bietet MariaDB GPL-Alternativen für die erwähnten proprietären Erweiterungen (Audit Plugin, Connection Pooling, PAM Authentizierung) von MySQL an. Mit dem von Percona entwickelten xtrabackup steht eine Alternative zum kommerziellen MySQL Enterprise Backup zur Verfügung. Viele wird es freuen, dass MariaDB auch ein Rollenkonzept zur Benutzerverwaltung implementiert. Einer der großen Vorteile von MariaDB ist die Integration von Plugins aus der Community. Der Zugriff auf verschiedene Storage Engines via Plugin scheint immer weniger im Fokus von MySQL zu sein. So bietet MariaDB mit SpiderSE die Möglichkeit, Daten transparent zu sharden, also auf viele Instanzen zu verteilen. Damit ist es möglich zu joinen, ohne die Applikation über verschiedene Shards anzupassen. ConnectSE bietet den Zugriff auf verschiedene Datenquellen, seien es lokale Datenfiles wie z.B. von Access, auf weitere MySQL Installationen oder auf eine ODBC Gegenseite (gerne auch eine Oracle).
TokuDB ermöglicht hohe Insert-Raten bei einem typischen 1:8-Footprint und OQGraph ermöglicht performante Graphen. Bei TokuDB muss negativ erwähnt werden, dass es sich hier um ein OpenCore-Plugin handelt. Das gerade wichtige binäre Online-Backup ist ein properitäres Add-On.
Ein besonderer Leckerbissen ist Galera. Es ermöglicht synchrone Multi-Master Replikation für MySQL/MariaDB, wird mit MariaDB ausgeliefert und gilt als der HA-Baustein für MySQL/MariaDB-Installationen. Diese Erweiterungen sind nicht in MySQL zu finden und/oder von Oracle supportet.
Fazit
Es gibt einige gute Gründe, ein Auge auf MariaDB zu werfen. Auch MySQL ist technisch weiterhin interessant und treibt die Entwicklung weiterhin voran.
Zu Unrecht nicht erwähnt wurde Percona. Percona ist auch ein Fork der GPL-Version MySQL. Der grundlegende Unterschied liegt darin, dass Percona nahe am MySQL bleibt. Es verantwortet vor allem den InnoDB Fork XtraDB und mit xtrabackp die binäre online Backupmöglichkeit. Zudem hat Percona Versionen mit Galera und TokuDB. Abgesehen davon stellt Percona einen reinen GPL-Ersatz bezüglich der Funktionalität von MySQL Enterprise dar.
Der Autor will noch auf eine Irritation hinweisen, die der Welt der Trademarks geschuldet ist. Mit MariaDB war immer der MariaDB Server der MariaDB Foundation gemeint. Während der Artikel verfasst wird, hat sich SkySQL in MariaDB Corporation umbenannt und hält auch das Trademark MariaDB, welches von der Foundation verwendet werden darf. Damit firmiert MariaDB Corporation als erste Adresse für MariaDB. So ist festzustellen, dass auch andere Firmen für MariaDB Server-Support anbieten und dazu keine Vereinbarung mit MariaDB Corporation brauchen - auch wenn die ganz gut sind. Dem Autor missfällt die Übertragung des MariaDB-Trademarks an SkySQL, hat dies doch ein unschönes Geschmäckle.
