Home ORDIX AG             Dienstleistung             Trainingsshop    Kunden / Referenzen Aktuelles    Kontakt
Home  Pfeil  ORDIX News  Pfeil  1/2006
suche: 
Der Artikel richtet sich an Datenbankadministratoren und Entwickler, die bereits mit älteren Versionen von MySQL vertraut sind und einen Umstieg planen oder auf wichtige Features warten.

Weiterführende Links

MySQL 5 New Features

MySQL 5 − The Next Generation

Seit Oktober 2005 ist die neue MySQL Version 5 für den produktiven Einsatz freigegeben. Der schwedische Datenbankhersteller MySQL AB feiert den neuen Sprössling als "The most important release ever ... ". Als Ziel wurde klar der Einsatz in geschäftskritischen Bereichen definiert − einem Bereich, in dem sich vor allem die bekannten, kommerziellen Anbieter etabliert haben. Ob mit dieser Version wirklich der ganz große Wurf gelungen ist, soll im Folgenden näher untersucht werden.

Ein ernst zu nehmender Gegner?

Bislang fristeten MySQL-Datenbanken in größeren Unternehmen ein Schattendasein. Das Fehlen einiger wichtiger Funktionen (Stored Procedures, Funktionen, Views usw.) machte es schwer, Geschäftslogik in der Datenbank zu hinterlegen.

Mit der neuen Version will MySQL diese Schwächen endlich hinter sich lassen und bemüht sich, den Wechsel auf das eigene Produkt so einfach wie möglich zu gestalten.

Stored Procedures, Trigger, Views und User-Functions

Eine der wichtigsten Neuerungen dürfte wohl die Einführung einiger lange vermisster Datenbankobjekte sein. Mit der neuen Version haben endlich Stored Procedures, Trigger, Views und User Functions Einzug in die Open Source Datenbank gehalten.

Besonders lobenswert ist die Tatsache, dass sich MySQL hierbei an den Standard SQL:2003 hält, der z. B. auch von IBMs DB2 unterstützt wird (siehe Abbildungen 1 und 2). Ebenfalls neu in der Version 5.0 sind updateable Views. Bislang waren nur lesende Zugriffe über Views möglich.

create function zinsen
    (betrag decimal(10,2), zinsen int(3), jahre int(2))
returns decimal(15,2)
return (betrag * power(1+(zinsen/100), jahre))
Abb. 1: Das Beispiel zeigt eine simple Funktion zur Berechnung von Zinseszinsen.

DELIMITER /;
CREATE PROCEDURE build_table()
BEGIN
DECLARE i INTEGER;
DECLARE v INTEGER;
SET i = 1;
SET v = 100;
WHILE i <= 125 DO INSERT into mytable VALUES (i, v); SET i = i + 1; SET v = v + 2; END WHILE; END / DELIMITER ';' /
Abb. 2: Das Beispiel zeigt eine Prozedur,
welche die Tabelle "mytable" mit 125
Datensätzen füllt..

Darf es ein bisschen mehr sein?

MySQL ist von jeher für seine unterschiedlichen Storage Engines bekannt, die je nach den gestellten Anforderungen hinsichtlich Performance oder Sicherheit ihre Stärken ausspielen können. MyISAM, InnoDB, MERGE und HEAP sind für die meisten MySQL-Nutzer längst alte Bekannte. Mit der neuen Version haben sich zwei neue "Datenverwalter" dazu gesellt: Die Archive Storage Engine und die Federated Storage Engine.

Klein aber fein

Die Archive Storage Engine soll große Datenmengen platzsparend verwalten. Gedacht ist sie z. B. für alte Bestandsdaten, die im Zugriff der Anwender bleiben sollen, jedoch nicht mehr verändert werden müssen. Die Daten werden dabei über einen zlib-Algorithmus direkt beim Anlegen (INSERT) komprimiert und platzsparend gespeichert.

Die Storage Engine unterstützt ausschließlich INSERT- und SELECT-Kommandos. Trotz der hohen Kompressionsrate erfolgen die Zugriffe außerordentlich schnell. Im Vergleich zu MyISAM-Tabellen können bis zu 80 Prozent Speicherplatz eingespart werden.

So nah und doch so fern

Die Federated Storage Engine verwaltet lokal keine Daten. Sie bietet dafür die Möglichkeit, Daten aus entfernten Tabellen beziehungsweise Datenbanken einzubinden. Beim Anlegen einer Tabelle wird definiert, auf welcher Instanz die dazugehörigen Daten zu finden sind (siehe Abbildung 3).

