Das Bild von MySQL hat sich in den vergangenen Jahren gewandelt. Lange Zeit wurde die Datenbank in Universitäten und Kleinstunternehmen gesehen, weit entfernt von den täglichen Anforderungen einer "richtigen Firma". Ein oft gehörter Einwand war, dass sie zum Beispiel keine echten Transaktionen unterstütze, was jedoch eine essenzielle Eigenschaft für die kommerzielle Datenverarbeitung ist. Dieses Feature ist zusammen mit Row Level Locking schon seit der Version 3.23 in der InnoDB Storage Engine von MySQL implementiert. Inzwischen reden wir bei MySQL 5 von neuen Features wie Stored Routines, Trigger und Views. Deshalb liegt es nahe, einmal näher zu beleuchten, in welchen Situationen MySQL eine interessante Alternative zu kommerziellen Datenbanken wie Oracle, IBM DB2 oder Microsoft SQL Server sein kann und wo derzeit noch die Grenzen liegen.

MySQL - technische Übersicht

Eine der wichtigsten Unterschiede von MySQL zu kommerziellen Datenbank-Systemen ist die Möglichkeit, verschiedene Storage Engines zu benutzen. Diese Storage Engines beeinflussen nicht nur die rein physische Speicherung der Tabellen, sondern können auch eine große Wirkung auf Eigenschaften wie Backup, Locking und Transaktions-Handling haben. Je nach Typ der Applikation kann man bestimmen, wie die Daten für eine bestimmte Tabelle physisch abgelegt werden. Hier können Fragen berücksichtigt werden wie:

- Braucht die Tabelle einen Transaktions-Support?

- Handelt es sich im Wesentlichen um eine Read-Only-Tabelle?

- Werden die Daten einer Tabelle parallel von vielen Benutzern aktualisiert?

- Werden Daten periodisch mit Batch-Jobs geladen?

Je nach Antwort kann eine adäquate Storage Engine ausgewählt und so der Ressourcenverbrauch möglichst klein gehalten werden. Wird eine Tabelle zum Beispiel kaum modifiziert oder werden deren Daten nur periodisch von einer Ladeprozedur aktualisiert, dann ist die MyISAM Storage Engine die perfekte Wahl. Sind parallele Updates zu erwarten oder ist Transaktions-Support notwendig, dann sollte in der Regel InnoDB genutzt werden.

Weitere Engines sind "Memory" (für volatile Daten, die einfach wiederhergestellt werden können), "Merge" (für partitionierte Tabellen, aber deutlich weniger leistungsfähig als zum Beispiel "Oracle Partitionen"), "BDB" (Berkley Database), "NDB Cluster" (für MySQL-Cluster) und "Federated" (für den Remote-Database-Access, ähnlich einem "Oracle Database Link", aber für nur eine Tabelle).

Prozess- und Speicherstrukturen

MySQL-Komponenten sind in Threads organisiert, ganz im Gegensatz etwa zu Oracle RDBMS auf Unix, welches für jede Datenbankkomponente einen eigenen Prozess nutzt (Database Writer, Process Monitor etc.). Mit der Thread-Technologie sind sehr effiziente Kontextwechsel zwischen den einzelnen Datenbankaktivitäten möglich, natürlich mit der potenziellen Gefahr einer gegenseitigen negativen Beeinflussung.

Eine der interessantesten Speicherstrukturen von MySQL ist der Query Cache. Er ist nützlich bei Abfragen, die viele I/Os erfordern. Um den Unterschied zu kommerziellen Datenbanken zu veranschaulichen, nehme man bei Oracle zum Beispiel die Vertriebstabelle aus der Demo-Version und ermittle dort die Summe über die Spalte "AMOUNT_SOLD". Das erste Mal warten Sie, weil das Select einen "Full Table Scan" praktisch komplett von der Platte durchführt. Die Blöcke werden in den Buffer Cache geladen und das Ergebnis ermittelt. Erfolgt die Abfrage nun zeitnah ein zweites Mal, wird ein Grossteil der Blöcke aus diesem Cache gelesen und nur wenig bis gar nichts von der Disk. So wartete man auf unserem Testsystem beim ersten Mal eine Minute, beim zweiten Mal zwölf Sekunden. "Sehr gut" werden Datenbankkenner sagen, "das macht eben ein gutes Datenbanksystem aus!" Andererseits könnte man sich auch fragen: "Warum zwölf Sekunden warten, wenn sich an der Tabelle doch gar nichts geändert hat?"

