Ein Migrationsleitfaden für Drizzle

Inhaltsverzeichnis

Drizzle ist ein abgespeckter Fork der Datenbank MySQL, der das ursprüngliche MySQL-Konzept einer leichtgewichtigen Datenbank für Webanwendungen und Cloud-Umgebungen umsetzen will. Durch den Verzicht auf Funktionen wie Stored Procedures, Triggern und Views soll Drizzle nach den Wünschen den Entwicklerteams um dem MySQL-Entwickler Brian Aker zu den Wurzeln von MySQL zurückkehren – eine schnelle, schlanke, auf Leseanfragen optimierte Datenbank.

Vorteile von Drizzle

Warum sollte man eine Migration zu Drizzle überhaupt in Erwägung ziehen? Der MySQL-Ableger wartet mit einigen interessanten Features auf. So wird Datenintegrität bei Drizzle groß geschrieben: Die Datenbank verlangt vom Anwender Eindeutigkeit. Wenn die Datenbank eine bestimmte Abfrage oder bestimmte Daten nicht versteht, gibt sie eine Fehlermeldung zurück.

Den Datentyp TIMESTAMP unterstützt Drizzle mit Mikrosekunden-Präzision (Drizzle nutzt dazu TIMESTAMP(6)) sowie verwandte Funktionen wie NOW(). Zudem gibt es mit UUID und nativem BOOLEAN einige neue Datentypen.

Den Quellcode der Datenbank haben die Drizzle-Entwickler gründlich überarbeitet und getestet. Dabei beseitigten sie viele Fehler, die noch aus MySQL-Zeiten stammten. Auch sind einige Locks verschwunden, die bei vielen gleichzeitigen Verbindungen die Performance ausbremsen konnten. Neue Code-Zweige werden rigoros auf Stabilität getestet, bevor sie aufgenommen werden. Dazu gehören diverse Leistungs- und Regressionstests.

Drizzle ist ein Community-Projekt und wird von Unternehmen entwickelt, die die Software selbst nutzen, nicht von Firmen, für die die Software Grundlage der eigenen Produkte oder Dienstleistungen ist. Alle Quellen lieegn vollständig offen. Das gilt auch für die Entwicklung und das Testen aller Commits, die eingereicht werden. Die Client-Bibliothek libdrizzle ist kompatibel zu MySQL und steht unter der BSD-Lizenz. Dadurch lässt sich die Library nicht nur in andere Open-Source-Projekte, sondern auch in kommerzielle Software integrieren. Für die Dokumentation setzt das Projekt auf die Creative-Commons-Lizenz "Share Alike 3.0", sodass auch diese leicht weitergegeben werden kann.

Für die Zukunft planen die Drizzle-Entwickler die Erweiterung von libdrizzle um native Sharding und Multi-Tenant-Fähigkeiten – die Grundlage dafür ist bereits geschaffen. Bei der Multi-Tenant-Fähigkeit geht es – vereinfachend gesagt – darum, dass mehrere unabhängige Drizzle-Instanzen hinter einem Daemon laufen. Die Funktion ist vor allem interessant, wenn man die Datenbanken für virtuelles Hosting und für Database-as-a-Service einsetzen wollen, da es damit viel leichter wird, mehrere Installationen der Datenbank auf einem Server für verschiedene Kunden bereitzuhalten.

Einen kleinen Preis bezahlt man jedoch für die grundlegende Überarbeitung und die neuen Features, mit denen Drizzle aufwartet: Der Fork ist dadurch nicht länger vollständig kompatibel zu MySQL. Vieles ist zwar gleich geblieben, aber es gibt eine Reihe von Unterschieden.

Protokoll

Drizzle versteht das MySQL-Protokoll, sodass in PHP, Python, Perl oder anderen Sprachen geschriebene Plug-ins in den meisten Fällen problemlos mit Drizzle funktionieren werden. Man sollte jedoch beachten, dass die Pakete von Debian/Ubuntu und RedHat/Fedora die üblichen Port- und Socket-Listener für MySQL standardmäßig nicht einrichten. Anwendungen müssen sich eventuell mit Port 4427 auf 127.0.0.1 verbinden statt mit "localhost", das versucht, den Socket zu benutzen. In Zukunft soll Port 4427 für neue Protokoll-Features (wie das bereits genannte Sharding) benutzt werden. Port 3306 und der Unix-Socket sollen jedoch vollständig kompatibel zu MySQL bleiben.

Hiermit in Zusammenhang steht, dass MySQL über eine eigene, native Authentifizierung verfügt und zudem in Version 5.5 eine Plug-in-API für Authentifizierung eingeführt hat. In Drizzle gibt es in der Standardeinstellung keine Authentifizierung. Mit Hilfe diverser Plug-ins lässt sich diese implementieren. Dafür stehen zum Beispiel PAM, Textdateien und einige andere Methoden zur Verfügung.

Was nicht geht

