MariaDB vs. MySQL – Nutzbarkeit statt Feature-War

Die Gründe dafür, dass immer mehr Anwender statt MySQL lieber MariaDB verwenden haben nur am Rande mit Features zu tun. Im Kern geht es um zwei Dinge: Welches Datenbanksystem ist wirklich Open Source? Und welches unterstützt die wichtigsten Anwendungsszenarien am zuverlässigsten?

In der allgemeinen Wahrnehmung ist MariaDB oft ein Ableger von MySQL. Doch ist es streng genommen nicht mehr korrekt, MariaDB als reinen MySQL-Fork zu betrachten. Zwar gründen beide Datenbank-Management-Systeme (DBMS) auf derselben Code-Basis und sind in vielen Bereichen nach wie vor kompatibel. Doch sie bewegen sich deutlich in unterschiedliche Richtungen. Sowohl was die Produktphilosophie angeht, als auch in der Umsetzung des Open-Source-Gedankens.

Benchmark ist kein Workload

Die MariaDB-Entwickler waren nicht untätig und haben sehr viele Ideen in die Datenbank-Lösung eingebracht. Das betrifft weniger den so genannten “War of Features”, bei dem sich Hersteller ständig gegenseitig mit neuen Funktionen übertrumpfen wollen, sondern in erster Linie den stabilen, zuverlässigen Einsatz des DBMS im Unternehmen.

Durchforstet man das Internet nach Vergleichen zwischen MariaDB und MySQL, stößt man schnell auf lange Feature-Listen und aufwändige Benchmarks. Das ist interessant zu lesen und oft genug schmeichelhaft für MariaDB. Doch Benchmarks sind nicht der echte Workload.

Im produktiven Unternehmenseinsatz stehen zunächst ganz andere Anforderungen im Vordergrund als Millisekunden. Ein DBMS im Unternehmen muss stabil arbeiten, ein hohes Maß an Sicherheit ermöglichen, flexibel neue Workloads ermöglichen und möglichst einfach in bestehende oder zukünftige Umgebungen zu integrieren sein.

Denn Datenbanken sind die Basis der IT – und damit der meisten Geschäftsprozesse. Und genau hier finden sich die zentralen Unterschiede zwischen MariaDB und MySQL.

Flexibilität und Sicherheit

Bei der Entwicklung von MariaDB stehen die Aspekte Flexibilität, Sicherheit und Skalierbarkeit im Mittelpunkt. Der Ansatz ist, das DBMS für möglichst viele Anwendungsfälle zu öffnen und zu optimieren. So verfügt MariaDB über eine breite und ständig wachsende Palette an Speicher-Engines und übertrifft in diesem Bereich MySQL bei Weitem.

Diese sind jeweils für bestimmte Einsatzszenarien konzipiert – zum Beispiel InnoDB für Transaktionen, Spider mit integrierten Sharding-Funktionen oder ColumnStore für massive parallele Architekturen und mit einem spaltenbasierenden Modell. Das Ziel ist es, die modulare Architektur – die MySQL und MariaDB teilen – so auszunutzen, dass es für jedes Einsatzszenario eine optimale Speicher-Engine gibt.

Fortlaufend steuert die Community neue Engines bei, die neue Nutzungsprofile erlauben. Dabei sind auch Generalisten wie die Connect-Engine, über die so gut wie jedes andere Datenbanksystem mit MariaDB kommunizieren kann.

Neben der Flexibilität spielt die Sicherheit der “Data at rest”, der gespeicherten Daten, eine zentrale Rolle im Unternehmenseinsatz. Mit Version 10.1 hat MariaDB deswegen die Möglichkeit zur Verschlüsselung von Daten auf Storage-Ebene eingeführt. Dabei können ganze Table-Spaces, aber auch nur einzelne Tabellen sowie verschiedenste Log-Dateien verschlüsselt werden.

Sehr wichtig hier: Die Daten sind nicht nur in den Dateien der Speicher-Engine geschützt, sondern auch in den für die Replikation wichtigen Binär-Logs. Für eine leichter zu verwaltende Zugriffskontrolle kommt Role-based Access Control zum Einsatz.

Dieses Vorgehen ist zwar nicht prinzipiell neu, jedoch als native Implementierung bei Datenbank-Management-Systemen bislang leider selten zu finden. Im Kern geht es darum, dass Zugriffsrechte nicht nur klassisch auf der Basis einzelner Benutzer und Benutzergruppen vergeben werden, sondern auch anhand einmal definierter Rollen, die ein Mitarbeiter im Unternehmen ausfüllt: Für jede Rolle wird einmalig definiert, was ein Mitarbeiter dieser Rolle mit den Daten und dem System machen darf.

Skalierbarkeit und Verfügbarkeit

Eine hohe Verfügbarkeit und die Möglichkeit, Anwendungen und die zugrundeliegenden Datenbanken schnell zu skalieren, sind für digitale Geschäftsmodelle und Unternehmensabläufe unverzichtbar. MariaDB setzt hierfür wie die meisten Infrastrukturkomponenten auf Clustering in Form des funktional sehr umfangreichen Galera-Clusters des finnischen Anbieters Codership.

Ergänzt wird diese Technologie um MariaDB MaxScale: MaxScale ist im Kern ein Datenbank-Router, der zum Load-Balancing von Galera-Clustern, Master-Slave-Replikationen und als Replikations-Relay eingesetzt wird. MaxScale wurde von der MySQL-Community zur “Application of the Year 2016” gewählt.

MaxScale ist für die Anwendung unsichtbar, der Router stellt aus Sicht der Anwendung eine normale Datenbankinstanz dar. Gegenüber dem Datenbank-Cluster wiederum bildet MaxScale eine übergeordnete Schicht, die die Kommunikation zwischen Anwendung und Datenbanken steuert. Der besondere Charme dieser Lösung: Änderungen an den Datenbank-Clustern wirken sich nicht auf die Anwendungsschicht aus, sie haben also keine Anpassungen auf Anwendungsseite zur Folge.

Auch kann die Datenbank so unabhängig von der Anwendungsschicht skalieren. Ebenso schlagen Änderungen bei der Anwendung ihrerseits nicht zwingend auf die Datenbanken im Hintergrund zurück.

Alle diese Entwicklungsschritte hätte MariaDB jedoch niemals alleine bewältigen können. Viele Unternehmen und Entwickler tragen dazu bei, neue Funktionen, Speicher-Engines und Einsatzszenarien zu ermöglichen. Ein wichtiger Grund für diese sehr aktive Community ist, dass MariaDB auch in Zukunft Open Source ist und die Entwicklungsarbeit transparent bleibt.

Die Rechte am Code liegen bei der Non-Profit-Organisation MariaDB Foundation, nicht bei der MariaDB Corporation. So ist auch sichergestellt, dass die Open-Source-Edition den gleichen Funktionsumfang besitzt wie die kostenpflichtige Subskription.