Genau hier spielt der Query Cache von MySQL seine Vorteile aus. Wenn zwei Benutzer exakt die gleiche Abfrage starten und sich auf den zugrunde liegenden Tabellen seit der letzten Query nichts geändert hat, dann wird MySQL das Resultat ohne Lesen der Tabelle von Disk oder Daten-Cache liefern. Im beschriebenen Fall dauerte es 0,01 Sekunden, den Query Cache abzufragen!

MySQL verfügt über eine Cluster-Technik und Replikationsfunktionen, die auf dem SQL-Befehl Replication aus den so genannten Binary Logs basieren. Die Clustering-Option ist komplett anders als zum Beispiel bei Oracle: Oracles Real Application Cluster folgt einem Shared-Disk-Ansatz, MySQLs Cluster-Option ist eine Shared-Nothing-Lösung.

Einer der Vorteile des MySQL-Clusters ist, dass kein spezieller Cluster-Manager eingesetzt werden muss und er mit Standard-Hardware auskommt. Oracle ist mit der Version 10g immerhin so weit fortgeschritten, dass der Cluster-Manager mit der Datenbank-Software ausgeliefert wird, man also nicht mehr auf einen Dritthersteller angewiesen ist. Es ist allerdings immer noch der gleichzeitige Anschluss von speziellen Disk-Systemen an mehrere Knoten erforderlich, was einen nicht zu vernachlässigenden Einfluss auf Kosten und Administrationsaufwand hat.

Der Oracle-Technik unterlegen

Oracles Cluster-Technologie ist heute sicher eines der Hauptverkaufsargumente für die Datenbank - verstärkt wird dies noch durch den Umstand, dass sie ab Oracle 10g in der Standard Edition kostenfrei mitgeliefert wird. Eingeführt wurde sie mit dem Release 9i im Jahr 2001, weshalb sie inzwischen als sehr ausgereift bezeichnet werden kann. In dieser Hinsicht und bezüglich ihres Funktionsumfangs ist sie dem MySQL-Cluster überlegen - allerdings zum Preis der deutlich höheren Komplexität.

Beim MySQL-Cluster ist nur die NDB Storage Engine Cluster-fähig. Dazu muss man wissen, dass MySQL im Prinzip aus zwei Teilen besteht: Aus dem MySQL-Server, der zum Beispiel Abfragen abarbeitet und den Cache verwaltet, und aus der Storage Engine, über die die Ablage der Daten erfolgt und die je nach gewählter Engine bestimmt, wie die Daten physisch gespeichert werden. Bei anderen Datenbanken sind diese Systemkomponenten nicht getrennt.

Server nicht "Cluster-aware"

Im Gegensatz zu kommerziellen Datenbank-Servern wissen die auf mehreren Knoten installierten MySQL-Server also nicht, dass sie in einem Cluster arbeiten, sie sind nicht "Cluster-aware". Sie übergeben die Datenblöcke der Engine, in diesem Fall der Cluster-fähigen NDB Storage Engine, die nun so konfiguriert werden kann, dass sie die Tabellen in mehreren Repliken auf verschiedenen Knoten ablegt, um die Verfügbarkeit zu erhöhen. Gleichzeitig werden die Daten partitioniert, um den parallelen Zugriff darauf zu verbessern.

Neue Features der Version 5.0