Die Grundidee hinter Drizzle ist ein "zurück zu den alten MySQL-Tugenden" – die Datenbank soll schnell, leichtgewichtig und auf die Bedürfnisse von Webanwendungen und der Coud optimiert sein und nicht mit großen Unternehmensdatenbanken konkurrieren. So unterstützt Drizzle Stored Procedures derzeit nicht – in der Startphase von Drizzle wurde entschieden, dass sich diese Logik in der Anwendungsschicht befinden sollte, vor allem in Cloud-Umgebungen, wo Ressourcen kostbar sind. Auf vielfachen Wunsch soll das nächste GA-Release aber ein Stored-Procedure-Interface enthalten. Zu diesem Zweck existiert bereits ein Projekt im Rahmen von Googles Summer of Code (GSoC). Views und Trigger sind zwar schon implementiert, aber nur für mutige Anwender nutzbar.

Kurz vor dem GA-Release haben die Entwickler die Anzahl der mitgelieferten Datenbank-Engines reduziert – manche wurden entfernt, weil ihre Entwicklung schon länger stagniert, andere, weil sie nicht mehr richtig funktionierten. MyISAM wird nur noch für temporäre Tabellen unterstützt. Tatsächlich ist es so, dass Drizzle für Haupttabellen keine nichttransaktionalen Speicher-Engines unterstützt. Solche Tabellen müssen also nach InnoDB konvertiert werden. In der Konsequenz werden auch Volltextindizes nicht unterstützt. Aktuell stehen für herkömmliche Tabellen neben InnoDB noch HailDB und PBMS zur Verfügung. Als temporäre Engines bietet Drizzle neben MyISAM auch Memory an.

Drizzle unterstützt fast alle von MySQL bekannten Datentypen. Einschränkungen gibt es aufgrund der bereits erwähnten Genauigkeit und auch durch die Bestrebungen von Drizzle, den SQL-Standard besser einzuhalten – dazu später mehr. Der einzige MySQL-Datentyp, den Drizzle aktuell nicht unterstützt, ist SET, aber auch hierfür gibt es in diesem Jahr ein GSoC-Projekt. Es soll zusätzlich einen neuen Datentyp TUPLE implementieren.

Zeichensätze

MySQL kann mit verschiedenen Zeichensätzen umgehen, woraus sich für Unternehmen vielfältige Nutzungsmöglichkeiten ergeben. Im Internet jedoch regiert UTF-8. Aus diesem Grund kennt Drizzle lediglich zwei Zeichensätze: UTF-8 und binär. Für viele Websites dürfte diese Vereinfachung von Vorteil sein. Bei einer Migration kann es jedoch eine Stolperfalle geben, auf den später noch eingegangen wird.

Datentypen

MySQL kennt eine Reihe von Integer-Datentypen, darunter TINYINT, SMALLINT, MEDIUMINT, INT und BIGINT. Drizzle reduziert sie auf überschaubare zwei Ganzzahltypen: INT (4 Bytes) und BIGINT (8 Bytes). Für diese Veränderung gab es mehrere Gründe – in erster Linie der Umstand, dass die verschiedenen Typen nicht Bestandteil der SQL-Spezifikation sind. Reicht bei einer Datenbankanwendung der ursprünglich festgelegte Zahlenbereich nicht mehr aus, ist für die Umwandlung in einen anderen Typ ein ALTER TABLE-Befehl notwendig, der bei großen Datenmengen sehr viel Zeit in Anspruch nehmen kann. Der wohl wichtigste Grund, die Anzahl der Datentypen zu reduzieren, liegt allerdings darin, dass bei den meisten Speicher-Engines (auch InnoDB) auch die kleinen Datentypen in vier Byte gespeichert werden – sie bringen also keinen Speichervorteil.

Auch für die Typen TEXT und BLOB kennt MySQL mehrere Größengaben (TINY, MEDIUM, LONG), was in den allermeisten Fällen jedoch höchstens einige Bytes im Row-Header eines Datentyps spart, der aber Daten im Kilobyte- oder Megabyte-Bereich speichert. In Drizzle gibt es daher nur einen BLOB/TEXT-Typ.

In MySQL unterstützt ENUM nicht nur die in der Liste gespeicherten Werte, sondern auch leere Werte. Auch ein unbekannter Wert wird, zumindest bei abgeschaltetem Strict-Modus, als leerer Wert dargestellt. Drizzle akzeptiert beim Typ ENUM keine leeren Werte.

Auf die neue Implementierung der Datentypen TIME und DATE haben die Drizzle-Entwickler viel Zeit und Aufmerksamkeit verwendet. Bei einer Migration sollte man die folgenden drei Aspekte im Auge behalten:

• In Drizzle reicht die Zeitspanne von 00:00:00 bis 23:59:59; MySQL bietet hier mehr Möglichkeiten. Wer Werte benötigt, die außerhalb dieses Bereichs liegen, sollte also lieber INT verwenden.
• Bei den Typen DATE/DATETIME/TIMESTAMP ist ein Wert von 0000-00-00 unzulässig; das erste gültige Datum ist 0001-01-01. In den meisten Fällen kann "0000-00-00" durch NULL ersetzt werden.
• Drizzle kennt nur eine Zeitzone: UTC.

Für das Speichern von Zeiten im Mikrosekunden-Bereich bietet sich der Datentyp TIMESTAMP(6) an.