11.6. MySQL Architektur

MySQL ist die sicherlich am weitesten verbreitete Datenbank für kleine Anwendungen, multi threaded programmiert. Je User wird ein eigener Thread, ein Prozess gestartet, der mit dem Haupt - Datenbankprozess das RAM teilt, aber auch eigenen Speicher für seine Abfragen, zum Sortieren, für Pufffer, u.s.w. benötigt. Mehr zu Threads, siehe Abschnitt 7.7. Greifen viele User gleichzeitig auf eine Datenbank zu, viele davon schreibend, so blockiert MySQL 3.x und 4.x dauernd, die Performance bricht völlig ein. Der Grund hierfür ist, daß zum Schreiben eines Datensatzes die komplette Tabelle gesperrt wird, table lock genannt. MySQL 4.1.x ist da schon besser, es beherrscht record locking, transactions, foreign keys, union, aber nur in Verbindung mit dem InnoDB Datenbankformat. Hiermit ist jedoch die in MySQL enthaltene Replikation (Master-Slave) zwischen zwei Datenbanken nicht möglich. Dies funktioniert nur mit dem alten Datenbankformat aus MySQL 3.x (MyISAM), wo nur table locking möglich ist. Es gibt aber noch einen anderen Grund, warum MySQL in der Performance einbrucht, nämlich die unter Linux fehlende Fähigkeit zu ASYNC I/O. Selbst wenn MySQL 4.x mittels ROW - LOCKING nur wenige Datensätze sperrt, so kann dennoch nur ein Thread schreibend auf die Datenbank zugreifen. Nur dann, wenn Linux auf File - oder RAW Device - Ebene ASYNC I/O unterstützte (erst ab Fedora Linux gibt es KAIO, LibAIO), und gleichzeitig MySQL die Library libaio nutzen würde, würden die Threads von MySQL sich nicht gegenseitig blockieren. Die Table - Locks von MySQL 3.x sind also nicht die einzigen Hindernisse. Wer zu MySQL 4.x wegen der Fähigkeit zum ROW - Locking wechselt, und sich davon höhere Performance bei vielen, gleichzeitigen Cientzugriffen für Lesen und Schreiben verspricht, wird enttäuscht sein. MySQL ist ausschließlich geeignet für Anwendungen, wo fast nur lesend zugegriffen wird, also die Schreibzugriffe nur von kurzer Dauer sind, und nur eine persistente Verbindung z.B. zu PHP im Apache Webserver aufgebaut wird. Für Websites mit wenigen, gleichzeitigen Zugriffen ist MySQL hervorragend geeignet, auch für Datenvolumina, welche mehrere 100.000.000 Datensätze umfasst. Komplexe SQL Statements mit verschachtelten Abfragen, group by, having, ... sind bei MySQL nicht möglich, weil erstens die SQL Abfragesprache nur ein Subset von SQL 92 ist, zweitens viele Sprachelemente sich nicht miteinander kombinieren lassen (keine Orthogonalität), und drittens MySQL so viele Fehler und Überraschungen enthält, daß man kaum (komplexere) Queries schreiben kann, bei denen das Ergebnis vorhersagbar ist: Siehe MySQL Gotchas.

Weil MySQL meist keine raw devices verwendet, und auf dem Filesystem arbeitet, ist MySQL auch ca. 30% langsamer, als wenn MySQL auf RAW - Devices schreibt. Hier kann man noch etwas tunen. Die Firma MySQL AB bietet eine MySQL Cluster Lösung an, die nichts anderes ist, als ein vorgeschalteter Router mit Load Balancing / Redirector namens LVS. Nur wenige Kommandos auf der Konsole einer Linux Workstation genügen, um Linux zu einem Load-Balancer und "Linux director" (vergl. zu "CISCO Director") zu machen. Auch diesen kann man noch hochverfügbar aufbauen, damit bei Ausfall ein zweiter Load Balancer übernehmen kann. So verkauft MySQL AB diese Lösung als 99.999%. Mehr hierzu siehe Kapitel 22.