Die neuen Features aus MySQL 5 werden die Akzeptanz dieser Datenbank weiter vorantreiben und sie in Bereiche vordringen lassen, wo Techniken wie Views, Stored Routines (Funktionen und Prozeduren) sowie Trigger gefordert sind. Die angebotenen Features sind zwar noch weit von Oracle entfernt, und ein versierter Oracle-PL/SQL-Programmierer wird viele Dinge bei den MySQL-Stored-Routines vermissen. Doch bedenkt man, dass früher komplexere Anwendungen (Schleifen, Ablaufstrukturen etc.) für MySQL zum Beispiel in Perl geschrieben wurden und die Skripte nicht in der Datenbank, sondern in einem externen Skript-Interpreter oder auf einem Web-Server abliefen, so hat sich mittlerweile einiges getan. Mit MySQL 5 braucht ein Datenbankadministrator oder PHP-orientierter Entwickler bei datennahen Operationen etwa für Loops oder If-Bedingungen nicht mehr auf eine externe Skriptsprache beziehungsweise Ablaufumgebung zurückgreifen.

Das neue Schema "information_schema" zeigt auch, dass MySQL auf dem richtigen Weg zum SQL-2003-Standard ist, der ein Metadaten-Verzeichnis verlangt. Bei Oracle ist dies das Data Dictionary beziehungsweise das SYS Schema. Dennoch existieren auch hier noch einige Fallstricke bei MySQL, so etwa im Security-Bereich: Wird eine Tabelle gelöscht, werden die Privilegien darauf nicht entfernt. Erzeugt derselbe Benutzer nun eine neue Tabelle mit demselben Namen, können die bislang für die alte Tabelle autorisierten User auf die neue Tabelle mit ihren bisherigen Rechten zugreifen.

Stabile Tools

Die MySQL-Tools sind in den letzten Release-Zyklen sehr stabil geworden und bieten einen großen Funktionsumfang. Der Query Browser und der MySQL-Administrator erlauben es, eine MySQL-Datenbank ohne das Kommandozeilen-Tool "mysql" zu verwalten. Funktional entspricht das der Oracle OEM Console in Java. Interessanterweise verfolgen Oracle und MySQL völlig unterschiedliche Strategien bei der Entwicklung von Administrations-Tools: Während sich MySQL entschieden hat, mit der grafischen Bibliothek des unterstützten Betriebssystems zu entwickeln (also kein Java), setzt Oracle seit der Version 10g auf einen Application Server mit Java Server Pages und einem Webbrowser als Client.

Migration von Access

Wie zu erwarten, gibt es ebenfall ein Migrations-Tool von Access oder Oracle nach MySQL. Aktuell in einer grafischen Version nur für Windows verfügbar, existiert es außerdem in einer textbasierenden Variante auch für Linux und Mac OS X. Es erlaubt die Migration der genannten Datenbanken im Rahmen der Möglichkeiten von MySQL, obschon es noch die eine oder andere Kante beim Datentransfer zu glätten gilt.

Der eigentlich Beweis aber, dass MySQL den Sprung auch Tool-seitig in die Enterprise-Liga geschafft hat, ist die Unterstützung der Datenbank durch namhafte Hersteller wie Quest, dessen im Oracle-Umfeld verbreitete Entwicklungs- und Administrationsumgebung "Toad" inzwischen auch für MySQL erhältlich ist - ein Umstand, der die Entscheidung für die Datenbank sicher erleichtert.

Für MySQL gibt es zum Teil direkten Support seitens der Hersteller von Backup-Medien, so umfassend wie für Oracle ist er allerdings nicht. Auch die eigentlichen Backup- und Recovery-Möglichkeiten von MySQL sind weit von Oracle entfernt. Ein Tool wie den Recovery Manager (RMAN) gibt es nicht, ebenso wenig das Feature, einzelne Blöcke zu reparieren oder das umfangreiche Point-in-Time-Recovery von Oracle. Ganz zu schweigen von den Möglichkeiten der Flashback Database, die Oracle ab 10g Release 1 eingeführt hat. Selbstverständlich lassen sich mit MySQL je nach Storage Engine Online-Backups vornehmen, aber Oracle spielt hier in einer anderen Liga.