CREATE TABLE remote_plz_orte (
       plz 		int(5) NOT NULL,
       ort 		varchar(50) NOT NULL,
       PRIMARY KEY 	(plz, ort),
)
ENGINE=FEDERATED
CONNECTION=
       'mysql://user:password@production:3306
       /instance1/plz_orte';
Abb. 3: Anlegen einer Tabelle, die ihre Daten vom Server "produktion" aus der Tabelle "plz_orte" in der Datenbank "instance1" bezieht. Natürlich muss für die entfernte Datenbank ein gültiger User Account bereitgestellt werden (hier repräsentiert durch "user" und "password").

Die Storage Engine ist optimal geeignet für Daten, die in mehreren Applikationen parallel benötigt werden. So können etwa Informationen zu Kunden zentral in einer Instanz gespeichert und dort auch gesichert werden. Alle anderen Datenbanken greifen dann über diesen Tabellentypen zentral auf die Daten zu.

Ideal Standard

Bis zur Version 5.0 wurden die Metadaten einer MySQL-Datenbank nicht − wie bei anderen Datenbanksystemen üblich − durch Systemtabellen bereitgestellt. Vielmehr gab es eine Reihe von SHOW-Befehlen, über welche die benötigten Informationen abgefragt werden konnten (z. B. "SHOW databases", um die verfügbaren Schemata/Datenbanken zu ermitteln).

Leider sind diese SHOW-Befehle MySQL spezifisch und entsprechen keinem Standard. Aus diesem Grund wurde in der Version 5 die Meta-Datenbank "information_schema" implementiert.

Diese enthält in Tabellenform alle benötigten Metadaten zu Tabellen, User, Prozeduren etc. und entspricht damit ebenfalls dem vereinbarten Standard SQL:2003. Im Vergleich zu anderen Datenbanksystemen, kommt die MySQL-Metadatenbank mit der geringen Anzahl von 20 Tabellen aus.

Fernbedienung für Administratoren

Ebenfalls neu ist der so genannte Instance Manager, der es Administratoren erlaubt, mehrere Datenbanken remote zu starten und/oder zu stoppen. Darüber hinaus überwacht der Instance Manager die Datenbanken und deren Dienste und startet diese zum Beispiel nach einem Crash unverzüglich neu. So können teure Ausfallzeiten auf ein Minimum reduziert werden.

Zusätzlich können die Datenbanken über den Instance Manager remote konfiguriert und deren Logfiles eingesehen und analysiert werden. Leider steht dieses Produkt derzeit nicht für Windows-Systeme zur Verfügung.

Bäumchen wechsel dich

Zusätzlich hat MySQL der aktuellen Datenbank ein neues Tool beiseite gestellt, um den Wechsel von Fremdprodukten noch einfacher zu gestalten. Das grafisch orientierte "MySQL Migration Toolkit" ermöglicht derzeit eine problemlose Migration von den folgenden Datenbanksystemen zu MySQL:

In acht einfachen Schritten werden wahlweise ganze Schemata oder nur einzelne Tabellen in die MySQL-Datenbank migriert (siehe Abbildung 4). Die internen Test-Migrationen von Oracle 10g/9i und einem MS SQL Server auf MySQL verliefen absolut problemlos.

Neben dem grafischen Produkt steht natürlich auch eine Kommando- Variante zur Verfügung, über welche sich Migrationsvorgänge sehr leicht automatisieren lassen.

Migration Tool
Abb. 4: Das neue "MySQL Migration Tool" erleichtert jedem DBA die Migration. In acht einfachen Schritten werden die notwendigen Parameter zur Migration abgefragt(vergrößern!).

Fazit

Der Abstand zu den etablierten Datenbanksystemen ist mit der neuen Version kleiner geworden. Viele lange vermisste Features können nun genutzt werden. Ob dies zu einem bahnbrechenden Erfolg der neuen Version führt, ist allerdings fraglich. Neben der konsequenten Weiterentwicklung der Datenbank muss auch am Image des Produktes weiter gearbeitet werden. All zu oft hört man weiterhin das Vorurteil, dass MySQL lediglich als Datenverwalter für Online- Shops oder Gästebücher im Web-Bereich zu gebrauchen sei.

Insofern kommt die neue Version − in Zeiten knapper IT-Budgets − vielleicht gerade im richtigen Moment, um doch noch als "wichtigstes Release" in der Geschichte von MySQL gefeiert zu werden. Das Potential dafür ist vorhanden.

Haben Sie Interesse am Einsatz von MySQL-Datenbanken oder benötigen Produktschulungen in diesem Umfeld? Dann wenden sie sich einfach an uns.

Matthias Jung (info@ordix.de).