Konsole verbesserungswürdig

Auch in Bezug auf die grundlegende Systemadminsitration muss MySQL noch etwas aufholen. Oracle hat schon früh die Notwendigkeit einer Verzeichnis- und Dateistruktur zur Unterstützung großer Datenbank-Server mit unterschiedlichen Software-Releases und mehreren Datenbanken erkannt. Die dazu notwendigen Konzepte wurden in der Optimal Flexible Architecture (OFA) festgeschrieben. Da die Verzeichnis- und File-Struktur mit den Oracle-eigenen Bordmitteln nicht immer leicht zu bedienen ist, haben Systemhäuser wie Trivadis eine Arbeitsumgebung dafür geschaffen. Bei MySQL vermisst man beides: Sowohl die Definition der Verzeichnisstruktur als auch die entsprechende Arbeitsumgebung - beides wurde von Trivadis aus der Oracle-Welt in die MySQL-Umgebung portiert. So lässt sich heute sagen, dass große MySQL-Server genauso sicher und komfortabel administriert werden können wie dies bei Oracle der Fall ist.

Damit ergibt sich die Gretchenfrage, wann man MySQL als Alternative zu einer der großen kommerziellen Datenbanken in Betracht ziehen kann. Die Erfahrung lehrt, dass für diese Entscheidung eine noch genauere Analyse der Anforderungen seitens der Applikationen und Geschäftsvorfälle erfolgen muss, als dies ohnehin schon bei normalen Projekten der Fall ist. Eine Frage lautet zum Beispiel, ob sich der Aufwand für ein weiteres Datenbanksystem im Vergleich zu den gesparten Lizenzkosten überhaupt lohnt.

Die für Entscheidungsmetriken zu sammelnden Kriterien umfassen das Datenvolumen, die Anzahl parallel arbeitender Benutzer und nicht zuletzt die Art der Applikation und damit die Art der Datenbankanfragen (schreibend, lesend, Verhältnis von schreibenden zu lesenden Anfragen etc.). Handelt es sich um ein Hochverfügbarkeitsprojekt, sind weitere Aspekte wie akzeptierte Ausfallzeiten und Mean Time to Recover von Bedeutung.

Wichtig ist, dass nicht verglichen wird, ob MySQL gleich gut oder besser als der kommerzielle Konkurrent ist, was oftmals ohnehin nicht der Fall sein dürfte, sondern ob MySQL gut genug für die gestellten Anforderungen ist!

Die erste Art von Applikationen, für die man MySQL in Betracht ziehen muss, sind Web-basierende Anwendungen wie Web-Shops. Einerseits wurde die Eignung von MySQL dafür im Rahmen vieler Lamp-Projekte (Linux, Apache, MySQL, PHP/Perl) bewiesen, andererseits schlagen bei kommerziellen Datenbanken wie Oracle der Web-Einsatz mit CPU-gestützten Lizenzmodellen besonders stark zu Buche. Zudem kann MySQL gerade im leseintensiven Web-Umfeld mit Features wie dem Query Cache punkten, und durch die sorgfältige Auswahl der Storage Engines lassen sich Ressourcen sparen:

Einsatz im Web-Shop

So kann man die Verkaufsdaten (schreibender Zugriff) in einer InnoDB-Tabelle ablegen, während die Produktinformationen in einer MyISAM-Tabelle besonders performant lesbar sind. Denn hier müssen keine lesekonsistenten Versionen der Datenblöcke erstellt, keine Transaktions-IDs generiert und keine aufwändigen Locking-Mechanismen abgearbeitet werden.

Aber man kann nicht nur bei überwiegend lesenden Anwendungen mit der MyISAM-Engine punkten. Für gewisse Arten von Transaktionen sind die hochgradig parallelisierbaren Konzepte von Systemen wie Oracle gar nicht notwendig. So zum Beispiel bei der Konsolidierung von Verbindungsdaten in einer zentralen Log-Datenbank (Wer hat sich wo und wie lange eingeloggt?). Rollbacks sind hier nicht notwendig, und der Schreibvorgang beschränkt sich auf das Anhängen eines einzigen, relativ kleinen Datensatzes an eine bestehende Tabelle. Zudem ist nicht mit Tausenden von Einträgen pro Sekunde zu rechnen. MySQL mit MyISAM ist hier die perfekte, effiziente und kostengünstige Lösung.

Interessante "Nebenrolle"

Im Bereich Backup/Recovery wurden die Schwächen von MySQL schon aufgezeigt. Wenn aber die MySQL-Datenbank im Crash-Fall aus einem Legacy-System schnell wieder neu aufgebaut werden kann, sind diese Features gar nicht gefragt. Ein Beispiel dafür: Auf einer Oracle-Datenbank läuft eine transaktionsorientierte Anwendung wie Kontobuchungen, deren Daten einmal pro Nacht in eine MySQL-Datenbank geladen werden, um daraus Reports zu generieren. Sollte MySQL nun abstürzen, wird die Datenbank einfach wieder aus dem Quellsystem neu aufgebaut - die umfangreichen Backup/Recovery-Funktionen wie sie Oracle bietet, sind nicht erforderlich. Unterm Strich lässt sich also sagen, dass für Datenbanken, die nicht "Master" der Daten sind und deshalb auch kein ausgefeiltes Backup/Recovery benötigen, Systeme wie MySQL in Betracht gezogen werden können.

Ähnlich verhält es sich mit der bislang eher am Anfang stehenden Implementierung der Stored Routines von MySQL: Solange ein Großteil der Applikations-Logik im Web- oder Applikations-Server mit PHP abläuft, braucht man keine komplexen Abfragesprachen wie PL/SQL von Oracle.

Performance-Probleme

Andererseits gibt es Situationen, in denen der Einsatz von MySQL sehr genau getestet und verifiziert werden muss. So zum Beispiel, wenn bei großen Datenmengen ein effizienter Transaktions-Support garantiert sein muss. Bei InnoDB ist es im Prinzip ähnlich wie bei Oracle möglich, mehrere Tabellen in einer Datei zu halten. Aktuell leidet das InnoDB-Space-Management jedoch an Performance-Problemen bei der Freigabe von Speicherplatz innerhalb eines Tablespaces. Ebenso ist das File-Management (hinzufügen und entfernen von Daten-Files) weit von den Möglichkeiten zum Beispiel eines Oracle-Systems entfernt. Innobase - die Firma, die die InnoDB Storage Engine entwickelt und pflegt - empfiehlt daher, pro Datei nur eine Tabelle einzurichten: Ein Konzept, wie es von der MyISAM Storage Engine bekannt ist.

Schließlich noch etwas zum Thema Cluster: Aktuell ist die NDB Storage Engine eine In-Memory Storage Engine, welche Transaktions-Support anbietet. Das Acid-Prinzip (Atomicity, Concurrency, Isolation, Duration) der Transaktionsverwaltung wird durch Datenänderungen auf mindestens zwei Knoten implementiert, um so vor Knoten-Crashes geschützt zu sein. Es gibt zwar einen Checkpoint-Prozess, doch der arbeitet asynchron zu den Transaktionen. Es ist klar, dass niemand seine Gehaltskontodaten auf diese Weise gesichert haben möchte: In vielen Fällen reicht die die Replikation von Änderungen auf viele Knoten allein nicht aus. Verbesserungen wird hier erst eine der folgenden Versionen von MySQL bringen. (ue)

*Yann Neuhaus ist Senior Consultant, Dr. Martin Wunderli ist Principal Consultant bei der Trivadis AG in Basel und Zürich.