High Performance MySQL: Optimierung, Backups, Replikation und Lastverteilung, 2. Auflage

he sc e e ut ab ag De sg ufl Au 2. A

r

de

Fortgeschrittene Techniken für MySQL-Administratoren

High Performance MySQL Optimierung, Datensicherung, Replikation & Lastverteilung

O’Reilly

Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremy D. Zawodny, Arjen Lentz & Derek J. Balling Deutsche Übersetzung von Kathrin Lichtenberg

High Performance MySQL Optimierung, Backups, Replikation und Lastverteilung 2. Auflage

Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremy D. Zawodny, Arjen Lentz & Derek J. Balling

Deutsche Übersetzung von Kathrin Lichtenberg

Beijing · Cambridge · Farnham · Köln · Sebastopol · Taipei · Tokyo

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen. Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Kommentare und Fragen können Sie gerne an uns richten: O’Reilly Verlag Balthasarstr. 81 50670 Köln E-Mail: [email protected]

Copyright der deutschen Ausgabe: © 2009 by O’Reilly Verlag GmbH & Co. KG 1. Auflage 2005 2. Auflage 2009 Die Originalausgabe erschien 2008 unter dem Titel High Performance MySQL: Optimization, Backups, Replication and more, 2nd Edition bei O’Reilly Media, Inc. Die Darstellung eines Sperbers im Zusammenhang mit dem Thema MySQL ist ein Warenzeichen von O’Reilly Media, Inc.

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. Übersetzung und deutsche Bearbeitung: Kathrin Lichtenberg, Ilmenau Lektorat: Christine Haite, Köln Korrektorat: Friederike Daenecke, Zülpich Satz: Tim Mergemeier, Reemers Publishing Services GmbH, Krefeld; www.reemers.de Umschlaggestaltung: Karen Montgomery, Boston & Michael Oreal, Köln Produktion: Andrea Miß, Köln Belichtung, Druck und buchbinderische Verarbeitung: Druckerei Kösel, Krugzell; www.koeselbuch.de

ISBN 978-3-89721-889-5 Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.

Inhalt

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI .............................................. 1 Die logische Architektur von MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Nebenläufigkeitskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Multi-Version Concurrency Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Die Storage-Engines von MySQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1 Die MySQL-Architektur

2 Engpässe finden: Benchmarking und Profiling. . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Wozu Benchmarks? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benchmarking-Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benchmarking-Taktiken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benchmarking-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benchmarking-Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Profiling des Betriebssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36 36 41 46 48 59 82

3 Schema-Optimierung und Indizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Optimale Datentypen auswählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Grundlagen der Indizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Indizierungsstrategien für High Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Indizierung – eine Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Index- und Tabellenpflege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Normalisierung und Denormalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 ALTER TABLE beschleunigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Hinweise zu Storage-Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

|

V

4 Optimierung der Abfrageleistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Grundlagen langsamer Abfragen: Datenzugriff optimieren . . . . . . . . . . . . . . . . . Methoden zum Umstrukturieren von Abfragen. . . . . . . . . . . . . . . . . . . . . . . . . . Grundlagen der Abfrageverarbeitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grenzen des MySQL-Abfrageoptimierers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bestimmte Arten von Abfragen optimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hinweise für den Abfrageoptimierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benutzerdefinierte Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Erweiterte MySQL-Funktionen

...................................... Der MySQL-Abfrage-Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Code in MySQL speichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cursor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vorbereitete Anweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benutzerdefinierte Funktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeichensätze und Sortierreihenfolgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Volltextsuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fremdschlüsselbeschränkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Merge-Tabellen und Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verteilte (XA-) Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

163 169 172 192 202 210 213

220 220 234 242 243 248 250 255 263 272 273 283

6 Die Servereinstellungen optimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Grundlagen der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Allgemeines Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Ein-/Ausgabeverhalten von MySQL anpassen . . . . . . . . . . . . . . . . . . . . . . . Die MySQL-Nebenläufigkeit anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lastbasierte Anpassungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verbindungsbezogene Werte anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Betriebssystem- und Hardwareoptimierung

........................... Was beschränkt die Leistung von MySQL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie Sie CPUs für MySQL auswählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Speicher- und Festplattenressourcen abwägen. . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware für einen Slave wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAID-Leistungsoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Storage Area Networks und Network-Attached Storage . . . . . . . . . . . . . . . . . . . Mehrere Festplatten-Volumes benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Netzwerkkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VI

| Inhalt

287 293 304 320 323 330

331 332 332 336 345 345 354 355 358

Ein Betriebssystem wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ein Dateisystem wählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Threading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Betriebssystemstatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Replikation

..................................................... Replikation im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Replikation einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Replikation näher betrachtet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Replikationstopologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Replikation und Kapazitätsplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Replikationsadministration und -wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Replikationsprobleme und Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie schnell ist die Replikation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Zukunft der MySQL-Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

360 361 363 364 366

373 373 377 386 393 408 410 421 441 443

9 Skalierung und Hochverfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MySQL skalieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lastausgleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hochverfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

446 448 475 487

10 Optimierung auf Anwendungsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 Überblick über die Anwendungsleistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Webserverprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MySQL erweitern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alternativen zu MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

498 502 505 512 514

11 Backup und Wiederherstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Überlegungen und Kompromisse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Binärlogs organisieren und sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Daten in einem Backup sichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wiederherstellung aus einem Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup- und Wiederherstellungsgeschwindigkeit . . . . . . . . . . . . . . . . . . . . . . . . Backup-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backups mit Skripten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

516 521 531 534 546 558 558 566

Inhalt | VII

12 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Account-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Betriebssystemsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Netzwerksicherheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datenverschlüsselung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MySQL in einer chroot-Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 Der MySQL-Serverstatus

........................................... Systemvariablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SHOW STATUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SHOW INNODB STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SHOW PROCESSLIST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SHOW MUTEX STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status der Replikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INFORMATION_SCHEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

570 571 592 593 601 606

608 608 609 616 631 631 633 634

14 Werkzeuge für High Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636 Schnittstellenwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Überwachungswerkzeuge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analysewerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MySQL-Dienstprogramme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weitere Informationsquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

636 638 649 652 655

A Große Dateien übertragen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656 B EXPLAIN benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661 C Sphinx mit MySQL benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677 D Sperren debuggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706 Index

...............................................................

VIII | Inhalt

717

Vorwort

Wir hatten für dieses Buch verschiedene Ziele im Sinn. Viele von ihnen rührten daher, dass wir über das sagenumwobene perfekte MySQL-Buch nachdachten, das noch niemand von uns zu Gesicht bekommen hatte, nach dem wir jedoch in den Regalen der Buchläden Ausschau hielten. Andere Ideen stammten aus unseren umfassenden Erfahrungen, die wir sammelten, wenn wir anderen Benutzern halfen, MySQL in ihren Umgebungen zum Laufen zu bringen. Wir wollten ein Buch, das nicht nur ein SQL-Einstieg ist. Wir wollten ein Buch mit einem Titel, der nicht in einem beliebigen Zeitrahmen begann oder endete (»…in 30 Tagen«, »In sieben Tagen zu besseren…«) und nicht von oben herab auf den Leser »einredete«. Vor allem wollten wir ein Buch, das Ihnen helfen würde, Ihre Fähigkeiten auf die nächste Stufe zu bringen und schnelle, zuverlässige Systeme mit MySQL aufzubauen – eines, das Fragen beantworten würde wie: »Wie kann ich einen Cluster aus MySQL-Servern einrichten, die in der Lage sind, Millionen und Abermillionen von Abfragen zu verarbeiten, und sicherstellen, dass alles weiter funktioniert, auch wenn einige der Server sterben?« Wir beschlossen, ein Buch zu schreiben, das sich nicht nur auf die Bedürfnisse der MySQL-Anwendungsentwickler konzentrierte, sondern auch auf die rigorosen Anforderungen des MySQL-Administrators, der das System am Laufen halten muss, was auch immer die Programmierer oder Benutzer dem Server zumuten. Infolgedessen gehen wir davon aus, dass Sie bereits relativ erfahren mit MySQL sind und idealerweise ein einführendes Buch darüber gelesen haben. Wir setzen außerdem eine gewisse Erfahrung mit der allgemeinen Systemadministration, dem Betrieb von Netzwerken und Unix-artigen Betriebssystemen voraus. Diese überarbeitete und erweiterte zweite Auflage enthält eine tiefergehende Behandlung all der Themen aus der ersten Auflage sowie viele neue Themen. Zum Teil ist dies eine Reaktion auf die Änderungen, die seit der ersten Veröffentlichung des Buches stattgefunden haben: MySQL ist jetzt eine viel größere und komplexere Software. Genauso wichtig: Seine Beliebtheit hat stark zugenommen. Die MySQL-Community ist sehr gewachsen, und große Unternehmen setzen MySQL inzwischen für ihre entscheidenden Anwendungen ein. Seit der ersten Auflage wird MySQL als vollwertige Software für den

| IX

Einsatz in Unternehmen angesehen.1 Es wird immer mehr auch für Anwendungen im Internet eingesetzt, wo Ausfallzeiten und andere Probleme nicht verschleiert oder toleriert werden können. Aus diesem Grund hat diese zweite Auflage einen etwas anderen Schwerpunkt als die erste Auflage. Wir betonen die Zuverlässigkeit und Korrektheit fast genauso stark wie die Performance – zum Teil, weil wir MySQL selbst für Anwendungen einsetzt haben, bei denen nicht unwesentliche Mengen Geldes vom Datenbankserver abhängen. Wir verfügen außerdem über umfassende Erfahrungen mit Webanwendungen, bei denen MySQL sehr populär geworden ist. Die zweite Auflage spricht die erweiterte Welt von MySQL an, die in dieser Form noch nicht existierte, als die erste Auflage erschienen ist.

Wie dieses Buch aufgebaut ist Wir haben in dieses Buch eine Menge komplizierter Themen aufgenommen. Hier wollen wir erklären, in welcher Reihenfolge wir sie zusammengestellt haben, damit sie leichter zu lernen sind.

Ein breiter Überblick Kapitel 1, Die MySQL-Architektur, widmet sich den Grundlagen – Dingen, mit denen Sie vertraut sein müssen, bevor Sie tiefer einsteigen. Sie müssen verstehen, wie MySQL organisiert ist, bevor Sie in der Lage sind, es effektiv zu benutzen. Dieses Kapitel erläutert die Architektur von MySQL und liefert wesentliche Fakten über seine Storage-Engines. Es hilft Ihnen beim Einstieg, falls Sie nicht mit den Grundlagen relationaler Datenbanken, inklusive Transaktionen, vertraut sind. Dieses Kapitel ist auch ganz nützlich, wenn dieses Buch Ihr Einstieg in MySQL ist, Sie sich aber schon mit einer anderen Datenbank, wie etwa Oracle, auskennen.

Eine solide Grundlage bauen Die nächsten vier Kapitel behandeln Material, auf das Sie immer wieder stoßen werden, wenn Sie MySQL benutzen. Kapitel 2, Engpässe finden: Benchmarking und Profiling, diskutiert die Grundlagen des Benchmarkings und Profilings – d.h., wie Sie feststellen, mit welcher Art von Arbeitsbelastung Ihr Server umgehen kann, wie schnell er bestimmte Aufgaben ausführen kann usw. Sie werden Ihre Anwendung sowohl vor als auch nach einer großen Änderung einem Benchmark-Test unterziehen, damit Sie beurteilen können, wie effektiv Ihre Änderungen sind. Was wie eine positive Änderung scheint, könnte sich unter realem Stress als negativ herausstellen, und Sie werden nie wissen, was wirklich eine schlechte Leistung verursacht, wenn Sie es nicht exakt messen. 1 Wir glauben, dass diese Phrase im Wesentlichen Marketing-Geblubber ist, sie scheint aber für viele Leute eine gewisse Wichtigkeit zu vermitteln.

X

| Vorwort

In Kapitel 3, Schema-Optimierung und Indizierung, behandeln wir die verschiedenen Nuancen der Datentypen, Tabellendesigns und Indizes. Ein gut gestaltetes Schema unterstützt MySQL bei der Arbeit. Viele der Dinge, die wir in späteren Kapiteln besprechen, sind davon abhängig, wie gut Ihre Anwendung die Indizes von MySQL zum Laufen bringt. Ein solides Verständnis der Indizes und ihrer Verwendung ist entscheidend für die effektive Benutzung von MySQL, so dass Sie wahrscheinlich öfter einmal zu diesem Kapitel zurückkehren werden. Kapitel 4, Optimierung der Abfrageleistung, erläutert, wie MySQL Abfragen ausführt und wie Sie die Stärken seines Abfrageoptimierers ausnutzen können. Ein sicheres Gespür dafür, wie der Abfrageoptimierer funktioniert, wirkt Wunder für Ihre Abfragen und hilft Ihnen dabei, die Indizes besser zu verstehen. (Indizierung und Abfrageoptimierung stellen eine Art Henne-Ei-Problem dar; möglicherweise hilft es, Kapitel 3 erneut zu lesen, wenn Sie mit Kapitel 4 fertig sind.) Dieses Kapitel präsentiert außerdem besondere Beispiele für praktisch alle gebräuchlichen Klassen von Abfragen, womit verdeutlicht wird, wo MySQL gute Arbeit leistet und wie man Abfragen in Formen umwandelt, die seine Stärken ausnutzen. Bis zu dieser Stelle haben wir die Grundlagen behandelt, die für jede Datenbank gelten: Tabellen, Indizes, Daten und Abfragen. Kapitel 5, Erweiterte MySQL-Funktionen, geht über die Grundlagen hinaus und zeigt Ihnen, wie die erweiterten Funktionen von MySQL arbeiten. Wir untersuchen den Abfrage-Cache, gespeicherte Prozeduren, Trigger, Zeichensätze und mehr. MySQLs Implementierung dieser Merkmale unterscheidet sich von der anderer Datenbanken, und ein gutes Verständnis dafür kann neue Möglichkeiten für Leistungsgewinne öffnen, die Sie möglicherweise sonst nicht erkannt hätten.

Ihre Anwendung verbessern In den nächsten beiden Kapiteln besprechen wir, wie man Änderungen vornimmt, um die Leistung Ihrer MySQL-basierten Anwendung zu verbessern. In Kapitel 6, Die Servereinstellungen optimieren, erläutern wir, wie Sie MySQL so einstellen, dass es das meiste aus Ihrer Hardware herausholt und so gut wie möglich für Ihre spezielle Anwendung funktioniert. Kapitel 7, Betriebssystem- und Hardwareoptimierung, zeigt, wie Sie das Betriebssystem und die Hardware am besten ausnutzen. Wir schlagen außerdem Hardware-Konfigurationen vor, die eine bessere Leistung für größere Anwendungen liefern.

Erweiterungen nach Änderungen Ein Server reicht nicht immer aus. In Kapitel 8, Replikation, besprechen wir die Replikation, d.h., wie Sie Ihre Daten automatisch auf mehrere Server kopiert bekommen. Kombiniert mit Skalierung, Lastausgleich und den Lektionen über Hochverfügbarkeit in Kapitel 9, Skalierung und Hochverfügbarkeit, bietet Ihnen das die Grundlage, um Ihre Anwendungen so zu skalieren, wie Sie sie brauchen.

Vorwort | XI

Eine Anwendung, die auf einem groß ausgebauten MySQL-Backend läuft, bietet oft wesentliche Möglichkeiten zur Optimierung in der Anwendung selbst. Es gibt bessere und schlechtere Methoden, um große Anwendungen zu gestalten. Sie sollen über den Tellerrand von MySQL hinaussehen. Kapitel 10, Optimierung auf Anwendungsebene, hilft Ihnen dabei, zu verbessernde Schwachstellen in Ihrer Gesamtarchitektur zu erkennen, vor allem, wenn es sich um eine Webanwendung handelt.

Ihre Anwendung zuverlässig machen Auch die am besten gestaltete, gut skalierbare Architektur nützt nichts, wenn sie Stromausfälle, bösartige Angriffe, Fehler in der Anwendung oder der Programmierung und andere Katastrophen nicht überstehen kann. In Kapitel 11, Backup und Wiederherstellung, diskutieren wir die verschiedenen Backupund Wiederherstellungsstrategien für Ihre MySQL-Datenbanken. Diese Strategien helfen Ihnen dabei, Ausfallzeiten zu minimieren, falls irgendwann (was unweigerlich geschehen wird) die Hardware kaputtgeht, und sie helfen Ihnen sicherzustellen, dass Ihre Daten solche Katastrophen überleben. Kapitel 12, Sicherheit, bietet Ihnen einen soliden Einblick in einige der Sicherheitsprobleme, die mit dem Betrieb eines MySQL-Servers verbunden sind. Noch wichtiger: Wir machen viele Vorschläge, mit deren Hilfe Sie verhindern können, dass Außenstehende die Server beschädigen, die Sie die ganze Zeit zu konfigurieren und zu optimieren versuchen. Wir erläutern einige der selten erkundeten Bereiche der Datenbanksicherheit, wobei wir Ihnen sowohl die Vorteile als auch die Auswirkungen auf die Performance der verschiedenen Praktiken zeigen. In Bezug auf die Leistung zahlt es sich normalerweise aus, einfache und klare Sicherheitsstrategien zu wählen.

Verschiedene nützliche Themen In den letzten Kapiteln und den Anhängen des Buches befassen wir uns mit verschiedenen Themen, die entweder in keines der früheren Kapitel »passen« oder auf die in anderen Kapiteln so oft verwiesen wird, dass sie ein wenig mehr Aufmerksamkeit verdienen. Kapitel 13, Der MySQL-Serverstatus, zeigt Ihnen, wie Sie Ihren MySQL-Server untersuchen. Es ist wichtig zu wissen, wie man Statusinformationen vom Server gewinnt. Noch wichtiger ist es, die Bedeutung dieser Informationen zu kennen. Besonders ausführlich behandeln wir SHOW INNODB STATUS, weil dies Ihnen einen tiefen Einblick in die Operationen der transaktionsfähigen Storage-Engine InnoDB bietet. Kapitel 14, Werkzeuge für High Performance, stellt Werkzeuge vor, mit denen Sie MySQL effizienter verwalten. Dazu gehören Überwachungs- und Analysewerkzeuge, Werkzeuge zum Schreiben von Abfragen usw. Dieses Kapitel behandelt die Maatkit-Werkzeuge von Baron, mit denen Sie die Funktionalität von MySQL erweitern und sich das Leben als Datenbankadministrator erleichtern können. Es zeigt außerdem ein Programm namens innotop, das Baron als leicht zu bedienende Schnittstelle zu dem, was Ihr MySQL-Server gerade tut, geschrieben hat. Es funktioniert fast wie das Unix-Programm top und kann in

XII | Vorwort

allen Phasen des Einstellungsprozesses gute Dienste leisten, indem es überwacht, was innerhalb von MySQL und seinen Storage-Engines geschieht. Anhang A, Große Dateien übertragen, zeigt Ihnen, wie Sie effizient sehr große Dateien von einer Stelle zur anderen kopieren – ein Muss, wenn Sie große Datenvolumen verwalten. In Anhang B, EXPLAIN benutzen, erfahren Sie, wie Sie den überaus wichtigen EXPLAIN-Befehl verwenden. Anhang C, Sphinx mit MySQL benutzen, ist eine Einführung in Sphinx, ein High-Performance-Volltextindizierungssystem, das die MySQL-eigenen Fähigkeiten ergänzt. Und Anhang D, Sperren debuggen, schließlich zeigt Ihnen, wie Sie entschlüsseln, was passiert, wenn Abfragen Locks anfordern, die einander stören.

Software-Versionen und Verfügbarkeit MySQL ist ständig in der Weiterentwicklung begriffen. Seit Jeremy den Entwurf für die erste Auflage dieses Buches geschrieben hat, sind zahlreiche Versionen von MySQL erschienen. MySQL 4.1 und 5.0 gab es nur als Alpha-Versionen, als die erste Auflage in den Druck ging, aber diese Versionen sind inzwischen seit Jahren im täglichen Einsatz und bilden heute das Rückgrat vieler großer Online-Anwendungen. Als wir diese zweite Auflage abgeschlossen haben, waren stattdessen MySQL 5.1 und 6.0 der neueste Schrei. (MySQL 5.1 ist ein Release-Kandidat, und 6.0 ist im Alpha-Stadium.) Wir haben uns für dieses Buch nicht auf eine einzige Version von MySQL versteift, sondern haben unser umfangreiches kollektives Wissen über MySQL in der echten Welt ins Rennen geworfen. Der Kern dieses Buches konzentriert sich auf MySQL 5.0, weil wir dies als die »aktuelle« Version ansehen. Die meisten unserer Beispiele gehen davon aus, dass Sie eine einigermaßen ausgereifte Version von MySQL 5.0 betreiben, wie etwa MySQL 5.0.40 oder neuer. Wir haben versucht, Eigenschaften oder Funktionalitäten anzugeben, die in älteren Ausgaben nicht existieren oder die es nur in der kommenden 5.1-Serie gibt. Allerdings ist die definitive Referenz zum Zuordnen von Funktionen zu bestimmten Versionen die MySQLDokumentation selbst. Wir erwarten, dass Sie von Zeit zu Zeit in der angegebenen OnlineDokumentation (http://dev.mysql.com/doc/) nachsehen, während Sie dieses Buch lesen. Ein weiterer großartiger Aspekt von MySQL ist, dass es auf allen heute verbreiteten Plattformen läuft: Mac OS X, Windows, GNU/Linux, Solaris, FreeBSD – was Sie wollen! Wir richten uns jedoch vorrangig an Nutzer von GNU/Linux2 und anderen Unix-artigen Betriebssystemen. Windows-Benutzer werden wahrscheinlich einige Unterschiede bemerken. Zum Beispiel sind die Dateipfade völlig anders. Wir verweisen darüber hinaus auf die normalen Unix-Kommandozeilenprogramme; wir gehen davon aus, dass Sie die entsprechenden Befehle unter Windows kennen.3

2 Um Verwirrung zu vermeiden, beziehen wir uns auf Linux, wenn wir über den Kernel schreiben, und auf GNU/Linux, wenn wir über die gesamte Betriebssysteminfrastruktur schreiben, die die Anwendungen unterstützt. 3 Sie erhalten Windows-kompatible Versionen der Unix-Dienstprogramme unter http://unxutils.sourceforge.net oder unter http://gnuwin32.sourceforge.net.

Vorwort

| XIII

Perl ist der andere Knackpunkt, wenn es um MySQL unter Windows geht. MySQL enthält eine Reihe nützlicher Dienstprogramme, die in Perl geschrieben sind, und verschiedene Kapitel in diesem Buch präsentieren beispielhaft Perl-Skripten, die die Grundlage der komplexeren Werkzeuge bilden, die Sie aufbauen. Maatkit ist ebenfalls in Perl geschrieben. Allerdings ist Perl nicht in Windows enthalten. Um diese Skripten zu benutzen, müssen Sie sich eine Windows-Version von Perl von ActiveState herunterladen und die notwendigen Zusatzmodule (DBI und DBD::mysql) für den MySQL-Zugriff installieren.

Konventionen in diesem Buch Folgende typografische Konventionen kommen in diesem Buch zum Einsatz: Kursiv Wird für neue Begriffe, URLs, E-Mail-Adressen, Benutzernamen, Hostnamen, Dateinamen, Dateierweiterungen, Pfadnamen, Verzeichnisse sowie Unix-Befehle und -Dienstprogramme verwendet. Nichtproportionalschrift

Kennzeichnet Codeelemente, Konfigurationsoptionen, Datenbank- und Tabellennamen, Variablen und deren Werte, Funktionen, Module, den Inhalt von Dateien oder die Ausgabe von Befehlen. Nichtproportionalschrift fett

Zeigt Befehle oder anderen Text, der so, wie er ist, vom Benutzer eingegeben werden soll. Wird auch zum Hervorheben in Befehlsausgaben benutzt. Nichtproportionalschrift kursiv

Zeigt Text, der durch Werte ersetzt werden soll, die der Benutzer angibt. Dieses Icon kennzeichnet einen Tipp, einen Vorschlag oder eine allgemeine Anmerkung.

Dieses Icon kennzeichnet eine Warnung oder einen Achtungshinweis.

Die Codebeispiele benutzen Dieses Buch soll Ihnen helfen, Ihre Arbeit zu erledigen. Im Allgemeinen dürfen Sie den Code aus diesem Buch in Ihren Programmen und Dokumentationen einsetzen. Sie müssen uns nicht um Erlaubnis fragen, es sei denn, Sie reproduzieren einen wesentlichen Teil des Codes. Es ist z.B. keine Erlaubnis erforderlich, wenn Sie ein Programm schreiben, das einige Teile des Codes aus diesem Buch benutzt. Wenn Sie dagegen eine CD-ROM mit Beispielen aus O’Reilly-Büchern verteilen oder verkaufen, ist eine Erlaubnis nötig. Das Beantworten einer Frage, indem dieses Buch sowie Beispielcode daraus zitiert werden, XIV | Vorwort

erfordert keine Erlaubnis. Fügen Sie dagegen einen wesentlichen Anteil Beispielcode aus diesem Buch in die Dokumentation Ihres Produkts ein, ist eine Erlaubnis nötig. Die Beispiele stehen auf der Site http://www.highperfmysql.com und werden gelegentlich aktualisiert. Wir können jedoch den Code nicht für jedes kleine Release von MySQL aktualisieren und testen. Wir freuen uns über eine Quellenangabe, bestehen aber nicht darauf. Eine Quellenangabe besteht normalerweise aus Titel, Autor, Verlag und ISBN. Zum Beispiel: »High Performance MySQL/Optimierung, Backups, Replikation und Lastverteilung, 2. Auflage, von Baron Schwartz et al. Copyright 2009, O’Reilly Verlag, ISBN 9783897218895.« Falls Sie das Gefühl haben, dass Ihre Benutzung des Codes durch die oben angegebenen Umstände nicht abgedeckt ist, dann schreiben Sie einfach an [email protected].

Wie Sie mit uns in Verbindung treten Sie können mit den Autoren direkt Kontakt aufnehmen. Barons Weblog finden Sie unter http://www.xaprb.com. Peter und Vadim betreiben zwei Weblogs, das etablierte und beliebte http://www.mysqlperformanceblog.com und das neuere http://www.webscalingblog.com. Sie finden die Website ihrer Firma, Percona, unter http://www.percona.com. Arjens Unternehmen, OpenQuery, besitzt eine Website unter http://openquery.com.au. Arjen betreibt ebenfalls ein Weblog unter http://arjen-lentz.livejournal.com und eine persönliche Site unter http://lentz.com.au.

Danksagungen für die zweite Auflage Sphinx-Entwickler Andrew Aksyonoff schrieb Anhang C, Sphinx mit MySQL benutzen. Wir wollen ihm für seine ausführliche Beschreibung danken. Wir haben beim Schreiben dieses Buches von vielen Leuten unschätzbare Hilfe erhalten. Es ist unmöglich, hier alle aufzuzählen – wir schulden der gesamten MySQL-Gemeinde sowie den Leuten bei MySQL AB unseren Dank. Hier ist eine Liste der Leute, die direkt etwas beigetragen haben; wir entschuldigen uns gleich bei denen, die wir vergessen haben: Tobias Asplund, Igor Babaev, Pascal Borghino, Roland Bouman, Ronald Bradford, Mark Callaghan, Jeremy Cole, Britt Crawford und das HiveDB-Projekt, Vasil Dimov, Harrison Fisk, Florian Haas, Dmitri Joukovski und Zmanda (danke für das Diagramm, das LVM-Schnappschüsse erläutert), Alan Kasindorf, Sheeri Kritzer Cabral, Marko Makela, Giuseppe Maxia, Paul McCullagh, B. Keith Murphy, Dhiren Patel, Sergey Petrunia, Alexander Rubin, Paul Tuckfield, Heikki Tuuri und Michael »Monty« Widenius. Ein besonderer Dank geht an Andy Oram, Isabel Kunkle und Rachel Wheeler, das Lektorenteam bei O’Reilly. Danke auch an den Rest der O’Reilly-Mannschaft.

Vorwort |

XV

Von Baron Ich möchte meiner Frau Lynn Rainville und unserem Hund Carbon danken. Wenn Sie ein Buch geschrieben hätten, dann wüssten Sie sicher, wie dankbar ich ihnen bin. Ganz besonderen Dank schulde ich außerdem Alan Rimm-Kaufman und meinen Kollegen bei der Rimm-Kaufman-Gruppe für ihre Unterstützung und Ermutigung während dieses Projekts. Danke an Peter, Vadim und Arjen dafür, dass sie mir die Möglichkeit gaben, meinen Traum zu verwirklichen. Und danke an Jeremy und Derek dafür, dass sie den Weg für uns gebahnt haben.

Von Peter Seit Jahren führe ich MySQL-Leistungs- und Skalierungspräsentationen, Schulungen und Beratungen durch und wollte immer ein breiteres Publikum erreichen. Deshalb war ich sehr aufgeregt, als Andy Oram an mich herantrat und mich bat, bei diesem Buch mitzuarbeiten. Ich habe vorher noch kein Buch geschrieben, war also nicht darauf vorbereitet, wie viel Zeit und Aufwand so etwas erfordert. Zuerst sprachen wir nur darüber, die erste Auflage zu aktualisieren, um neuere Versionen von MySQL einzubeziehen. Wir wollten aber so viel Material aufnehmen, dass wir schließlich den größten Teil des Buches neu schrieben. Dieses Buch ist wirklich eine Teamleistung. Da ich sehr damit beschäftigt war, Percona, Vadims und meine Beratungsfirma, in Gang zu bringen, und Englisch nicht meine Muttersprache ist, spielten wir alle unterschiedliche Rollen. Ich lieferte den Entwurf und den technischen Inhalt, anschließend sichtete ich das Material, wobei ich es während des Schreibens überarbeitete und erweiterte. Als Arjen (früherer Kopf des MySQL-Dokumentationsteams) zum Projekt stieß, begannen wir damit, den Entwurf mit Leben zu füllen. Die Dinge kamen dann wirklich ins Rollen, als Baron hinzukam, der in wahnwitziger Geschwindigkeit qualitativ hochwertigen Inhalt schreiben kann. Vadim war eine große Hilfe bei den tiefgehenden MySQL-Quellcodetests und wenn wir unsere Behauptungen mit Benchmarks und anderen Untersuchungen untermauern mussten. Während der Arbeit an dem Buch fanden wir immer mehr Bereiche, die wir genauer erkunden wollten. Viele der Themen des Buches, wie etwa Replikation, Abfrageoptimierung, InnoDB, Architektur und Entwurf, könnten leicht eigene Bücher füllen, so dass wir irgendwo aufhören und Material für eine künftige Auflage oder für unsere Blogs, Präsentationen und Artikel lassen mussten. Umfangreiche Hilfe bekamen wir von unseren Gutachtern, die zu den echten MySQLExperten, sowohl innerhalb als auch außerhalb von MySQL AB, gehören. Das sind der MySQL-Begründer Michael Widenius, der InnoDB-Begründer Heikki Tuuri, Igor Babaev, der Chef des MySQL-Optimiererteams, und viele andere.

XVI |

Vorwort

Außerdem danke ich meiner Frau Katya Zaytseva und meinen Kindern Ivan und Nadezhda, dass sie mir erlaubt haben, Zeit, die eigentlich der Familie gewidmet sein sollte, mit dem Buch zu verbringen. Ich bin darüber hinaus den Angestellten von Percona dankbar, dass sie eingesprungen sind, wenn ich verschwand, um an dem Buch zu arbeiten, und natürlich Andy Oram und O’Reilly, dass sie das Buch ermöglicht haben.

Von Vadim Ich danke Peter, mit dem ich wunderbar an diesem Buch zusammengearbeitet habe und auch gern andere Projekte durchführen würde, Baron, der entscheidend dafür verantwortlich ist, dass dieses Buch zustande kam, und Arjen, mit dem zu arbeiten mir viel Spaß macht. Dank gebührt auch unserem Lektor Andy Oram, der viel Geduld mit uns hatte, dem MySQL-Team, das eine großartige Software geschaffen hat, und unseren Kunden, die mir die Möglichkeiten geboten haben, mein MySQL-Verständnis zu schärfen. Und schließlich geht ein besonderer Dank an meine Frau Valerie und unsere Söhne Myroslav und Timur, die mich immer unterstützen und mir helfen voranzukommen.

Von Arjen Ich danke Andy für seine Klugheit, Führung und Geduld. Mein Dank gilt Baron, der auf den Zug zur zweiten Auflage aufgesprungen ist, obwohl er sich schon in Bewegung gesetzt hatte, und Peter und Vadim für die soliden Hintergrundinformationen und Benchmarks. Ein Dank geht auch an Jeremy und Derek, die mit der ersten Auflage das Fundament geschaffen haben. Wie Du, Derek, in meine Kopie geschrieben hast: »Macht es ordentlich, mehr will ich nicht.« Ich danke ebenfalls meinen früheren Kollegen (und jetzigen Freunden) von MySQL AB, wo ich das meiste erfahren habe, was ich über das Thema weiß, und ich möchte in diesem Zusammenhang vor allem Monty erwähnen, den ich weiterhin als stolzen Vater von MySQL betrachte, auch wenn sein Unternehmen jetzt Teil von Sun Microsystems ist. Ich danke außerdem allen anderen in der globalen MySQL-Gemeinschaft. Und last but not least, danke ich meiner Tochter Phoebe, die sich in dieser Phase ihres Lebens noch nicht um das Ding namens »MySQL« kümmert und auch keine Ahnung hat, welcher der Wiggles (die australische Popband, nicht die Zwerge) damit gemeint sein könnte! Für manche ist Ignoranz ein wahrer Segen, und sie bieten uns eine erfrischende Sicht auf die Dinge, die wirklich wichtig sind im Leben. Für alle anderen ist dieses Buch hoffentlich eine sinnvolle Ergänzung im Bücherschrank. Und vergessen Sie nicht zu leben!

Vorwort | XVII

Danksagungen für die erste Auflage Ein Buch wie dieses würde ohne die Hilfe Dutzender Menschen nie Wirklichkeit werden. Ohne sie wäre das Buch, das Sie gerade in den Händen halten, nur ein Haufen an den Rändern unserer Monitore angebrachter Notizen. Dies ist der Teil des Buches, in dem wir über die Leute, die uns geholfen haben, sagen dürfen, was wir wollen. Und wir müssen uns keine Sorgen machen, dass im Hintergrund Musik ertönt, die uns auffordert, den Mund zu halten und zu verschwinden, wie man das von Preisverleihungen im Fernsehen kennt. Wir hätten dieses Projekt ohne das ständige Drängeln, Betteln, Fordern und die Unterstützung unseres Lektors Andy Oram niemals abschließen können. Wenn es eine Person gibt, die dafür verantwortlich ist, dass Sie dieses Buch in den Händen halten, dann ist es Andy. Wir wissen die wöchentlichen Meckerrunden wirklich zu schätzen. Aber natürlich ist Andy nicht allein. Bei O’Reilly hatte eine ganze Menge anderer Leute ihren Anteil daran, dass aus den am Monitor befestigten Notizen das Buch wurde, das Sie gerade lesen möchten, deshalb wollen wir an dieser Stelle auch den Produktions-, Grafikund Marketingleuten danken, die uns dabei behilflich waren, dieses Buch zu schaffen. Und natürlich geht unser Dank auch an Tim O’Reilly für sein fortwährendes Engagement, die beste Dokumentation zu populärer Open-Source-Software zu veröffentlichen. Abschließend geht unser Dank an die Leute, die sich bereit erklärt haben, die verschiedenen Rohfassungen dieses Buches anzuschauen und uns all die Dinge aufzuzeigen, die wir falsch gemacht haben: unsere Korrektoren. Sie haben einen Teil ihres 2003er-Urlaubs damit verbracht, sich grob formatierte Versionen dieses Textes anzuschauen, der voller Schreibfehler, irreführender Anweisungen und mathematischer Fehler war. Unser Dank geht (ohne bestimmte Reihenfolge) an Brian »Krow« Aker, Mark »JDBC« Matthews, Jeremy »the other Jeremy« Cole, Mike »VBMySQL.com« Hillyer, Raymond »Rainman« De Roo, Jeffrey »Regex Master« Friedl, Jason DeHaan, Dan Nelson, Steve »Unix Wiz« Friedl und Kasia »Unix Girl« Trapszo.

Von Jeremy Ich möchte noch einmal Andy dafür danken, dass er dieses Projekt übernommen und uns fortlaufend weitere Kapitel abgerungen hat. Dereks Hilfe war unerlässlich, um die letzten 20–30 % des Buches abschließen zu können, ohne einen weiteren Zieltermin zu verpassen. Dank dafür, dass er noch so spät in diesen Prozess eingestiegen ist, meine sporadischen Produktivitätsausbrüche verarbeitet hat und die XML-Arbeit, Kapitel 10, Anhang C und all die anderen Dinge übernommen hat, die ich auf ihn abgewälzt habe. Ich muss auch meinen Eltern danken, die mir vor so vielen Jahren den ersten Commodore 64 kauften. Sie haben nicht nur die ersten zehn Jahre alles toleriert, was nach einer lebenslangen Besessenheit für Elektronik und Computertechnik aussah, sondern unterstützten auch sehr schnell meinen nie endenden Wunsch, mehr zu lernen und zu tun.

XVIII | Vorwort

Als Nächstes möchte ich einer Gruppe von Leuten danken, mit denen ich in den vergangenen Jahren arbeiten durfte, während ich missionarisch die Lehre von MySQL bei Yahoo! verbreitete. Jeffrey Friedl und Ray Goldberger ermutigten mich seit den frühen Anfängen dieses Unternehmens und lieferten Feedback zurück. Gleichzeitig fanden sich Steve Morris, James Harvey und Sergey Kolychev mit meinen scheinbar pausenlosen Experimenten mit den Yahoo! Finance MySQL-Servern ab, auch wenn dies ihre wichtige Arbeit störte. Dank auch an die unzähligen anderen Yahoo!s, die mir dabei halfen, interessante MySQL-Probleme und -Lösungen zu finden. Und, was noch wichtiger ist, danke für das Vertrauen und den Glauben an mich, der notwendig war, um MySQL an einer der wichtigsten und sichtbarsten Stellen des Yahoo!-Geschäfts einsetzen zu dürfen. Adam Goodman, Herausgeber und Besitzer des Linux Magazine, erleichterte mir den Einstieg in die Welt des Schreibens für ein technisches Publikum, indem er meine ersten längeren MySQL-Artikel im Jahr 2001 veröffentlichte. Seither hat er mir mehr über redaktionelle Bearbeitung und Herausgabe beigebracht, als ihm bewusst war, und mich ermutigt, diesen Weg weiterzugehen, indem er mir eine eigene monatliche Kolumne in seinem Magazin gewährte. Danke, Adam. Ich danke Monty und David dafür, MySQL mit der Welt zu teilen. Und da wir gerade bei MySQL AB sind, möchte ich auch all den anderen danken, die mich ermutigt haben, dieses Buch zu schreiben: Kerry, Larry, Joe, Marten, Brian, Paul, Jeremy, Mark, Harrison, Matt und dem Rest des Teams. Ihr seid der Hammer. Schließlich möchte ich all meinen Weblog-Lesern danken, die mich ermutigt haben, jeden Tag informell über MySQL und andere technische Themen zu schreiben.

Von Derek Wie Jeremy möchte ich, aus den gleichen Gründen, meiner Familie danken. Ich möchte meinen Eltern danken, die mich fortwährend ermutigt haben, ein Buch zu schreiben, auch wenn das Ergebnis nicht dem entspricht, was sie im Sinn hatten. Meine Großeltern brachten mir zwei wertvolle Dinge bei: den Umgang mit Geld und die Liebe zu Computern (als sie mir das Geld für meinen ersten Commodore VIC-20 liehen). Ich kann Jeremy nicht genug danken, mich zu dieser Achterbahnfahrt des Buchschreibens eingeladen zu haben. Es war eine großartige Erfahrung, und ich hoffe, zukünftig wieder mit ihm arbeiten zu können. Besonderer Dank geht an Raymond De Roo, Brian Wohlgemuth, David Calafrancesco, Tera Doty, Jay Rubin, Bill Catlan, Anthony Howe, Mark O’Neal, George Montgomery, George Barber und die vielen anderen Menschen, die sich mein Meckern angehört haben, auf die ich meine Ideen loslassen durfte, um zu sehen, ob ein Außenstehender verstehen kann, was ich zu sagen versuche, oder die ein Lächeln auf meine Lippen zauberten, als ich es am meisten brauchte. Ohne euch wäre das Buch vielleicht auch geschrieben worden, aber ich wäre darüber verrückt geworden.

Vorwort | XIX

KAPITEL 1

Die MySQL-Architektur

Die MySQL-Architektur unterscheidet sich stark von der anderer Datenbankserver und ist sehr vielseitig einsetzbar. MySQL ist zwar nicht perfekt, aber dennoch so flexibel, dass es in anspruchsvollen Umgebungen, wie etwa Webanwendungen, gut funktioniert. Gleichzeitig kann MySQL eingebettete Anwendungen, Data-Warehouses, Content-Indexing- und -Delivery-Software, hochverfügbare redundante Systeme, Online Transaction Processing (OLTP) und vieles mehr versorgen. Um das meiste aus MySQL herauszuholen, müssen Sie seinen Aufbau verstehen, damit Sie mit ihm und nicht gegen es arbeiten. MySQL ist ausgesprochen flexibel. So können Sie es für den Gebrauch auf vielerlei Hardware konfigurieren, außerdem unterstützt es eine Vielzahl von Datentypen. Die ungewöhnlichste und wichtigste Eigenart von MySQL ist jedoch seine Storage-Engine-Architektur, deren Design die Verarbeitung von Abfragen sowie andere Serveraufgaben von der Datenspeicherung und -bereitstellung trennt. In MySQL 5.1 können Sie Storage-Engines sogar als Laufzeit-Plugins laden. Diese Trennung erlaubt es Ihnen, tabellenweise zu entscheiden, wie Ihre Daten gespeichert werden und welche Leistungen, Funktionen und andere Eigenschaften Sie haben wollen. Dieses Kapitel bietet einen Überblick über die MySQL-Serverarchitektur, zeigt die wesentlichen Unterschiede zwischen den Storage-Engines und erläutert, weshalb diese Unterschiede wichtig sind. Wir versuchen, MySQL zu erklären, indem wir Details vereinfachen und Beispiele zeigen. Diese Diskussion ist vor allem für Neulinge auf dem Gebiet der Datenbankserver sinnvoll sowie für Leser, die sich eher mit anderen Datenbankservern auskennen.

Die logische Architektur von MySQL Es wird Ihnen helfen, den Server zu verstehen, wenn Sie sich eine Vorstellung davon machen, wie die Komponenten von MySQL zusammenarbeiten. Abbildung 1-1 zeigt den Aufbau von MySQL aus logischer Sicht.

|

1

Clients

Verbindungs-/Thread-Verarbeitung

AbfrageCache

Parser

Optimierer

Storage-Engines

Abbildung 1-1: Logischer Aufbau der MySQL-Serverarchitektur

Die oberste Schicht enthält die Dienste, die nicht allein von MySQL verwendet werden. Diese Dienste werden von den meisten netzwerkbasierten Client/Server-Programmen oder -Servern benötigt: Behandlung von Verbindungen, Authentifizierung, Sicherheit usw. In der zweiten Schicht werden die Dinge interessant. Ein Großteil des in MySQL investierten Gehirnschmalzes liegt hier, einschließlich des Codes für Parsing, Analyse, Optimierung, Caching von Abfragen sowie alle fest eingebauten Funktionen (z.B. Datum, Zeit, Mathematik und Verschlüsselung). Jegliche Funktionalität, die über StorageEngines hinweg zur Verfügung gestellt wird, ist hier zusammengefasst: z.B. gespeicherte Prozeduren (Stored Procedures), Trigger und Sichten. Die dritte Schicht enthält die Storage-Engines (auch: Speicher-Engines). Sie sind für die Speicherung und den Abruf aller Daten verantwortlich, die »in« MySQL gespeichert werden. Wie die verschiedenen unter GNU/Linux zur Verfügung stehenden Dateisysteme besitzt jede Storage-Engine ihre Vor- und Nachteile. Der Server kommuniziert mit ihnen über die Storage-Engine-API. Diese Schnittstelle verbirgt die Unterschiede zwischen den Storage-Engines, so dass sie auf der Abfrageebene im Großen und Ganzen transparent sind. Die API enthält einige Dutzend Low-Level-Funktionen für solche Operationen wie »beginne eine Transaktion« oder »lies die Zeile mit dem Primärschlüssel«. Die StorageEngines verarbeiten weder SQL1 noch kommunizieren sie miteinander; sie reagieren einfach auf Anforderungen vom Server.

1 Eine Ausnahme bildet InnoDB, das fremde Schlüsseldefinitionen verarbeitet, weil der MySQL-Server diese nicht selbst implementiert.

2 | Kapitel 1: Die MySQL-Architektur

Verbindungsmanagement und Sicherheit Jede Clientverbindung erhält innerhalb des Serverprozesses ihren eigenen Thread. Die Abfragen der Verbindung werden in dem jeweiligen Thread ausgeführt, der sich wiederum auf einem Prozessorkern oder einer CPU befindet. Der Server speichert Threads im Cache, so dass sie bei einer neuen Verbindung nicht jedes Mal erzeugt und zerstört werden müssen.2 Wenn Clients (Anwendungen) eine Verbindung zum MySQL-Server herstellen, muss der Server sie authentifizieren. Die Authentifizierung erfolgt anhand des Benutzernamens, des Ursprungshosts und des Passworts. Über eine SSL-Verbindung (Secure Sockets Layer) können auch X.509-Zertifikate eingesetzt werden. Sobald die Verbindung zum Client besteht, verifiziert der Server, ob der Client die Berechtigungen für die jeweils ausgeführten Abfragen besitzt (z.B., ob es dem Client erlaubt ist, eine SELECT-Anweisung auszuführen, die auf die Country-Tabelle in der Datenbank world zugreift). Wir behandeln diese Themen detailliert in Kapitel 12.

Optimierung und Ausführung MySQL analysiert Abfragen, um eine interne Struktur zu erzeugen (den Parse- oder Syntaxbaum), und führt dann eine Reihe von Optimierungen durch. Dazu können das Umschreiben der Abfrage, das Feststellen der Reihenfolge, in der die Tabellen gelesen werden, das Auswählen der zu verwendenden Indizes usw. gehören. Über spezielle Schlüsselwörter in der Abfrage können Sie Hinweise an den Optimierer übergeben, die die Entscheidungsfindung beeinflussen. Darüber hinaus können Sie den Server auffordern, verschiedene Aspekte der Optimierung zu erklären. Auf diese Weise erfahren Sie, welche Entscheidungen der Server trifft. Sie erhalten also einen Anhaltspunkt zum Überarbeiten von Abfragen, Schemata und Einstellungen, damit Sie alles so effizient wie möglich gestalten können. Auf den Optimierer gehen wir in Kapitel 4 ausführlicher ein. Dem Optimierer ist es im Prinzip egal, welche Storage-Engine eine bestimmte Tabelle verwendet, die Storage-Engine hingegen beeinflusst, wie der Server die Abfrage optimiert. Der Optimierer fragt die Storage-Engine nach einigen ihrer Fähigkeiten und den Kosten für bestimmte Operationen sowie nach Statistiken über die Tabellendaten. Einige Storage-Engines unterstützen z.B. Indextypen, die für bestimmte Abfragen hilfreich sein können. Mehr Informationen über Indizierung und Schema-Optimierung erhalten Sie in Kapitel 3. Bevor allerdings die Abfrage geparst wird, schaut der Server im Abfrage-Cache nach, der nur SELECT-Anweisungen sowie deren Ergebnissätze speichern kann. Wenn jemand eine Abfrage ausführt, die identisch ist mit einer, die sich bereits im Cache befindet, dann muss der Server diese Abfrage nicht parsen, optimieren oder ausführen – er kann einfach den gespeicherten Ergebnissatz zurückliefern! Wir besprechen den Abfrage-Cache ausführlich in »Der MySQL-Abfrage-Cache« auf Seite 220. 2 MySQL AB plant, in künftigen Versionen des Servers Verbindungen von Threads zu trennen.

Die logische Architektur von MySQL | 3

Nebenläufigkeitskontrolle Immer wenn zu einem Zeitpunkt mehr als eine Abfrage Daten ändern muss, tritt das Problem der Nebenläufigkeitskontrolle (Concurrency Control) auf. Für unsere Zwecke in diesem Kapitel muss MySQL auf zwei Ebenen aktiv werden: auf der Serverebene und auf der Ebene der Storage-Engine. Dem großen Thema der Nebenläufigkeitskontrolle widmet sich ein Großteil der theoretischen Literatur. Dieses Buch allerdings befasst sich nicht mit der Theorie oder gar mit den Interna von MySQL. Daher geben wir Ihnen nur einen vereinfachten Überblick darüber, wie MySQL mit nebenläufigen Lese- und Schreibvorgängen umgeht, damit Sie die nötigen Informationen für den Rest dieses Kapitels haben. Wir benutzen eine Mailbox auf einem Unix-System als Beispiel. Das klassische mboxDateiformat ist sehr einfach. Alle Nachrichten in einer mbox-Mailbox werden eine nach der anderen aneinandergefügt. Das macht es sehr einfach, E-Mail-Nachrichten zu lesen und zu verarbeiten. Außerdem vereinfacht es die Auslieferung der E-Mails: Eine neue Nachricht wird einfach an das Ende der Datei angehängt. Was geschieht jedoch, wenn zwei Prozesse versuchen, etwas zur gleichen Zeit an die gleiche Mailbox auszuliefern? Natürlich kann das die Mailbox beschädigen und zwei ineinander vermischte Nachrichten am Ende der Mailbox-Datei hinterlassen. Anständige Systeme zur Mail-Auslieferung setzen Sperren (Locks) ein, um eine Beschädigung zu vermeiden. Versucht ein Client eine zweite Auslieferung, während die Mailbox gesperrt ist, muss er warten, bis er den Lock erhalten hat, bevor er die Nachricht zustellen kann. Dieses Schema funktioniert in der Praxis recht gut, bietet aber keine Unterstützung für Nebenläufigkeit. Da zu einem Zeitpunkt nur ein einziger Prozess die Mailbox ändern darf, wirft dieser Ansatz bei einer stark genutzten Mailbox Probleme auf.

Lese/Schreib-Locks Das Lesen aus der Mailbox ist nicht ganz so problematisch. Es gibt keine Schwierigkeiten, wenn mehrere Clients gleichzeitig die gleiche Mailbox auslesen. Da sie keine Änderungen vornehmen, kann eigentlich auch nichts schiefgehen. Was passiert aber, wenn jemand versucht, Nachricht Nummer 25 zu löschen, während andere Programme die Mailbox auslesen? Es kommt drauf an. Ein Leser könnte eine beschädigte oder inkonsistente Ansicht der Mailbox erhalten. Um sicherzugehen, verlangt sogar das Lesen aus einer Mailbox besondere Sorgfalt. Wenn Sie sich die Mailbox als Datenbanktabelle und jede Nachricht als eine Zeile vorstellen, dann werden Sie leicht merken, dass das Problem in diesem Kontext das gleiche ist. In vielerlei Hinsicht ist eine Mailbox nur eine einfache Datenbanktabelle. Das Modifizieren von Zeilen (bzw. Datensätzen) in einer Datenbanktabelle ist dem Löschen oder Ändern von Nachrichten in einer Mailbox-Datei sehr ähnlich. Die Lösung dieses klassischen Problems der Nebenläufigkeitskontrolle ist recht einfach. Systeme, die einen nebenläufigen, d.h. parallel erfolgenden Lese-/Schreibzugriff erlau-

4 | Kapitel 1: Die MySQL-Architektur

ben, implementieren typischerweise ein Locking-System, das zwei Arten von Sperren unterstützt. Diese Sperren oder Locks sind üblicherweise als Shared Locks und Exklusive Locks oder als Lese-Locks und Schreib-Locks bekannt. Ohne uns um die eigentliche Locking-Technik zu kümmern, können wir das Konzept folgendermaßen beschreiben. Die Lese-Locks (Read Locks) für eine Ressource werden gemeinsam genutzt (engl. Shared): Viele Clients können die Ressource gleichzeitig lesen und stören einander nicht. Schreib-Locks dagegen sind exklusiv – d.h., sie blockieren sowohl Lese-Locks als auch andere Schreib-Locks –, da die einzig sichere Methode darin besteht, zu einem Zeitpunkt nur einen einzigen Client auf die Ressource schreiben zu lassen und alle Lesevorgänge zu verhindern, wenn ein Client schreibt. In der Datenbankwelt kommt das Locking ständig vor: MySQL muss verhindern, dass ein Client einen Teil der Daten liest, während ihn ein anderer Client ändert. Es führt dieses Lock-Management intern auf eine Art und Weise aus, die größtenteils transparent ist.

Locking-Granularität Eine Möglichkeit, die Nebenläufigkeit einer gemeinsam genutzten Ressource zu verbessern, besteht darin, bei der Wahl dessen, was gesperrt wird, selektiver zu sein. Anstatt die gesamte Ressource zu sperren, könnten Sie nur den Teil sperren, der die zu ändernden Daten enthält. Oder noch besser: Sperren Sie genau den Teil der Daten, der geändert werden soll. Indem Sie die Menge der zu sperrenden Daten einschränken, können mehr Änderungen gleichzeitig erfolgen – solange sie sich untereinander nicht überschneiden. Problematisch ist allerdings, dass die Locks Ressourcen beanspruchen. Jede Lock-Operation – das Erstellen eines Locks, die Prüfung, ob ein Lock frei ist, das Freigeben eines Locks usw. – erfordert einen gewissen Aufwand. Wenn das System zu viel Zeit damit verbringt, die Locks zu verwalten, anstatt Daten zu speichern und abzurufen, leidet möglicherweise die Performance. Eine Locking-Strategie stellt immer einen Kompromiss aus Locking-Overhead und Datensicherheit dar; dieser Kompromiss beeinflusst schließlich die Performance. Die meisten kommerziellen Datenbankserver lassen Ihnen kaum eine Wahl: Sie können für Ihre Tabellen das sogenannte Row-Level Locking einsetzen, also das Locking auf Datensatzebene, bei dem Ihnen eine Vielzahl von oftmals komplexen Methoden zur Verfügung steht, um eine gute Performance mit vielen Locks zu erreichen. Bei MySQL haben Sie dagegen die Wahl. Seine Storage-Engines können eigene LockingRichtlinien und -Granularitäten implementieren. Die Locking-Verwaltung bildet eine wichtige Entscheidung beim Entwurf der Storage-Engine; das Festlegen der Granularität auf einer bestimmten Stufe kann für verschiedene Anwendungszwecke eine bessere Performance gewährleisten, die Engine jedoch für andere Fälle weniger gut geeignet erscheinen lassen. Da MySQL mehrere Storage-Engines bietet, ist es nicht nötig, sich auf eine einzige, allumfassende Lösung zu beschränken. Schauen wir uns die beiden wichtigsten Locking-Strategien an.

Nebenläufigkeitskontrolle | 5

Tabellen-Locks Die grundlegendste und mit dem geringsten Overhead verbundene Locking-Strategie in MySQL ist der Tabellen-Lock. Er entspricht dem bereits beschriebenen Mailbox-Locking: Er sperrt die gesamte Tabelle. Möchte ein Client etwas in die Tabelle schreiben (einfügen, löschen, aktualisieren usw.), beschafft er sich einen Schreib-Lock, der alle anderen Leseund Schreiboperationen in Schach hält. Wenn niemand schreibt, können lesende Prozesse Lese-Locks anfordern, die anderen Lese-Locks nicht in die Quere kommen. Tabellen-Locks bieten Variationen, um unter bestimmten Bedingungen eine gute Performance zu gewährleisten. Beispielsweise erlauben READ LOCAL-Tabellen-Locks einige Arten von nebenläufigen, d.h. parallel erfolgenden Schreiboperationen. Schreib-Locks besitzen außerdem eine höhere Priorität als Lese-Locks, so dass die Anforderung eines SchreibLocks an den Anfang der Locking-Warteschlange rückt, auch wenn sich bereits lesende Prozesse in der Warteschlange befinden (Schreib-Locks können in der Warteschlange an Lese-Locks vorbeiziehen, Lese-Locks dagegen können Schreib-Locks nicht überholen). Storage-Engines können zwar ihre eigenen Locks verwalten, dennoch verwendet auch MySQL eine Vielzahl von Locks für verschiedene Zwecke, bei denen es sich prinzipiell um Tabellen-Locks handelt. So setzt etwa der Server ungeachtet der Storage-Engine einen Tabellen-Lock für Anweisungen wie ALTER TABLE ein.

Row-Locks Die Form des Lockings, die die größtmögliche Nebenläufigkeit ermöglicht (und den meisten Overhead mitschleppt) ist das zeilenorientierte oder Row-Locking. Row-Locking gibt es unter anderem in den InnoDB- und Falcon-Storage-Engines. Row-Locks werden in der Storage-Engine implementiert, nicht im Server (werfen Sie einfach noch einmal einen Blick auf die Darstellung der logischen Architektur). Der Server ist völlig ahnungslos, was Locks betrifft, die in den Storage-Engines implementiert sind. Wie Sie später noch erfahren werden, implementieren die Storage-Engines das Locking alle auf ihre eigene Weise.

Transaktionen Es ist kaum möglich, sich mit den erweiterten Funktionen eines Datenbanksystems zu befassen, ohne auf Transaktionen zu stoßen. Eine Transaktion ist eine Gruppe von SQLAbfragen, die als atomar betrachtet werden, d.h. als zusammengehörende Einheit. Entweder wird die gesamte Gruppe der Abfragen von der Datenbank-Engine auf die Datenbank angewandt oder keine (z.B. aufgrund eines Absturzes oder aus einem anderen Grund). Hier gilt: alles oder nichts! Nur ein kleiner Teil dieses Abschnitts ist MySQL-spezifisch. Wenn Sie bereits mit ACIDTransaktionen vertraut sind, können Sie direkt mit »Transaktionen bei MySQL« auf Seite 11 fortfahren. Eine Bankanwendung ist das klassische Beispiel dafür, weshalb Transaktionen notwendig sind. Stellen Sie sich vor, die Datenbank der Bank würde aus zwei Tabellen bestehen:

6 | Kapitel 1: Die MySQL-Architektur

Girokonto und Sparkonto. Um 200 € von Karlas Girokonto auf ihr Sparkonto zu überwei-

sen, sind mindestens drei Schritte notwendig: 1. Sicherstellen, dass ihr Guthaben auf dem Girokonto mehr als 200 € aufweist 2. 200 € vom Girokonto abziehen 3. 200 € dem Sparkonto gutschreiben

Die gesamte Operation muss in einer Transaktion zusammengefasst werden, damit sie als Ganzes zurückgenommen werden kann, falls einer der Schritte fehlschlägt. Eine Transaktion wird mit der Anweisung START TRANSACTION gestartet und dann mit COMMIT bestätigt und gespeichert oder mit ROLLBACK zurückgenommen. Der SQL-Code für die Beispieltransaktion könnte so aussehen: 1 2 3 4 5

START TRANSACTION; SELECT balance FROM checking WHERE customer_id = 10233276; UPDATE checking SET balance = balance - 200.00 WHERE customer_id = 10233276; UPDATE savings SET balance = balance + 200.00 WHERE customer_id = 10233276; COMMIT;

Transaktionen allein reichen aber nicht aus. Was passiert, wenn der Datenbankserver abstürzt, während er gerade Zeile 4 ausführt? Wer weiß? Die Kundin hat wahrscheinlich gerade 200 € verloren. Und was passiert, wenn ein anderer Prozess zwischen den Zeilen 3 und 4 einfach das ganze Girokonto löscht? Die Bank hätte der Kundin einen Kredit von 200 € gewährt, ohne es überhaupt zu wissen. Transaktionen reichen nicht aus, wenn das System nicht den sogenannten ACID-Test besteht. ACID ist ein Akronym für »Atomicity, Consistency, Isolation, Durability«, also Atomarität, Konsistenz, Isolation, Dauerhaftigkeit, vier eng miteinander verknüpften Kriterien, die ein gut funktionierendes Transaktionsverarbeitungssystem erfüllen muss: Atomicity (Atomarität) Eine Transaktion muss als eine einzelne, nicht teilbare Arbeitseinheit ausgeführt werden: Entweder wird die gesamte Transaktion angewandt, oder sie wird komplett zurückgenommen. Wenn Transaktionen atomar sind, dann gibt es keine teilweise abgeschlossene Transaktion. Das Prinzip heißt: alles oder nichts. Consistency (Konsistenz) Die Datenbank muss sich immer von einem konsistenten Zustand in den nächsten bewegen. In unserem Beispiel sorgt die Konsistenz dafür, dass ein Absturz zwischen den Zeilen 3 und 4 nicht dazu führt, dass 200 € vom Girokonto verschwinden. Da die Transaktion niemals bestätigt wird (COMMIT), spiegelt sich keine der an der Datenbank durchgeführten Änderungen in der Datenbank wider. Isolation Die Ergebnisse einer Transaktion sind üblicherweise für andere Transaktionen unsichtbar, bis die Transaktion abgeschlossen ist. Das stellt in unserem Fall sicher, dass bei der Erstellung einer Kontoübersicht nach Zeile 3, aber vor Zeile 4 die 200 € immer noch auf dem Girokonto zu sehen sind. Wenn wir die verschiedenen Isolationsebenen besprechen, werden Sie verstehen, weshalb wir üblicherweise sagen.

Transaktionen | 7

Durability (Dauerhaftigkeit) Einmal mit COMMIT bestätigt, werden die Ergebnisse der Transaktion dauerhaft gespeichert. Das bedeutet, dass die Änderungen in einer Art festgehalten werden müssen, die dafür sorgt, dass die Daten bei einem Systemabsturz nicht verlorengehen. Das Konzept der Dauerhaftigkeit ist allerdings etwas unscharf, da es tatsächlich viele Stufen gibt. Manche Dauerhaftigkeitsstrategien bieten eine stärkere Sicherheitsgarantie als andere, und nichts ist wirklich hundertprozentig von Dauer. Wir werden später darauf eingehen, was Dauerhaftigkeit in MySQL wirklich bedeutet. Freuen Sie sich speziell auf »InnoDB-Ein-/Ausgabe-Tuning« auf Seite 306. ACID-Transaktionen sorgen dafür, dass die Banken Ihr Geld nicht verlieren. Es ist im Allgemeinen ausgesprochen schwierig, wenn nicht gar unmöglich, dies mit der Anwendungslogik zu erreichen. Ein ACID-konformer Datenbankserver muss alle möglichen komplizierten Dinge tun, die Sie möglicherweise gar nicht mitbekommen, um ACIDGarantien zu gewährleisten. Genau wie bei der erhöhten Locking-Granularität besteht der Nachteil dieser zusätzlichen Sicherheit darin, dass der Datenbankserver mehr Arbeit erledigen muss. Das bedeutet auch, dass ein Datenbankserver mit ACID-Transaktionen im Allgemeinen mehr CPULeistung, Speicher und Plattenplatz benötigt als ohne. Wie wir bereits mehrfach ausgeführt haben, spielt hier die Storage-Engine-Architektur von MySQL ihre Vorteile aus. Sie können selbst entscheiden, ob Ihre Anwendung Transaktionen benötigt. Wenn Sie sie nicht brauchen, können Sie bei einigen Arten von Abfragen eine höhere Leistung erreichen, wenn Sie eine Storage-Engine verwenden, die keine Transaktionen bietet. Sie könnten sogar LOCK TABLES einsetzen, um auch ohne Transaktionen die notwendige Sicherheit zu erhalten. Es liegt ganz bei Ihnen.

Isolationsebenen Isolation ist komplexer, als es auf den ersten Blick erscheinen mag. Der SQL-Standard definiert vier Isolationsebenen mit speziellen Regeln dafür, welche Änderungen innerhalb und außerhalb einer Transaktion sichtbar sind oder nicht. Niedrigere Isolationsebenen erlauben typischerweise eine stärkere Nebenläufigkeit und bringen einen geringeren Overhead mit sich. Jede Storage-Engine implementiert die Isolationsebenen etwas anders, und möglicherweise entspricht die Umsetzung nicht dem, was Sie erwarten würden, wenn Sie mit einem anderen Datenbankprodukt vertraut sind (wir werden deshalb in diesem Abschnitt nicht auf jedes einzelne Detail eingehen). Lesen Sie einfach das Handbuch der Storage-Engine, für die Sie sich letztendlich entschieden haben.

8 | Kapitel 1: Die MySQL-Architektur

Schauen wir uns die vier Isolationsebenen an: READ UNCOMMITTED

Auf der Isolationsebene READ UNCOMMITTED können Transaktionen die Ergebnisse noch nicht bestätigter Transaktionen sehen. Auf dieser Ebene können sehr viele Probleme auftreten, wenn Sie nicht ganz genau wissen, was Sie tun, und keinen guten Grund haben, es zu tun. In der Praxis wird diese Ebene selten genutzt, da ihre Performance kaum besser ist als die der anderen Ebenen, die wiederum viele Vorteile bieten. Das Lesen unbestätigter Daten wird auch als Dirty Read bezeichnet. READ COMMITTED

Die Standardisolationsebene der meisten Datenbanksysteme (aber nicht von MySQL!) ist READ COMMITTED. Sie entspricht der einfachen Definition der Isolation, die wir vorhin verwendet haben: Eine Transaktion sieht nur die Ergebnisse von Transaktionen, die bereits bestätigt waren, als sie begann. Ihre Änderungen wiederum werden erst sichtbar, nachdem sie bestätigt wurde. Auf dieser Ebene ist immer noch ein sogenannter Nonrepeatable Read (eine nicht wiederholbare Leseoperation) erlaubt. Dies bedeutet, dass Sie eine Anweisung zweimal ausführen können und unterschiedliche Daten zu sehen bekommen. REPEATABLE READ REPEATABLE READ löst die Probleme, die READ UNCOMMITTED zulässt. Diese Ebene garan-

tiert, dass alle Zeilen, die eine Transaktion liest, bei nachfolgenden Lesevorgängen innerhalb der gleichen Transaktion »gleich aussehen«. Theoretisch kann aber immer noch ein anderes schwerwiegendes Problem auftreten, nämlich das der PhantomReads. Vereinfacht gesagt, kann ein Phantom-Read auftreten, wenn Sie einen Bereich von Zeilen auswählen, eine andere Transaktion eine neue Zeile in diesen Bereich einfügt und Sie diesen Bereich erneut auswählen. Sie sehen dann diese neue »Phantom«-Zeile. InnoDB und Falcon lösen das Phantom-Read-Problem mithilfe der Multi-Version Concurrency Control, die wir weiter hinten in diesem Kapitel erklären. REPEATABLE READ ist die Standardisolationsebene von MySQL. Die Storage-Engines

InnoDB und Falcon respektieren diese Einstellung; Sie lernen in Kapitel 6, wie Sie sie ändern. Einige andere Engines beachten sie ebenfalls, das hängt aber von der Engine ab. SERIALIZABLE

Die höchste Isolationsebene, SERIALIZABLE, löst das Phantom-Read-Problem, indem die Transaktionen so angeordnet werden, dass sie sich nicht stören können. SERIALIZABLE setzt quasi auf jede Zeile, die es liest, eine Sperre. Auf dieser Ebene kann es zu vielen Timeouts und Kämpfen um einen Lock kommen. Wir kennen kaum Leute, die diese Isolationsebene benutzen, allerdings könnten die Anforderungen Ihrer Anwendung es notwendig machen, die verringerte Performance in Kauf zu nehmen, um die damit verbundene Datenstabilität zu erreichen. Tabelle 1-1 fasst die verschiedenen Isolationsebenen und die mit ihnen verbundenen Nachteile zusammen.

Transaktionen | 9

Tabelle 1-1: ANSI SQL-Isolationsebenen Isolationsebene

Dirty Reads möglich

Nonrepeatable Reads möglich

Phantom-Reads möglich

Locking-Reads

READ UNCOMMITTED

Ja

Ja

Ja

Nein

READ COMMITTED

Nein

Ja

Ja

Nein

REPEATABLE READ

Nein

Nein

Ja

Nein

SERIALIZABLE

Nein

Nein

Nein

Ja

Deadlocks Ein Deadlock tritt auf, wenn zwei oder mehr Transaktionen wechselseitig Locks auf denselben Ressourcen anfordern und halten und dadurch einen Kreis von Abhängigkeiten schaffen. Es kommt zu Deadlocks, wenn Transaktionen versuchen, Ressourcen in unterschiedlicher Reihenfolge zu sperren. Sie können auftreten, wenn mehrere Transaktionen die gleichen Ressourcen sperren. Nehmen wir als Beispiel diese beiden Transaktionen, die über die StockPrice-Tabelle laufen sollen: Transaktion #1 START TRANSACTION; UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = '2002-05-01'; UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = '2002-05-02'; COMMIT;

Transaktion #2 START TRANSACTION; UPDATE StockPrice SET high UPDATE StockPrice SET high COMMIT;

= 20.12 WHERE stock_id = 3 and date = '2002-05-02'; = 47.20 WHERE stock_id = 4 and date = '2002-05-01';

Wenn Sie Pech haben, führt jede Transaktion die erste Anweisung aus und aktualisiert eine Datenzeile, wodurch diese in dem Prozess gesperrt wird. Beide Transaktionen versuchen dann, ihre zweite Zeile zu aktualisieren, wobei sie dann feststellen, dass diese bereits gesperrt ist. Die beiden Transaktionen warten nun bis in alle Ewigkeit darauf, dass die jeweils andere fertig wird – es sei denn, jemand schreitet ein und löst diesen Deadlock auf. Um dieses Problem zu lösen, implementieren Datenbanksysteme verschiedene Formen von Deadlock-Erkennung und Timeouts. Die schlaueren Systeme, wie etwa die InnoDBStorage-Engine, erkennen zyklische Abhängigkeiten und geben einen Fehler zurück. Das ist in der Tat sehr gut, da sich Deadlocks ansonsten in ausgesprochen langsam ablaufenden Abfragen äußern würden. Andere geben nach einer gewissen Zeit auf, wenn sie keinen Lock erhalten haben, was wiederum nicht so gut ist. Der Umgang von InnoDB mit Deadlocks sieht momentan so aus, dass es diejenige Transaktion rückgängig macht, die die wenigsten exklusiven Row-Locks besitzt (ein ungefähres Maß, für das es am einfachsten ist, es rückgängig zu machen).

10 |

Kapitel 1: Die MySQL-Architektur

Das Verhalten und die Reihenfolge von Locks hängen von der jeweiligen Storage-Engine ab. Einige Storage-Engines landen möglicherweise bei einer bestimmten Abfolge von Anweisungen in einem Deadlock, während andere dies nicht tun. Deadlocks haben eine Doppelnatur: Manche sind aufgrund echter Datenkonflikte unvermeidlich, während andere aufgrund der Funktionsweise einer Storage-Engine entstehen. Deadlocks können nicht unterbrochen werden, ohne eine der Transaktionen, entweder teilweise oder vollständig, zu widerrufen. Sie gehören zu Transaktionssystemen einfach dazu. Ihre Anwendungen müssen daher in der Lage sein, mit ihnen zurechtzukommen. Viele Anwendungen können einfach ihre Transaktionen wiederholen.

Transaktions-Log Mit einer Protokollierung der Transaktionen (Transaktions-Logging) können Transaktionen effizienter gestaltet werden. Anstatt die Tabellen auf der Festplatte nach jeder Änderung zu aktualisieren, kann die Storage-Engine die im Speicher befindliche Kopie der Daten ändern. Das geht sehr schnell. Die Storage-Engine schreibt dann einen Eintrag für die Änderung in das Transaktions-Log, das sich auf der Festplatte befindet und daher dauerhaft ist. Auch dies ist eine relativ schnelle Operation, da das Anhängen von LogEreignissen anstelle der zufälligen Ein-/Ausgabe an vielen Stellen nur eine sequenzielle Ein-/Ausgabe auf einem sehr kleinen Bereich der Festplatte umfasst. Zu einem späteren Zeitpunkt kann ein Prozess dann die Tabelle auf der Festplatte aktualisieren. Die meisten Storage-Engines, die diese (auch als Write-Ahead Logging bezeichnete) Technik einsetzen, müssen daher Änderungen zweimal auf die Festplatte schreiben.3 Kommt es zu einem Absturz, nachdem die Aktualisierung in das Transaktions-Log geschrieben wurde, aber bevor die Änderungen an den Daten selbst vorgenommen wurden, kann die Storage-Engine die Änderungen nach einem Neustart wiederherstellen. Die Wiederherstellungsmethode hängt von der jeweiligen Storage-Engine ab.

Transaktionen bei MySQL MySQL AB stellt drei transaktionsfähige Storage-Engines bereit: InnoDB, NDB Cluster und Falcon. Es gibt außerdem verschiedene Engines von Drittanbietern; die momentan bekanntesten Engines sind solidDB und PBXT. Im nächsten Abschnitt stellen wir spezielle Eigenschaften der einzelnen Engines vor.

AUTOCOMMIT MySQL arbeitet per Voreinstellung im AUTOCOMMIT-Modus. Das bedeutet, dass jede Abfrage als separate Transaktion ausgeführt wird, solange Sie nicht ausdrücklich eine Transaktion begonnen haben. Sie können AUTOCOMMIT für die aktuelle Verbindung aktivieren oder deaktivieren, indem Sie eine Variable setzen: 3 Die PBXT-Storage-Engine vermeidet clevererweise das Write-Ahead Logging.

Transaktionen |

11

mysql> SHOW VARIABLES LIKE 'AUTOCOMMIT'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | autocommit | ON | +---------------+-------+ 1 row in set (0.00 sec) mysql> SET AUTOCOMMIT = 1;

Die Werte 1 und ON sind äquivalent, genau wie 0 und OFF. Wenn Sie mit AUTOCOMMIT=0 arbeiten, sind Sie immer in einer Transaktion, bis Sie COMMIT oder ROLLBACK ausführen. MySQL startet dann sofort eine neue Transaktion. Das Ändern des Wertes von AUTOCOMMIT hat keine Wirkung auf nichttransaktionsfähige Tabellen wie MyISAM- oder Memory-Tabellen, die prinzipiell immer im AUTOCOMMIT-Modus arbeiten. Werden bestimmte Befehle während einer offenen Transaktion aufgerufen, dann veranlassen sie MySQL, die Transaktion zu bestätigen, bevor sie ausgeführt werden. Bei diesen Befehlen handelt es sich typischerweise um DDL-Befehle (Data Definition Language), die wesentliche Änderungen verursachen können, wie etwa ALTER TABLE. Aber auch LOCK TABLES und einige andere Anweisungen haben diese Wirkung. In der Dokumentation Ihrer Version finden Sie eine vollständige Liste der Befehle, die automatisch eine Transaktion bestätigen. MySQL erlaubt es Ihnen, mit dem Befehl SET TRANSACTION ISOLATION LEVEL die Isolationsebene festzulegen, die wirksam wird, wenn die nächste Transaktion beginnt. Sie können die Isolationsebene für den gesamten Server in der Konfigurationsdatei festlegen (siehe Kapitel 6) oder sich auf die aktuelle Sitzung beschränken: mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

MySQL erkennt alle vier Standard-ANSI-Isolationsebenen, InnoDB unterstützt sie alle. Andere Storage-Engines bieten unterschiedliche Unterstützung für die verschiedenen Isolationsebenen.

Storage-Engines in Transaktionen mischen Bei MySQL werden die Transaktionen nicht vom Server verwaltet; stattdessen implementieren die zugrunde liegenden Storage-Engines die Transaktionen selbst. Aus diesem Grund ist es nicht möglich, unterschiedliche Engines in einer einzigen Transaktion zu mischen. Bei MySQL AB arbeitet man daran, den Server um eine Transaktionsverwaltung auf höherer Ebene zu erweitern, wodurch es möglich werden wird, transaktionsfähige Tabellen in einer Transaktion zu mischen und zu vergleichen. Bis es so weit ist, müssen Sie vorsichtig sein. Wenn Sie transaktionsfähige und nichttransaktionsfähige Tabellen (z.B. InnoDB- und MyISAM-Tabellen) in einer Transaktion mischen, funktioniert die Transaktion (wenn alles gut geht). Wird jedoch ein Rollback erforderlich, dann können die Änderungen an der nichttransaktionsfähigen Tabelle nicht zurückgenommen werden. Die Datenbank verbleibt in einem inkonsistenten Zustand, der nur schwer wieder ausgeglichen werden

12 |

Kapitel 1: Die MySQL-Architektur

kann und die ganze Idee einer Transaktion ad absurdum führt. Daher ist es enorm wichtig, die richtige Storage-Engine für eine Tabelle zu wählen. Normalerweise warnt MySQL Sie nicht, wenn Sie transaktionsfähige Operationen auf einer nichttransaktionsfähigen Tabelle durchführen. Gelegentlich generiert die Zurücknahme einer Transaktion die Warnung »Some nontransactional changed tables couldn’t be rolled back«, meist allerdings gibt es kein Anzeichen dafür, dass Sie mit nichttransaktionsfähigen Tabellen arbeiten.

Implizites und explizites Locking InnoDB verwendet ein zweiphasiges Locking-Protokoll. Es kann sich jederzeit während einer Transaktion Locks beschaffen, gibt sie aber erst bei einem COMMIT oder ROLLBACK wieder frei. Alle Locks werden gleichzeitig freigegeben. Die früher beschriebenen LockingMechanismen sind alle implizit. InnoDB behandelt die Locks automatisch entsprechend Ihrer Isolationsebene. Allerdings unterstützt InnoDB auch explizites Locking, das vom SQL-Standard nicht einmal erwähnt wird: • SELECT ... LOCK IN SHARE MODE • SELECT ... FOR UPDATE MySQL unterstützt auch die Befehle LOCK TABLES und UNLOCK TABLES, die im Server und nicht in den Storage-Engines implementiert sind. Es gibt für sie Anwendungsfälle, allerdings stellen sie keinen Ersatz für Transaktionen dar. Wenn Sie Transaktionen benötigen, dann verwenden Sie eine transaktionsfähige Storage-Engine. Wir haben es oft mit Anwendungen zu tun, die von MyISAM nach InnoDB konvertiert wurden, aber weiterhin LOCK TABLES benutzen. Dies ist aufgrund des Row-Level-Locking nicht mehr notwendig und kann schwerwiegende Performance-Probleme verursachen. Die Interaktion zwischen LOCK TABLES und Transaktionen ist komplex, und es kann in manchen Serverversionen zu unerwarteten Verhaltensweisen kommen. Wir empfehlen daher, dass Sie – egal, welche Storage-Engine Sie verwenden – von der Verwendung von LOCK TABLES absehen, es sei denn, Sie sind in einer Transaktion, und AUTOCOMMIT ist deaktiviert.

Multi-Version Concurrency Control Die meisten der transaktionsfähigen Storage-Engines von MySQL, wie etwa InnoDB, Falcon und PBXT, verwenden keinen einfachen Row-Locking-Mechanismus, sondern benutzen Row-Level-Locking zusammen mit einer Technik zur Erhöhung der Nebenläufigkeit namens Multi-Version Concurrency Control (MVCC). MVCC ist nicht auf MySQL beschränkt, auch Oracle, PostgreSQL und einige andere Datenbanksysteme setzen es ein.

Multi-Version Concurrency Control |

13

Sie können sich MVCC als eine neue Variante des Row-Level-Lockings vorstellen. Sie müssen in vielen Fällen überhaupt nicht sperren und haben einen geringeren Overhead. Je nach seiner Implementierung erlaubt es nichtsperrende Leseoperationen und sperrt während der Schreiboperationen nur die notwendigen Datensätze. MVCC behält einen Schnappschuss der Daten von einem ganz bestimmten Zeitpunkt. Das bedeutet, dass Transaktionen eine konsistente Sicht der Daten sehen, unabhängig davon, wie lange ihre Ausführung dauert. Es bedeutet aber auch, dass unterschiedliche Transaktionen zur gleichen Zeit unterschiedliche Daten in den gleichen Tabellen sehen können! Wenn Sie das noch nie zuvor erlebt haben, mag es zunächst verwirrend sein, mit der Zeit aber werden Sie es immer besser verstehen. Jede Storage-Engine implementiert MVCC anders. Zu den Varianten gehören optimistische und pessimistische Concurrency Control. Wir werden eine Möglichkeit der Funktion von MVCC anhand einer vereinfachten Version des Verhaltens von InnoDB erläutern. InnoDB implementiert MVCC, indem es für jede Zeile zwei zusätzliche verborgene Werte speichert, die aufzeichnen, wann diese Zeile erzeugt wurde und wann sie verfällt (oder gelöscht wurde). Anstatt die tatsächlichen Zeiten festzuhalten, an denen diese Ereignisse eingetreten sind, speichert die Zeile die Systemversionsnummer zum Zeitpunkt des Ereignisses. Dabei handelt es sich um eine Zahl, die immer dann erhöht wird, wenn eine Transaktion beginnt. Jede Transaktion besitzt ab dem Zeitpunkt, zu dem sie begann, einen eigenen Datensatz mit der aktuellen Systemversion. Alle Abfragen müssen die Versionsnummern der Zeilen anhand der Version der Transaktion überprüfen. Wir wollen uns anschauen, wie das bei bestimmten Operationen funktioniert, wenn die Isolationsebene auf REPEATABLE READ gesetzt ist: SELECT

InnoDB muss jede Zeile untersuchen, um sicherzustellen, dass sie zwei Kriterien erfüllt: • InnoDB muss eine Version der Zeile finden, die mindestens so alt ist wie die Transaktion (d.h., ihre Version muss kleiner oder gleich der Version der Transaktion sein). Dies stellt sicher, dass die Zeile entweder bereits existierte, als die Transaktion begann, oder dass die Transaktion die Zeile erzeugte bzw. veränderte. • Die Löschversionsnummer (Deletion-ID) der Zeile muss undefiniert oder größer sein als die Version der Transaktion. Dies stellt sicher, dass die Zeile nicht gelöscht war, bevor die Transaktion begann. Zeilen, die beide Tests bestehen, können als Ergebnis der Abfrage zurückgeliefert werden. INSERT

InnoDB zeichnet die aktuelle Systemversionsnummer in der neuen Zeile auf. DELETE

InnoDB zeichnet die aktuelle Systemversionsnummer als Deletion-ID der Zeile auf.

14 |

Kapitel 1: Die MySQL-Architektur

UPDATE

InnoDB schreibt eine neue Kopie der Zeile und verwendet dabei die Systemversionsnummer für die Version der neuen Zeile. Außerdem schreibt es die Systemversionsnummer als Deletion-ID der alten Zeile. Das Ergebnis dieses zusätzlichen Aufwands besteht darin, dass die meisten lesenden Abfragen niemals Locks anfordern. Sie lesen die Daten ganz einfach so schnell sie können, wobei sie aber nur Zeilen auswählen, die den Kriterien entsprechen. Nachteilig ist allerdings, dass die Storage-Engine in den einzelnen Zeilen mehr Daten speichern muss, mehr Aufwand beim Untersuchen der Zeilen hat und mehr Verwaltungsoperationen durchführen muss. MVCC funktioniert nur mit den Isolationsebenen REPEATABLE READ und READ COMMITTED. READ UNCOMMITTED ist nicht MVCC-kompatibel, da die Abfragen nicht die Zeilenversion lesen, die ihrer Transaktionsversion entspricht; sie lesen einfach immer die neueste Version. SERIALIZABLE ist nicht MVCC-kompatibel, weil Leseoperationen jede Zeile sperren, die sie zurückliefern. In Tabelle 1-2 sind die verschiedenen Locking-Modelle und Concurrency-Ebenen in MySQL noch einmal zusammengefasst. Tabelle 1-2: Locking-Modelle und Concurrency in MySQL bei der Standardisolationsebene Locking-Strategie

Concurrency

Overhead

Engines

Tabellenorientiert

Niedrigste

Niedrigster

MyISAM, Merge, Memory

Zeilenorientiert

Hoch

Hoch

NDB Cluster

Zeilenorientiert mit MVCC

Höchste

Höchster

InnoDB, Falcon, PBXT, solidDB

Die Storage-Engines von MySQL In diesem Abschnitt erhalten Sie einen Überblick über die Storage-Engines von MySQL. Wir werden hier nicht allzu sehr ins Detail gehen, da wir die Storage-Engines und ihre speziellen Verhaltensweisen im Laufe des Buches noch genauer erläutern. Allerdings ist selbst dieses Buch keine komplette Dokumentation; Sie müssen daher unbedingt die MySQL-Handbücher für die Storage-Engines lesen, für die Sie sich entschieden haben. MySQL bietet darüber hinaus Foren für die einzelnen Storage-Engines, in denen Sie oft auch Links auf weiterführende Informationen und interessante Einsatzgebiete finden. Falls Sie die Engines nur grob miteinander vergleichen wollen, können Sie sich gleich zu Tabelle 1-3 auf Seite 32 begeben. MySQL speichert jede Datenbank (auch als Schema bezeichnet) als Unterverzeichnis seines Datenverzeichnisses im zugrunde liegenden Dateisystem. Wenn Sie eine Tabelle erzeugen, speichert MySQL die Tabellendefinition in einer .frm-Datei mit dem gleichen Namen wie die Tabelle. Das heißt, wenn Sie eine Tabelle namens MyTable anlegen, speichert MySQL die Tabellendefinition in MyTable.frm. Da MySQL das Dateisystem ver-

Die Storage-Engines von MySQL |

15

wendet, um Datenbanknamen und Tabellendefinitionen abzulegen, hängt es von der Plattform ab, ob Groß- und Kleinschreibung eine Rolle spielen. Bei einer MySQL-Instanz unter Windows ist die Schreibweise von Tabellen- und Datenbanknamen egal, auf Unixartigen Systemen wird zwischen Groß- und Kleinschreibung unterschieden. Jede StorageEngine speichert die Daten und Indizes der Tabelle anders, der Server selbst arbeitet mit der Tabellendefinition. Um festzustellen, welche Storage-Engine eine bestimmte Tabelle verwendet, benutzen Sie den Befehl SHOW TABLE STATUS. Führen Sie z.B. folgenden Befehl aus, um die Tabelle user in der Datenbank mysql zu untersuchen: mysql> SHOW TABLE STATUS LIKE 'user' \G *************************** 1. row *************************** Name: user Engine: MyISAM Row_format: Dynamic Rows: 6 Avg_row_length: 59 Data_length: 356 Max_data_length: 4294967295 Index_length: 2048 Data_free: 0 Auto_increment: NULL Create_time: 2002-01-24 18:07:17 Update_time: 2002-01-24 21:56:29 Check_time: NULL Collation: utf8_bin Checksum: NULL Create_options: Comment: Users and global privileges 1 row in set (0.00 sec)

Die Ausgabe zeigt, dass es sich hier um eine MyISAM-Tabelle handelt. Sie werden in der Ausgabe vermutlich noch viele weitere Informationen und Statistiken bemerken. Schauen wir uns die Bedeutung der einzelnen Zeilen kurz an: Name

Der Name der Tabelle. Engine

Die Storage-Engine der Tabelle. In den alten MySQL-Versionen hieß diese Spalte Type, nicht Engine. Row_format

Das Format der Zeile bzw. des Datensatzes. Bei einer MyISAM-Tabelle kann es Dynamic, Fixed oder Compressed sein. Dynamische Zeilen variieren in der Länge, weil sie Felder variabler Länge enthalten, etwa VARCHAR oder BLOB. Feste Zeilen, die immer die gleiche Größe aufweisen, bestehen entsprechend aus Feldern, deren Länge nicht variiert, wie etwa CHAR und INTEGER. Komprimierte Zeilen existieren nur in komprimierten Tabellen (siehe »Komprimierte MyISAM-Tabellen« auf Seite 20).

16 |

Kapitel 1: Die MySQL-Architektur

Rows

Die Anzahl der Zeilen (Datensätze) in der Tabelle. Bei nichttransaktionsfähigen Tabellen ist diese Zahl immer genau, sonst handelt es sich eher um eine Schätzung. Avg_row_length

Gibt an, wie viele Bytes die durchschnittliche Zeile enthält. Data_length

Gibt an, wie viele Daten (in Bytes) die gesamte Tabelle enthält. Max_data_length

Die maximale Datenmenge, die diese Tabelle aufnehmen kann. Näheres erfahren Sie in »Speicherung« auf Seite 18. Index_length

Gibt an, wie viel Festplattenplatz die Indexdaten einnehmen. Data_free

Bei einer MyISAM-Tabelle ist das die Menge des zugewiesenen, aber momentan unbenutzten Platzes. Diese Menge enthält die zuvor gelöschten Zeilen und kann von künftigen INSERT-Anweisungen wieder zurückgefordert werden. Auto_increment

Der nächste AUTO_INCREMENT-Wert. Create_time

Gibt an, wann die Tabelle angelegt wurde. Update_time

Gibt an, wann die Daten in der Tabelle zuletzt geändert wurden. Check_time

Gibt an, wann die Tabelle zuletzt mit CHECK TABLE oder myisamchk überprüft wurde. Collation

Der Standardzeichensatz und die Sortierreihenfolge für Zeichenspalten in der Tabelle. Nähere Informationen über diese Eigenschaften finden Sie in »Zeichensätze und Sortierreihenfolgen« auf Seite 255. Checksum

Bei Aktivierung liefert diese Information eine aktuelle Checksumme des Inhalts der gesamten Tabelle. Create_options

Weitere Optionen, die beim Anlegen der Tabelle angegeben wurden. Comment

Dieses Feld enthält eine Reihe zusätzlicher Informationen. Bei einer MyISAMTabelle sind hier mögliche Kommentare enthalten, die beim Erzeugen der Tabelle angegeben wurden. Verwendet die Tabelle die InnoDB-Storage-Engine, dann steht hier die Menge des freien Platzes im InnoDB-Tablespace. Ist die Tabelle eine Sicht, dann enthält der Kommentar den Text »VIEW«.

Die Storage-Engines von MySQL |

17

Die MyISAM-Engine Als Standard-Storage-Engine von MySQL bietet MyISAM einen guten Kompromiss aus Leistung und nützlichen Funktionen, wie etwa Volltextindizierung, Komprimierung und raumbezogenen (GIS) Funktionen. MyISAM unterstützt weder Transaktionen noch zeilenorientierte (Row-Level) Locks.

Speicherung MyISAM speichert jede Tabelle typischerweise in zwei Dateien: einer Datendatei und einer Indexdatei. Die beiden Dateien tragen die Erweiterungen .MYD bzw. .MYI. Das MyISAM-Format ist plattformneutral, was bedeutet, dass Sie die Daten- und Indexdateien problemlos von einem Intel-basierten Server auf einen PowerPC oder eine Sun SPARC kopieren können. MyISAM-Tabellen können dynamische oder statische Zeilen (d.h. Zeilen fester Länge) enthalten. MySQL entscheidet anhand der Tabellendefinition, welches Format es verwendet. Die Anzahl der Zeilen, die eine MyISAM-Tabelle aufnehmen kann, wird hauptsächlich durch den verfügbaren Festplattenplatz auf Ihrem Datenbankserver und die größtmögliche Dateigröße bestimmt, die Ihr Betriebssystem erzeugen kann. MyISAM-Tabellen, die in MySQL 5.0 mit Zeilen variabler Länge erzeugt werden, können standardmäßig mit 256 TByte Daten umgehen und verwenden 6 Byte große Zeiger auf die Datensätze. Frühere MySQL-Versionen benutzten standardmäßig 4-Byte-Zeige für bis zu 4 GByte Daten. Alle MySQL-Versionen können mit Zeigergrößen bis zu 8 Byte umgehen. Um die Zeigergröße in einer MyISAM-Tabelle nach oben oder unten zu ändern, müssen Sie Werte für die Optionen MAX_ROWS und AVG_ROW_LENGTH angeben, die ungefähr den benötigten Platz repräsentieren: CREATE TABLE mytable ( a INTEGER NOT NULL PRIMARY KEY, b CHAR(18) NOT NULL ) MAX_ROWS = 1000000000 AVG_ROW_LENGTH = 32;

In diesem Beispiel haben wir MySQL mitgeteilt, dass es sich auf die Speicherung von wenigstens 32 GByte Daten in der Tabelle einstellen muss. Um festzustellen, was MySQL getan hat, fragen Sie einfach den Tabellenstatus ab: mysql> SHOW TABLE STATUS LIKE 'mytable' \G *************************** 1. row *************************** Name: mytable Engine: MyISAM Row_format: Fixed Rows: 0 Avg_row_length: 0 Data_length: 0 Max_data_length: 98784247807 Index_length: 1024 Data_free: 0 Auto_increment: NULL

18 |

Kapitel 1: Die MySQL-Architektur

Create_time: 2002-02-24 17:36:57 Update_time: 2002-02-24 17:36:57 Check_time: NULL Create_options: max_rows=1000000000 avg_row_length=32 Comment: 1 row in set (0.05 sec)

Wie Sie sehen können, hat sich MySQL genau die Optionen gemerkt, die Sie angegeben haben. Und es hat sich für eine Repräsentation entschieden, die 91 GByte Daten aufnehmen kann! Die Zeigergröße können Sie später mit der Anweisung ALTER TABLE ändern. Allerdings werden dabei die gesamte Tabelle und alle ihre Indizes neu geschrieben, was recht lange dauern kann.

MyISAM-Eigenschaften Als eine der ältesten Storage-Engines in MySQL besitzt MyISAM viele Eigenschaften, die im Laufe der Jahre entwickelt wurden, um bestimmte Lücken zu schließen: Locking und Nebenläufigkeit MyISAM sperrt ganze Tabellen, keine Zeilen. Lesende Operationen fordern Shared Locks (Lese-Locks) für alle Tabellen an, die sie lesen müssen. Schreibende Operationen fordern exklusive Locks (Schreib-Locks) an. Es ist allerdings möglich, neue Zeilen in die Tabelle einzufügen, während Auswahlabfragen darauf ausgeführt werden (nebenläufige oder parallele Einfügungen). Dies ist eine wichtige und sinnvolle Eigenart. Automatische Reparatur MySQL unterstützt die automatische Überprüfung und Reparatur von MyISAMTabellen. In »MyISAM-Ein-/Ausgabe verbessern« auf Seite 304 finden Sie weitere Informationen. Manuelle Reparatur Sie können die Befehle CHECK TABLE mytable und REPAIR TABLE mytable verwenden, um eine Tabelle auf Fehler zu überprüfen und diese zu beheben. Wenn der Server offline ist, haben Sie die Möglichkeit, die Überprüfung und Reparatur der Tabellen mit dem Kommandozeilenwerkzeug myisamchk vorzunehmen. Index-Funktionen In MyISAM-Tabellen können Sie Indizes der ersten 500 Zeichen von BLOB- und TEXTSpalten erzeugen. MyISAM unterstützt Volltextindizes, die einzelne Wörter für komplexe Suchoperationen indizieren. Weitere Informationen über die Indizierung finden Sie in Kapitel 3. Verzögertes Schreiben von Schlüsseln MyISAM-Tabellen, die mit der Option DELAY_KEY_WRITE erzeugt wurden, schreiben am Ende einer Abfrage keine geänderten Indexdaten auf die Festplatte. Stattdessen puffert MyISAM die Änderungen in einem Schlüsselpuffer im Speicher. Die Indexblöcke werden erst dann auf die Platte geschrieben, wenn der Puffer geleert oder die Tabelle geschlossen wird. Bei sich häufig ändernden Tabellen kann dies zu einer deutlichen

Die Storage-Engines von MySQL |

19

Leistungssteigerung führen. Nach einem Server- oder Systemabsturz werden die Indizes allerdings mit hoher Wahrscheinlichkeit beschädigt und müssen repariert werden. Sie sollten dies mit einem Skript erledigen, das myisamchk ausführt, bevor Sie den Server neu starten, oder indem Sie automatische Wiederherstellungsoptionen verwenden. (Selbst wenn Sie DELAY_KEY_WRITE nicht benutzen, sind diese Sicherheitsvorkehrungen eine ausgezeichnete Idee.) Sie können das verzögerte Schreiben der Schlüssel global oder für einzelne Tabellen konfigurieren.

Komprimierte MyISAM-Tabellen Manche Tabellen ändern sich nie, nachdem sie erzeugt und mit Daten gefüllt wurden – etwa in CD-ROM- oder DVD-ROM-basierten Anwendungen und Embedded-Umgebungen. Diese eignen sich dann besonders für komprimierte MyISAM-Tabellen. Sie können Tabellen mit dem Dienstprogramm myisampack komprimieren (oder »packen«). Komprimierte Tabellen lassen sich nicht mehr ändern (obwohl Sie sie bei Bedarf dekomprimieren, verändern und erneut komprimieren können), benötigen aber im Allgemeinen weniger Festplattenplatz. Dadurch sind sie schneller, da kleinere Dateien weniger Suchoperationen erfordern, um Datensätze zu finden. Komprimierte MyISAMTabellen können Indizes haben, sind aber schreibgeschützt. Bei moderner Hardware ist der benötigte Overhead für die Dekomprimierung der Daten für die meisten Anwendungen unerheblich, wo der wirkliche Nutzen in der Reduzierung der Festplattenzugriffe liegt. Die Zeilen werden einzeln komprimiert, so dass MySQL nicht die ganze Tabelle (oder eine Seite) entpacken muss, nur um eine einzige Zeile zu lesen.

Die MyISAM-Merge-Engine Die Merge-Engine ist eine Variante von MyISAM. Eine Merge-Tabelle bildet eine Kombination mehrerer identischer MyISAM-Tabellen in einer virtuellen Tabelle. Sie bietet sich vor allem an, wenn Sie MySQL in Logging- und Data-Warehouse-Anwendungen einsetzen. Eine ausführliche Besprechung der Merge-Tabellen finden Sie in »Merge-Tabellen und Partitionierung« auf Seite 273.

Die InnoDB-Engine InnoDB wurde für die Transaktionsverarbeitung geschaffen – speziell für die Verarbeitung vieler kurzlebiger Transaktionen, die normalerweise abgeschlossen und nicht zurückgenommen werden. Für die transaktionsfähige Speicherung ist dies die beliebteste Storage-Engine. Ihre Leistungsfähigkeit und die Fähigkeit zur automatischen Wiederherstellung nach Abstürzen hat jedoch auch zu ihrer Popularität für nichttransaktionsfähige Speicheranforderungen beigetragen.

20 |

Kapitel 1: Die MySQL-Architektur

InnoDB speichert seine Daten in einer oder mehreren Datendateien, die zusammen als Tablespace bezeichnet werden. Bei einem Tablespace handelt es sich im Prinzip um eine Blackbox, die InnoDB ganz allein verwaltet. In MySQL 4.1 und neueren Versionen kann InnoDB die Daten und Indizes jeder Tabelle in separaten Dateien ablegen. InnoDB kann auch direkt Festplattenpartitionen zum Aufbau seines Tablespace nutzen. Näheres hierzu finden Sie in »Der InnoDB-Tablespace« auf Seite 314. InnoDB verwendet MVCC, um eine hohe Nebenläufigkeit zu erreichen, und implementiert alle vier Standard-SQL-Isolationsebenen. Standardmäßig wird die Isolationsebene REPEATABLE READ benutzt. InnoDB setzt eine Next-Key-Locking-Strategie ein, um Phantom-Reads in dieser Isolationsebene zu vermeiden: Anstatt nur die Zeilen zu sperren, die Sie in einer Abfrage berührt haben, sperrt InnoDB auch Lücken in der Indexstruktur, wodurch verhindert wird, dass Phantome eingefügt werden. InnoDB-Tabellen bauen auf einem cluster-orientierten Index auf, den wir in Kapitel 3 behandeln. Die Indexstrukturen von InnoDB unterscheiden sich stark von denen der meisten anderen MySQL-Storage-Engines. Dadurch sind sehr schnelle Anfragen nach Primärschlüsseln möglich. Allerdings enthalten Sekundärindizes (Indizes, die nicht der Primärschlüssel sind) die Spalten mit den Primärschlüsseln; falls Ihr Primärschlüssel also groß ist, werden auch die anderen Indizes groß sein. Sie sollten sich um einen kleinen Primärschlüssel bemühen, falls Sie viele Indizes in einer Tabelle haben. InnoDB komprimiert nämlich seine Indizes nicht. Momentan ist InnoDB im Gegensatz zu MyISAM nicht dazu in der Lage, Indizes durch Sortierung aufzubauen. Daher lädt InnoDB die Daten und erzeugt die Indizes viel langsamer als MyISAM. Jede Operation, die die Struktur einer InnoDB-Tabelle ändert, baut die gesamte Tabelle einschließlich aller Indizes neu auf. InnoDB wurde entworfen, als die meisten Server langsame Festplatten, nur eine einzige CPU und begrenzte Speicherkapazität besaßen. Heutzutage, da Multicore-Server mit riesigen Speichern und schnellen Festplatten immer preiswerter werden, kommt es bei InnoDB zu Problemen mit der Skalierbarkeit. Die Entwickler von InnoDB kümmern sich um diese Probleme, zurzeit sind aber noch nicht alle gelöst. Im Abschnitt »InnoDB bei Nebenläufigkeit anpassen« auf Seite 321 erfahren Sie genauer, wie Sie eine hohe Nebenläufigkeit mit InnoDB erreichen. Neben der ausgezeichneten Nebenläufigkeit ist die Fremdschlüssel-Beschränkung eine ausgesprochen beliebte Eigenschaft von InnoDB, die nicht einmal der MySQL-Server bietet. InnoDB bietet darüber hinaus außerordentlich schnelle Lookups bei Abfragen, die einen Primärschlüssel verwenden. InnoDB besitzt eine Vielzahl interner Optimierungen. Dazu gehört vorausschauendes Read-Ahead (Vorwärts-Lesen) zum Vorabladen von Daten von der Festplatte, ein adaptiver Hash, der für sehr schnelle Suchen automatisch Indizes im Speicher aufbaut, und ein Eingabepuffer, um das Einfügen zu beschleunigen. Wir werden später ausführlich auf diese Optimierungen eingehen.

Die Storage-Engines von MySQL |

21

Das Verhalten von InnoDB ist sehr kompliziert. Wir empfehlen Ihnen, den Abschnitt »InnoDB Transaction Model and Locking« des MySQL-Handbuchs zu lesen, falls Sie InnoDB einsetzen. Es gibt eine Menge Überraschungen und Ausnahmen, derer Sie sich bewusst sein sollten, bevor Sie eine Anwendung mit InnoDB erstellen.

Die Memory-Engine Memory-Tabellen (früher als HEAP-Tabellen bezeichnet) sind sinnvoll, wenn Sie einen schnellen Zugriff auf Daten benötigen, die sich entweder nie ändern oder die nach einem Neustart nicht fortbestehen müssen. Memory-Tabellen sind im Allgemeinen um etwa eine Größenordnung schneller als MyISAM-Tabellen. Alle ihre Daten werden im Speicher abgelegt, Abfragen müssen deshalb nicht auf die Festplatten-Ein-/Ausgabe warten. Die Tabellenstruktur einer Memory-Tabelle überlebt einen Serverneustart, die Daten tun dies allerdings nicht. Hier sind einige gute Anwendungsfälle für Memory-Tabellen: • für »Lookup«- oder »Mapping«-Tabellen, wie etwa Tabellen, die Postleitzahlen zu Orten zuordnen • zum Speichern der Ergebnisse periodisch gesammelter Daten in einem Cache • für Zwischenergebnisse beim Analysieren von Daten Memory-Tabellen unterstützen HASH-Indizes, die bei Lookup-Abfragen sehr schnell arbeiten. In »Hash-Indizes« auf Seite 108 finden Sie weitere Informationen über HASH-Indizes. Obwohl Memory-Tabellen sehr schnell sind, eignen sie sich oft nicht als allgemeiner Ersatz für festplattenbasierte Tabellen. Sie verwenden ein tabellenorientiertes Locking, das für Schreibvorgänge nur eine niedrige Nebenläufigkeit gewährt, und sie unterstützen keine TEXT- oder BLOB-Spaltentypen. Außerdem unterstützen sie nur Zeilen fester Größe, so dass sie VARCHARs als CHARs ablegen, was eine Verschwendung von Speicher darstellt. MySQL benutzt die Memory-Engine intern, wenn es Abfragen verarbeitet, die eine temporäre Tabelle für Zwischenergebnisse benötigen. Wenn das Zwischenergebnis zu groß für eine Memory-Tabelle wird oder TEXT- oder BLOB-Spalten besitzt, konvertiert MySQL es in eine MyISAM-Tabelle auf der Festplatte um. Mehr dazu erfahren Sie in späteren Kapiteln. Oft werden Memory-Tabellen mit temporären Tabellen verwechselt, bei denen es sich um flüchtige Tabellen handelt, die mit CREATE TEMPORARY TABLE erzeugt wurden. Temporäre Tabellen können jede Storage-Engine verwenden, sie sind nicht identisch mit Tabellen, die die Memory-StorageEngine benutzen. Temporäre Tabellen sind nur für eine einzige Verbindung sichtbar und verschwinden komplett, wenn die Verbindung geschlossen wird.

22 |

Kapitel 1: Die MySQL-Architektur

Die Archive-Engine Die Archive-Engine unterstützt nur INSERT- und SELECT-Abfragen und bot vor MySQL 5.1 auch keine Unterstützung für Indizes. Sie verursacht weniger Festplattenzugriffe als MyISAM, da sie Schreibzugriffe auf Daten puffert und jede Zeile beim Einfügen mit zlib komprimiert. Jede SELECT-Abfrage erfordert außerdem einen kompletten Scan der Tabelle. Archive-Tabellen eignen sich daher ideal für das Logging und die Datenerfassung, wo bei der Analyse oft eine ganze Tabelle durchsucht wird oder wo man schnelle INSERT-Abfragen auf einem Replikations-Master haben will. Replikations-Slaves können für die gleiche Tabelle eine andere Storage-Engine verwenden. Das bedeutet, dass die Tabelle auf dem Slave Indizes für eine schnellere Performance bei der Analyse haben kann. (In Kapitel 8 finden Sie weitere Informationen über die Replikation.) Archive unterstützt ein Row-Level-Locking und ein besonderes Puffersystem für stark nebenläufiges Einfügen. Es bietet konsistente Leseoperationen, indem es ein SELECT stoppt, nachdem es die Anzahl der Zeilen bezogen hat, die in der Tabelle existierten, als die Abfrage begann. Außerdem lässt es massenhafte Einfügungen so lange unsichtbar, bis sie abgeschlossen sind. Diese Funktionen emulieren einige Aspekte der transaktionsfähigen und MVCC-Verhaltensweisen, allerdings ist Archive keine transaktionsfähige Storage-Engine. Es ist einfach eine Storage-Engine, die für schnelles Einfügen und komprimierte Speicherung optimiert wurde.

Die CSV-Engine Die CSV-Engine kann Dateien mit kommaseparierten Werten (CSV-Dateien) als Tabellen behandeln, unterstützt aber keine Indizes dafür. Diese Engine ermöglicht es Ihnen, Dateien in eine Datenbank hinein- und aus ihr herauszukopieren, während der Server läuft. Eine CSV-Datei, die Sie aus einer Tabellenkalkulation exportieren und im Datenverzeichnis des MySQL-Servers speichern, kann der Server sofort lesen. In gleicher Weise kann ein externes Programm Daten, die Sie in eine CSV-Tabelle schreiben, sofort lesen. CSV-Tabellen eignen sich besonders als Datenaustauschformat und für bestimmte Arten des Logging.

Die Federated-Engine Die Federated-Engine speichert Daten nicht lokal. Jede Federated-Tabelle verweist auf eine Tabelle auf einem entfernten MySQL-Server. Sie stellt also für alle Operationen eine Verbindung zu einem entfernten Server her. Sie wird gelegentlich verwendet, um »Hacks« zu ermöglichen, wie etwa Tricks bei der Replikation. In der aktuellen Implementierung dieser Engine gibt es viele Merkwürdigkeiten und Beschränkungen. Wir denken, dass die Federated-Engine sich aufgrund ihrer Funktionsweise am besten für Lookups nach einzelnen Zeilen anhand des Primärschlüssels oder für INSERT-Abfragen auf einem entfernten Server eignet. Bei Aggregatabfragen (zusammengesetzten Abfragen), Verknüpfungen (Joins) oder anderen grundlegenden Operationen funktioniert sie nicht besonders gut.

Die Storage-Engines von MySQL |

23

Die Blackhole-Engine Die Blackhole-Engine besitzt überhaupt keinen Speichermechanismus. Sie verwirft alle INSERTs, anstatt sie zu speichern. Allerdings schreibt der Server Abfragen an BlackholeTabellen wie gewöhnlich in seine Protokolle, so dass sie auf Slaves repliziert oder einfach im Log aufbewahrt werden können. Dadurch eignet sich die Blackhole-Engine ganz gut für ausgefallene Replikationskonfigurationen und für das Logging von Überprüfungen.

Die NDB-Cluster-Engine MySQL AB erwarb die NDB-Cluster-Engine im Jahre 2003 von Sony Ericsson. Ursprünglich war sie für Echtzeitanforderungen gedacht und bot Redundanz und Lastausgleich. Die Engine schrieb zwar ein Log auf die Festplatte, behielt aber alle Daten im Speicher und war für Primärschlüssel-Lookups optimiert. MySQL hat seitdem weitere Indizierungsmethoden und viele Optimierungen hinzugefügt, und MySQL 5.1 erlaubt die Speicherung einiger Spalten auf der Festplatte. Die NDB-Architektur ist einzigartig: Ein NDB-Cluster ist völlig anders als beispielsweise ein Oracle-Cluster. Die NDB-Infrastruktur basiert auf einem Shared-Nothing-Konzept. Es gibt kein Speichernetzwerk oder eine andere große, zentralisierte Speicherlösung, auf die andere Cluster-Typen zurückgreifen. Eine NDB-Datenbank besteht aus Datenknoten, Verwaltungsknoten und SQL-Knoten (MySQL-Instanzen). Jeder Datenknoten enthält ein Segment (»Fragment«) der Daten des Clusters. Die Fragmente werden dupliziert, so dass das System mehrere Kopien der gleichen Daten auf unterschiedlichen Knoten besitzt. Aus Gründen der Redundanz und der Hochverfügbarkeit ist üblicherweise jedem Knoten ein physischer Server zugeordnet. In diesem Sinn ist NDB mit einem RAID auf Serverebene vergleichbar. Die Verwaltungsknoten werden verwendet, um die zentralisierte Konfiguration zu beziehen sowie um die Cluster-Knoten zu überwachen und zu steuern. Alle Datenknoten kommunizieren miteinander, und alle MySQL-Server sind mit allen Datenknoten verbunden. Eine niedrige Netzwerklatenz ist außerordentlich wichtig für NDB-Cluster. Eine Warnung: NDB-Cluster ist eine ziemlich »coole« Technik und sicherlich einiger Untersuchungen wert, um Ihre Neugierde zu befriedigen, allerdings neigen viele Techniker dazu, Ausreden zu suchen, um sie einsetzen zu können, und versuchen, sie an Anforderungen anzupassen, für die sie definitiv nicht geeignet sind. Unserer Erfahrung nach erkennen viele Leute trotz sorgfältiger Überlegungen nicht, wo diese Engine wirklich sinnvoll ist und wie sie funktioniert, wenn sie sie nicht tatsächlich installiert und eine Weile benutzt haben. Dadurch wird meist eine Menge Zeit verschwendet, weil sie wirklich nicht als allgemein einsetzbare Storage-Engine gedacht ist. Schockierend wirkt oft, dass NDB Joins momentan auf der MySQL-Serverebene ausführt und nicht in der Storage-Engine. Da alle Daten für NDB über das Netzwerk bezogen werden müssen, sind komplexe Joins unwahrscheinlich langsam. Andererseits können Suchen in nur einer Tabelle sehr schnell ablaufen, da mehrere Datenknoten jeweils einen

24 |

Kapitel 1: Die MySQL-Architektur

Teil des Ergebnisses liefern. Dies ist nur einer der vielen Aspekte, die Sie berücksichtigen und verstehen müssen, wenn Sie NDB-Cluster für eine bestimmte Anwendung in Betracht ziehen. Die NDB-Cluster-Engine ist so groß und komplex, dass wir sie in diesem Buch nicht weiter behandeln werden. Falls Sie daran interessiert sind, sollten Sie sich ein Buch suchen, das sich speziell diesem Thema widmet. Stellen Sie sich jedoch darauf ein, dass die NDBCluster-Engine voraussichtlich nicht Ihren Erwartungen entsprechen wird und für die meisten traditionellen Anwendungen nicht die richtige Lösung ist.

Die Falcon-Engine Jim Starkey, ein Datenbankpionier, zu dessen früheren Erfindungen Interbase, MVCC und der Spaltentyp BLOB gehören, hat die Falcon-Engine entworfen. MySQL AB erwarb die Falcon-Technik im Jahre 2006, und Jim arbeitet momentan für MySQL AB. Falcon wurde mit Blick auf moderne Hardware entworfen – speziell für Server mit mehreren 64-Bit-Prozessoren und Unmengen an Speicher –, kann aber auch in bescheideneren Umgebungen agieren. Falcon verwendet MVCC und versucht, laufende Transaktionen vollständig im Speicher zu behalten. Daher sind Rollback- und Wiederherstellungsoperationen außerordentlich schnell. Falcon ist momentan noch nicht fertiggestellt (z.B. synchronisiert es seine Commits noch nicht mit dem Binärlog), so dass wir darüber kaum etwas mit Bestimmtheit sagen können. Selbst die ersten Benchmarks, die wir damit durchgeführt haben, werden wahrscheinlich schon wieder veraltet sein, wenn es für den allgemeinen Gebrauch freigegeben wird. Die Falcon-Engine scheint ein gutes Potenzial für viele Online-Anwendungen zu bieten, aber Genaueres wird sich erst mit der Zeit zeigen.

Die solidDB-Engine Die solidDB-Engine, entwickelt von Solid Information Technology (http://www.soliddb. com), ist eine transaktionsfähige Engine, die MVCC benutzt. Sie unterstützt als momentan einzige Engine sowohl pessimistische als auch optimistische Nebenläufigkeitskontrolle. Die solidDB für MySQL enthält eine vollständige Unterstützung für Fremdschlüssel. Sie ähnelt in vielerlei Hinsicht InnoDB, etwa in ihrer Verwendung von Cluster-Indizes. Die solidDB für MySQL enthält eine kostenlose Online-Backup-Möglichkeit. Die solidDB für MySQL ist ein vollständiges Paket, das aus der solidDB-Storage-Engine, der MyISAM-Storage-Engine und dem MySQL-Server besteht. Der »Kitt« zwischen der solidDB-Storage-Engine und dem MySQL-Server wurde Ende 2006 eingeführt. Die zugrunde liegende Technik und der Code haben sich jedoch im Laufe der 15-jährigen Geschichte des Unternehmens entwickelt. Solid zertifiziert und unterstützt das gesamte Produkt. Es unterliegt der GPL und wird kommerziell unter einem dualen Lizenzierungsmodell angeboten, das identisch mit dem des MySQL-Servers ist.

Die Storage-Engines von MySQL |

25

Die PBXT-(Primebase XT-)Engine Die PBXT-Engine, entwickelt von Paul McCullagh von der SNAP Innovation GmbH in Hamburg (http://www.primebase.com), ist eine transaktionsfähige Storage-Engine mit einem einmaligen Design. Eines ihrer charakteristischen Merkmale ist die Art, wie sie Transaktions-Logs und Datendateien einsetzt, um ein Write-Ahead-Logging zu vermeiden, wodurch sich der Overhead der Transaktions-Commits entscheidend verringert. Aufgrund dieser Architektur hat PBXT das Potenzial zu einer sehr hohen Nebenläufigkeit bei Schreiboperationen. Tests haben bereits bewiesen, dass diese Engine bei bestimmten Operationen schneller sein kann als InnoDB. PBXT verwendet MVCC und unterstützt Fremdschlüssel-Beschränkungen, setzt aber keine Cluster-Indizes ein. PBXT ist eine relativ neue Engine und muss sich erst noch in Produktionsumgebungen bewähren. So wurde etwa die Implementierung für wirklich dauerhafte Transaktionen erst während der Entstehung dieses Buches abgeschlossen. Als Ergänzung zu PBXT arbeitet man bei SNAP Innovation an einer skalierbaren »BlobStreaming«-Infrastruktur (http://www.blobstreaming.org). Diese soll in der Lage sein, große Mengen an Binärdaten effizient zu speichern und abzurufen.

Die Maria-Storage-Engine Maria ist eine neue Storage-Engine, die von einigen der besten MySQL-Entwickler entwickelt wird, etwa von Michael Widenius, der MySQL geschaffen hat. Die Version 1.0 enthält nur einige der geplanten Funktionen. Das Ziel besteht darin, Maria als Ersatz für MyISAM zu verwenden, das momentan die Standard-Storage-Engine von MySQL ist und das der Server intern für solche Aufgaben wie Privilege Tables und temporäre Tabellen benutzt, die beim Ausführen von Abfragen erzeugt werden. Hier sind einige Besonderheiten aus dem Plan: • das tabellenweise Festlegen einer transaktionsfähigen oder nichttransaktionsfähigen Speicherung • die Wiederherstellung nach Abstürzen, selbst wenn die Tabelle im nichttransaktionsfähigen Modus läuft • Row-Level-Locking und MVCC • bessere BLOB-Verarbeitung

Weitere Storage-Engines Mehrere Dritthersteller bieten weitere (manchmal proprietäre) Engines an. Außerdem gibt es eine Unmenge spezialisierter und experimenteller Engines (z.B. eine Engine zum Abfragen von Webservices). Einige dieser Engines werden eher so nebenbei entwickelt, manchmal nur von einem oder zwei Entwicklern. Es ist nämlich recht einfach, eine Storage-Engine für MySQL herzustellen. Die meisten dieser Engines sind allerdings nicht weit verbreitet, weil sie oft nur begrenzt einsetzbar sind. Wir überlassen es Ihnen, diese Angebote zu erkunden.

26 |

Kapitel 1: Die MySQL-Architektur

Die richtige Engine auswählen Wenn Sie MySQL-basierte Anwendungen entwerfen, müssen Sie entscheiden, welche Storage-Engine Sie zum Speichern Ihrer Daten verwenden. Falls Sie nicht schon in der Entwurfsphase darüber nachdenken, werden Sie wahrscheinlich später mit Schwierigkeiten rechnen müssen. Möglicherweise merken Sie dann, dass die vorgegebene Engine eine gewünschte Funktion, wie etwa Transaktionen, nicht bietet oder dass der Mix aus Leseund Schreibabfragen, den Ihre Anwendung generiert, eine größere Granularität beim Locking erfordert, als die Tabellen-Locks von MyISAM erlauben. Da Sie die Storage-Engines tabellenweise angeben können, müssen Sie eine klare Vorstellung davon haben, wie die einzelnen Tabellen verwendet werden und welche Daten sie speichern sollen. Es ist außerdem hilfreich, wenn man ein gutes Verständnis für die Anwendung als Ganzes und ihr Wachstumspotenzial hat. Ausgestattet mit diesen Informationen können Sie darangehen, sinnvolle Entscheidungen darüber zu treffen, welche Storage-Engines letztendlich zum Zuge kommen. Es ist nicht unbedingt eine gute Idee, für unterschiedliche Tabellen auch unterschiedliche Storage-Engines zu verwenden. Wenn es sich einrichten lässt, sollten Sie sich für eine Storage-Engine entscheiden. Sie werden sich Ihr Leben damit deutlich erleichtern.

Überlegungen Es gibt zwar viele Faktoren, die Ihre Entscheidung beeinflussen können, welche StorageEngines zum Einsatz kommen, normalerweise läuft es aber auf ein paar wesentliche Überlegungen hinaus. Hier sind die wichtigsten Dinge, die Sie beachten sollten: Transaktionen Falls Ihre Anwendung Transaktionen erfordert, dann ist InnoDB momentan die stabilste, am besten integrierte und bewährte Wahl. Wir gehen aber davon aus, dass andere transaktionsfähige Engines mit der Zeit eine starke Konkurrenz bilden werden. MyISAM ist eine gute Wahl, wenn eine Aufgabe keine Transaktionen erfordert und vor allem SELECT- oder INSERT-Abfragen ausführt. Manchmal fallen bestimmte Komponenten einer Anwendung (wie etwa das Logging) in diese Kategorie. Nebenläufigkeit (Concurrency) Wie Sie am besten Ihre Anforderungen an die Nebenläufigkeit befriedigen, hängt von Ihrer Arbeitslast ab. Falls Sie nur parallel einfügen und lesen müssen, dann ist, ob Sie es glauben oder nicht, MyISAM eine gute Wahl! Müssen Sie dagegen dafür sorgen, dass ein Mix aus Operationen nebenläufig ausgeführt wird, ohne dass sie sich in die Quere kommen, dann sollten Sie sich für eine der Engines mit RowLevel-Locking entscheiden.

Die Storage-Engines von MySQL |

27

Backups Die Forderung nach regelmäßig durchgeführten Backups könnte ebenfalls die Wahl Ihrer Tabelle beeinflussen. Falls es kein Problem ist, den Server zum Erstellen von Backups regelmäßig herunterzufahren, dann ist es auch einfach, eine Storage-Engine zu wählen. Falls Sie dagegen in irgendeiner Form Online-Backups durchführen müssen, wird es weniger einfach. In Kapitel 11 wird dieses Thema näher betrachtet. Denken Sie auch daran, dass sich bei Verwendung mehrerer Storage-Engines die Komplexität der Backups und der Servereinrichtung erhöht. Wiederherstellung nach Abstürzen Wenn Sie viele Daten haben, müssen Sie ernsthaft darüber nachdenken, wie lange es dauert, das System nach einem Absturz wiederherzustellen. MyISAM-Tabellen werden z.B. im Allgemeinen leichter zerstört und brauchen viel länger für die Wiederherstellung als InnoDB-Tabellen. Um genau zu sein, ist das sogar einer der wichtigsten Gründe dafür, weshalb so viele Leute InnoDB verwenden, obwohl sie keine Transaktionen benötigen. Besondere Eigenschaften Manchmal werden Sie feststellen, dass eine Anwendung auf bestimmte Funktionen oder Optimierungen zurückgreift, die nur einige der MySQL-Storage-Engines zu bieten haben. Zum Beispiel sind viele Anwendungen auf Cluster-Index-Optimierungen angewiesen. Momentan beschränkt Sie dies auf InnoDB und solidDB. Andererseits unterstützt nur MyISAM eine Volltextsuche in MySQL. Wenn eine StorageEngine eine oder mehrere wichtige Anforderungen erfüllt, andere dagegen nicht, dann müssen Sie entweder einen Kompromiss eingehen oder eine clevere Designlösung finden. Oft bekommen Sie das, was Sie brauchen, von einer Storage-Engine, die Ihre Anforderungen scheinbar nicht unterstützt. Sie müssen sich nicht sofort entscheiden. Im Rest dieses Buches erfahren Sie noch eine Menge über die Stärken und Schwächen der einzelnen Storage-Engines und erhalten viele Tipps zu Architektur und Entwurf. Meist gibt es mehr Möglichkeiten, als Sie wahrscheinlich jetzt erkennen, und vermutlich hilft es, später auf die Frage der richtigen StorageEngine zurückzukommen.

Praktische Beispiele Ohne Beispiele aus dem richtigen Leben wirken diese Probleme und Überlegungen vermutlich ziemlich abstrakt. Betrachten wir deshalb einige verbreitete Datenbankanwendungen. Wir schauen uns verschiedene Tabellen an und stellen fest, welche Engine deren Anforderungen am besten entgegenkommt. Eine Zusammenfassung der Möglichkeiten finden Sie im nächsten Abschnitt.

Logging Nehmen wir an, Sie wollen mit MySQL in Echtzeit jeden Anruf über eine zentrale Telefonanlage festhalten. Oder vielleicht haben Sie mod_log_sql für Apache installiert, so 28 |

Kapitel 1: Die MySQL-Architektur

dass Sie alle Besuche Ihrer Website direkt in einer Tabelle festhalten können. Bei einer solchen Anwendung ist Geschwindigkeit wohl das wesentliche Ziel, und die Datenbank soll dabei nicht einen Flaschenhals bilden. Die Storage-Engines MyISAM und Archive würden hier ganz gut funktionieren, da sie einen relativ geringen Overhead verursachen und Tausende von Datensätzen pro Sekunde aufzeichnen können. Auch die PBXTStorage-Engine ist vermutlich besonders für Logging-Aufgaben geeignet. Interessant wird es, wenn Sie beschließen, Berichte anzufertigen, die die aufgezeichneten Daten zusammenfassen. Je nach den verwendeten Abfragen wird sich das Einfügen der Datensätze deutlich verlangsamen, während Sie die Daten für den Bericht sammeln. Was können Sie tun? Eine Lösung besteht darin, die Daten mithilfe der in MySQL fest eingebaute Replikation auf einen zweiten (Slave-)Server zu klonen. Die zeit- und CPU-intensiven Abfragen können dann auf dem Slave ausgeführt werden. Der Master kann die Datensätze weiterhin so schnell einfügen wie bisher, während Sie auf dem Slave beliebige Abfragen durchführen können, ohne sich Gedanken darüber machen zu müssen, ob diese das Echtzeit-Logging negativ beeinflussen. Sie können Abfragen auch in Zeiten mit niedriger Last durchführen, allerdings dürfen Sie sich nicht darauf verlassen, dass diese Strategie noch funktioniert, wenn Ihre Anwendung wächst. Eine weitere Möglichkeit ist die Verwendung einer Merge-Tabelle. Anstatt die Daten immer in die gleiche Tabelle zu schreiben, passen Sie die Anwendung so an, dass sie in eine Tabelle schreibt, die das Jahr oder den Namen bzw. die Nummer des Monats in ihrem Namen enthält: web_logs_2008_01 oder web_logs_2008_jan. Definieren Sie dann eine Merge-Tabelle, die die Daten enthält, die Sie zusammenfassen wollen, und verwenden Sie diese in Ihren Abfragen. Auch falls Sie die Daten täglich oder wöchentlich zusammenfassen müssen, funktioniert diese Strategie, Sie müssen einfach nur Tabellen mit spezielleren Namen anlegen, wie etwa web_logs_2008_01_01. Während Sie Abfragen in Tabellen durchführen, in die nicht mehr geschrieben wird, kann Ihre Anwendung ungestört Datensätze in der aktuellen Tabelle aufzeichnen.

Nur (oder hauptsächlich) gelesene Tabellen Aus Tabellen, deren Daten zum Aufbau eines Katalogs oder einer Liste (Jobs, Auktionen, Immobilien usw.) verwendet werden, wird normalerweise viel häufiger gelesen, als dass in sie geschrieben wird. Das macht sie zu guten Kandidaten für MyISAM – falls es Ihnen egal ist, was passiert, wenn MyISAM abstürzt. Unterschätzen Sie nicht, wie wichtig das ist; viele Anwender verstehen nicht, wie riskant es ist, eine Storage-Engine zu benutzen, die sich nicht einmal ernsthaft darum bemüht, ihre Daten auf die Platte zu schreiben.

Die Storage-Engines von MySQL |

29

Es ist eine ausgezeichnete Idee, eine realistische Lastsimulation auf einem Testserver durchzuführen und dann im wahrsten Sinne des Wortes den Stecker zu ziehen. Die Erfahrungen, die Sie bei der Wiederherstellung nach einem Absturz machen werden, sind unbezahlbar. Sie ersparen Ihnen hässliche Überraschungen im tatsächlichen Betrieb.

Vertrauen Sie nicht einfach auf die verbreitete Volksweisheit »MyISAM ist schneller als InnoDB«. Sie ist nicht grundsätzlich wahr. Wir können Ihnen Dutzende von Situationen nennen, in denen InnoDB MyISAM weit hinter sich lässt, vor allem bei Anwendungen, in denen Cluster-Indizes sinnvoll sind oder bei denen die Daten in den Speicher passen. Wenn Sie den Rest dieses Buches lesen, bekommen Sie ein Gespür dafür, welche Faktoren die Leistung einer Storage-Engine beeinflussen (Datengröße, Anzahl der notwendigen Ein-/Ausgabeoperationen, Primärschlüssel gegen Sekundärindizes usw.) und welche davon für Ihre Anwendung wichtig sind.

Auftragsverarbeitung Wenn Sie es mit irgendeiner Art von Auftragsverarbeitung zu tun haben, dann sind Transaktionen ein Muss. Halb abgearbeitete Bestellungen würden Ihren Dienst beim Kunden nicht unbedingt beliebt machen. Eine weitere wichtige Überlegung ist, ob die Engine Fremdschlüssel-Beschränkungen unterstützen muss. Zurzeit ist wahrscheinlich InnoDB am besten für Anwendungen zur Auftragsbearbeitung geeignet, obwohl auch die anderen transaktionsfähigen Storage-Engines heiße Kandidaten sind.

Aktienkurse Falls Sie Aktienkurse für die eigene Analyse sammeln, ist MyISAM – mit den üblichen Warnungen – eine gute Wahl. Betreiben Sie jedoch einen stark frequentierten Webservice, der Aktienkurse in Echtzeit sammelt und Tausende von Benutzern bedient, dann sollte eine Abfrage nie warten müssen. Zu jedem Zeitpunkt könnten viele Clients versuchen, die Tabelle zu lesen bzw. zu schreiben. Deshalb stellt Row-Level-Locking oder ein Entwurf, der Updates minimiert, die beste Lösung dar.

Schwarze Bretter und Thread-fähige Diskussionsforen Thread-fähige Diskussionsforen sind für MySQL-Benutzer ein interessantes Problem. Es gibt dafür Hunderte von frei verfügbaren PHP- und Perl-basierten Systemen. Bei vielen von ihnen wurde die Effizienz der Datenbank nicht berücksichtigt, so dass sie dazu neigen, für jede Anforderung eine große Anzahl von Abfragen auszuführen. Einige von ihnen wurden unabhängig von einer bestimmten Datenbank geschrieben, so dass sie die Vorteile von bestimmten Datenbanksystemen nicht ausnutzen. Gleichzeitig müssen die Zähler und Statistiken für die verschiedenen Diskussionen aktualisiert werden. Viele der Systeme benutzen darüber hinaus nur wenige monolithische Tabellen, um ihre Daten zu

30 |

Kapitel 1: Die MySQL-Architektur

speichern. Dementsprechend konzentrieren sich die starken Schreib-/Leseaktivitäten auf einige zentrale Tabellen, und die zur Wahrung der Konsistenz notwendigen Locks werden zu einer steten Quelle des Wettstreits. Ungeachtet ihrer Entwurfsmängel funktionieren die meisten Systeme bei kleiner und mittlerer Last ganz gut. Wenn eine Website jedoch wächst und eine Menge Verkehr generiert, kann sie sehr langsam werden. Die offensichtliche Lösung besteht darin, auf eine andere Storage-Engine zu wechseln, die in der Lage ist, mit dem gestiegenen Lese-/ Schreibaufkommen klarzukommen. Benutzer, die dies versuchen, werden manchmal allerdings überrascht sein, wenn sie feststellen, dass die Systeme sogar noch langsamer laufen als vorher! Diese Benutzer bemerken nicht, dass das System eine bestimmte Abfrage verwendet, die normalerweise ungefähr so aussieht: mysql> SELECT COUNT(*) FROM table;

Das Problem ist, dass nicht alle Engines diese Abfrage schnell ausführen können: MyISAM kann es, andere Engines möglicherweise nicht. Für jede Engine gibt es ähnliche Beispiele. In Kapitel 2 erfahren Sie, wie Sie sich vor solchen Überraschungen schützen und Lösungen für dieses Problem finden können.

CD-ROM-Anwendungen Wenn Sie eine CD-ROM- oder DVD-ROM-basierte Anwendung vertreiben müssen, die MySQL-Datendateien verwendet, dann sollten Sie in Betracht ziehen, MyISAM oder komprimierte MyISAM-Tabellen zu verwenden, die leicht isoliert und auf andere Medien kopiert werden können. Komprimierte MyISAM-Tabellen benötigen viel weniger Platz als unkomprimierte, sind allerdings schreibgeschützt. Bei bestimmten Anwendungen kann das problematisch werden, da die Daten aber sowieso auf ein schreibgeschütztes Medium kommen sollen, besteht wenig Grund dafür, unkomprimierte Tabellen für diese spezielle Aufgabe einzusetzen.

Storage-Engine-Zusammenfassung Tabelle 1-3 fasst die transaktions- und Locking-bezogenen Eigenschaften der beliebtesten MySQL-Storage-Engines zusammen. Die Spalte mit der MySQL-Version zeigt die minimale MySQL-Version, die Sie benötigen, um die Engine zu verwenden. Für einige Engines und MySQL-Versionen müssen Sie allerdings Ihren eigenen Server kompilieren. Das Wort »Alle« in dieser Spalte bedeutet alle Versionen seit MySQL 3.23.

Die Storage-Engines von MySQL |

31

Tabelle 1-3: Zusammenfassung der MySQL-Storage-Engines Storage-Engine

MySQL-Version

Transaktionen

MyISAM

Alle

Nein

LockingGranularität

Wichtige Anwendungen

Gegenanzeigen

Tabelle mit nebenläufigen Einfügungen

SELECT, INSERT, Laden

Gemischte Lese-/ Schreiblast

großer Mengen

MyISAM Merge

Alle

Nein

Tabelle mit nebenläufigen Einfügungen

Segmentierte Archivierung, Data- Warehouses

Viele globale Lookups

Memory (HEAP)

Alle

Nein

Tabelle

Zwischenberechnungen, statischer Lookup

Große Datensätze, persistente Speicherung

InnoDB

Alle

Ja

Zeilenorientiert (Row-Level) mit MVCC

Transaktionsfähige Verarbeitung

Keine

Falcon

6.0

Ja

Zeilenorientiert (Row-Level) mit MVCC

Transaktionsfähige Verarbeitung

Keine

Archive

4.1

Ja

Zeilenorientiert (Row-Level)

Logging, Gesamtanalyse

Zufälliger Zugriff, Updates, Löschungen

CSV

4.1

Nein

Tabelle

Logging, massenhaftes Laden externer Daten

Zufälliger Zugriff, Indizierung

Blackhole

4.1

Ja

Row-Level mit MVCC

geloggte oder replizierte Archivierung

Alle bis auf die vorgesehenen Anwendungen

Federated

5.0

N/A

N/A

Verteilte Datenquellen

Alle bis auf die vorgesehene Anwendung

NDB Cluster

5.0

Ja

Zeilenorientiert (Row-Level)

Hochverfügbarkeit

Die meisten typischen Anwendungen

PBXT

5.0

Ja

Zeilenorientiert (Row-Level) mit MVCC

Transaktionsfähige Verarbeitung, Logging

Bedarf an ClusterIndizes

solidDB

5.0

Ja

Zeilenorientiert (Row-Level) mit MVCC

Transaktionsfähige Verarbeitung

Keine

Maria (geplant)

6.x

Ja

Zeilenorientiert (Row-Level) mit MVCC

MyISAM-Ersatz

Keine

32 |

Kapitel 1: Die MySQL-Architektur

Tabellenkonvertierungen Es gibt verschiedene Möglichkeiten, eine Tabelle von einer Storage-Engine in eine andere zu konvertieren, die jeweils Vor- und Nachteile haben. In den folgenden Abschnitten beschreiben wir drei der gebräuchlichsten Methoden.

ALTER TABLE Die einfachste Möglichkeit, eine Tabelle von einer Engine zu einer anderen zu verschieben, besteht in der Anweisung ALTER TABLE. Der folgende Befehl konvertiert mytable zu Falcon: mysql> ALTER TABLE mytable ENGINE = Falcon;

Diese Syntax funktioniert bei allen Storage-Engines, es gibt allerdings einen Haken: Es kann sehr lange dauern. MySQL kopiert die alte Tabelle zeilenweise in die neue Tabelle. Während dieser Zeit wird wahrscheinlich die komplette Ein-/Ausgabekapazität der Festplatte des Servers beansprucht, und die Originaltabelle wird zum Lesen gesperrt, während die Konvertierung läuft. Denken Sie also zweimal nach, bevor Sie diese Technik auf einer ausgelasteten Tabelle einsetzen. Greifen Sie vielleicht lieber auf eine der anderen vorgestellten Methoden zurück, bei denen zuerst eine Kopie der Tabelle erstellt wird. Wenn Sie von einer Storage-Engine in eine andere konvertieren, gehen alle StorageEngine-spezifischen Eigenschaften verloren. Falls Sie etwa eine InnoDB-Tabelle nach MyISAM und wieder zurück konvertieren, verlieren Sie alle Fremdschlüssel, die Sie ursprünglich in der InnoDB-Tabelle definiert hatten.

Dump und Import Um den Konvertierungsvorgang besser kontrollieren zu können, könnten Sie die Tabelle zuerst mit dem Dienstprogramm mysqldump in eine Textdatei speichern. Anschließend bearbeiten Sie einfach die Dump-Datei, um die CREATE TABLE-Anweisung anzupassen, die sie enthält. Denken Sie daran, sowohl den Tabellennamen als auch ihren Typ zu ändern, da es nämlich nicht möglich ist, zwei Tabellen des gleichen Namens in der Datenbank vorzuhalten, selbst wenn sie einen unterschiedlichen Typ aufweisen – und mysqldump schreibt standardmäßig den Befehl DROP TABLE vor CREATE TABLE, so dass Ihre Daten verloren gehen, wenn Sie nicht aufpassen! In Kapitel 11 finden Sie weitere Hinweise über das effiziente Dumpen und Neuladen von Daten.

CREATE und SELECT Die dritte Konvertierungstechnik ist ein Kompromiss aus der Geschwindigkeit des ersten und der Sicherheit des zweiten Mechanismus. Anstatt die gesamte Tabelle als Dump zu speichern oder alles auf einmal zu konvertieren, legen Sie die neue Tabelle an und verwenden die MySQL-Syntax INSERT ... SELECT, um sie zu füllen:

Die Storage-Engines von MySQL |

33

mysql> CREATE TABLE innodb_table LIKE myisam_table; mysql> ALTER TABLE innodb_table ENGINE=InnoDB; mysql> INSERT INTO innodb_table SELECT * FROM myisam_table;

Das funktioniert gut, wenn Sie nicht viele Daten haben. Müssen dagegen viele Daten konvertiert werden, ist es oft effizienter, die Tabelle schrittweise zu füllen und die Transaktion zwischen jedem Schritt zu bestätigen, damit die »Undo-Logs« nicht zu groß werden. Nehmen Sie an, dass id der Primärschlüssel ist. Führen Sie dann diese Abfrage wiederholt aus (wobei Sie jedes Mal größere Werte für x und y benutzen), bis Sie alle Daten in die neue Tabelle kopiert haben: mysql> mysql> -> mysql>

START TRANSACTION; INSERT INTO innodb_table SELECT * FROM myisam_table WHERE id BETWEEN x AND y; COMMIT;

Anschließend haben Sie die Originaltabelle, die Sie schließen können, wenn Sie fertig sind, und die neue Tabelle, die nun vollständig gefüllt ist. Denken Sie daran, die Originaltabelle zu sperren, damit Sie keine inkonsistente Kopie der Daten erhalten!

34 |

Kapitel 1: Die MySQL-Architektur

KAPITEL 2

Engpässe finden: Benchmarking und Profiling

Irgendwann wird es so weit sein, dass Sie mehr Leistung von MySQL benötigen. Aber was sollten Sie versuchen zu verbessern? Eine bestimmte Abfrage? Ihr Schema? Ihre Hardware? Sie werden es nur herausfinden, wenn Sie messen, was Ihr System tut, und seine Leistung unter verschiedenen Bedingungen testen. Aus diesem Grund haben wir dieses Kapitel bereits so früh in das Buch eingefügt. Die beste Strategie besteht darin, die schwächste Verbindung in der Kette der Komponenten Ihrer Anwendung zu finden. Das ist vor allem dann sinnvoll, wenn Sie nicht wissen, was eine bessere Performance verhindert – oder was eine bessere Performance in der Zukunft verhindern wird. Benchmarking und Profiling sind zwei wichtige Techniken, um Flaschenhälse zu ermitteln. Sie sind miteinander verwandt, aber nicht identisch. Ein Benchmark misst die Leistung Ihres Systems. Das kann helfen, die Kapazität eines Systems festzustellen, zu zeigen, welche Änderungen eine Rolle spielen und welche nicht, oder zu zeigen, wie Ihre Anwendung mit unterschiedlichen Daten funktioniert. Im Gegensatz dazu hilft Ihnen Profiling dabei, herauszufinden, wo Ihre Anwendung die meiste Zeit verbringt oder die meisten Ressourcen beansprucht. Mit anderen Worten, Benchmarking beantwortet die Frage »Wie gut funktioniert das?«, und Profiling beantwortet die Frage »Wieso funktioniert es so?«. Wir haben dieses Kapitel in zwei Teile aufgeteilt: Der erste Teil handelt vom Benchmarking, im zweiten geht es um Profiling. Wir beginnen mit einer Diskussion der Gründe und Strategien für das Benchmarking und kommen dann zu speziellen Taktiken dafür. Wir zeigen Ihnen, wie man Benchmarks plant und entwirft, wie man für exakte Ergebnisse entwirft, Benchmarks durchführt und die Ergebnisse analysiert. Zum Ende des ersten Teils betrachten wir Benchmarking-Werkzeuge und schauen uns Beispiele für deren Einsatz an. Im zweiten Teil des Kapitels erfahren Sie, wie man sowohl Anwendungen als auch MySQL profiliert. Wir zeigen Beispiele für echten Profilierungscode, den wir in der Produktion verwendet haben, um uns bei der Analyse der Performance von Anwendungen

|

35

zu unterstützen. Darüber hinaus zeigen wir, wie man die Abfragen von MySQL protokolliert, die Logs analysiert und die Statuszähler von MySQL und andere Werkzeuge einsetzt, um festzustellen, was MySQL und Ihre Abfragen tun.

Wozu Benchmarks? Bei vielen mittleren bis großen MySQL-Anwendungsfällen gibt es Leute, die sich speziell um das Benchmarking kümmern. Allerdings sollte jeder Entwickler und Datenbankadministrator mit grundlegenden Benchmarking-Prinzipien und -Techniken vertraut sein. Benchmarks können sehr hilfreich für Sie sein: • Messen Sie, wie Ihre Anwendung momentan arbeitet. Wenn Sie nicht wissen, wie schnell sie im Moment läuft, können Sie nicht sicher sein, ob Änderungen, die Sie vornehmen, überhaupt einen Sinn haben. Mithilfe älterer Benchmark-Ergebnisse können Sie Probleme erkennen, die Sie nicht vorhergesehen haben. • Validieren Sie die Skalierbarkeit Ihres Systems. Mit einem Benchmark könnten Sie eine viel höhere Last simulieren, als Ihre Produktionssysteme verarbeiten, etwa den tausendfachen Anstieg der Benutzerzahl. • Berücksichtigen Sie das Wachstum bei Ihrer Planung. Benchmarks helfen Ihnen dabei, abzuschätzen, wie viel Hardware, Netzwerkkapazität und andere Ressourcen Sie für Ihre vorgesehene künftige Last benötigen. Damit verringern Sie das Risiko bei Upgrades oder größeren Änderungen der Anwendung. • Testen Sie die Fähigkeit Ihrer Anwendung, eine sich ändernde Umgebung zu tolerieren. Beispielsweise können Sie feststellen, wie Ihre Anwendung bei einer sporadisch auftretenden Spitze in der Nebenläufigkeit oder mit einer anderen Serverkonfiguration funktioniert oder wie Sie mit einer anderen Datenverteilung zurechtkommt. • Testen Sie unterschiedliche Hardware-, Software- und Betriebssystemkonfigurationen. Ist RAID 5 oder RAID 10 besser für Ihr System? Wie ändert sich die Leistung von zufälligen Schreiboperationen, wenn Sie von ATA-Festplatten auf SAN-Speicherung umstellen? Skaliert der 2.4-Linux-Kernel besser als der 2.6-Kernel? Nützt eine höhere MySQL-Version der Leistung? Was ist mit einer anderen Storage-Engine für Ihre Daten? Diese Fragen können Sie mit speziellen Benchmarks beantworten. Benchmarks können Sie auch für andere Zwecke einsetzen, etwa um eine einheitliche Testsuite für Ihre Anwendung zu schaffen; wir konzentrieren uns hier jedoch auf die leistungsbezogenen Aspekte.

Benchmarking-Strategien Es gibt zwei vorrangige Benchmarking-Strategien: Sie können die Anwendung als Ganzes bewerten oder MySQL allein betrachten. Diese beiden Strategien werden als Full-Stackbzw. Single-Component-Benchmarking bezeichnet. Es gibt verschiedene Gründe, eine Anwendung als Ganzes zu messen, anstatt sich nur auf MySQL zu beschränken:

36 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

• Sie testen die gesamte Anwendung, einschließlich des Webservers, des Anwendungscodes und der Datenbank. Das ist sinnvoll, weil Sie sich nicht um die Leistung von MySQL im Speziellen kümmern; Ihnen geht es um die ganze Anwendung. • MySQL bildet nicht immer die Engstelle der Anwendung. Ein Full-Stack-Benchmark kann dies beweisen. • Nur durch das Testen der ganzen Anwendung können Sie feststellen, wie sich der Cache der einzelnen Teile verhält. • Benchmarks sind nur so weit gut, dass sie das Verhalten der eigentlichen Anwendung widerspiegeln, was schwer festzustellen ist, wenn Sie nur einen Teil davon testen. Andererseits sind Anwendungs-Benchmarks unter Umständen schwer herzustellen und noch schwerer korrekt einzurichten. Wenn Sie einen Benchmark schlecht gestalten, treffen Sie möglicherweise falsche Entscheidungen, weil die Ergebnisse gar nicht die Wirklichkeit wiedergeben. Manchmal jedoch wollen Sie nicht über die ganze Anwendung informiert werden. Sie brauchen vielleicht nur einen MySQL-Benchmark, zumindest anfangs. Solch ein Benchmark ist sinnvoll, wenn: • Sie verschiedene Schemata oder Abfragen vergleichen wollen • Sie ein spezielles Problem testen wollen, das Sie in der Anwendung festgestellt haben • Sie einen langen Benchmark zu Gunsten eines kürzeren vermeiden wollen, der einen schnelleren Zyklus von Änderung und Messung erlaubt Es ist darüber hinaus sinnvoll, Benchmark-Tests mit MySQL durchzuführen, wenn Sie die Abfragen Ihrer Anwendung an einer echten Datenmenge wiederholen können. Die Daten selbst und die Größe der Datenmenge müssen realistisch sein. Nutzen Sie nach Möglichkeit einen Schnappschuss von tatsächlichen Produktionsdaten. Leider kann das Einrichten eines realistischen Benchmarks kompliziert und zeitaufwendig sein, und Sie haben Glück, wenn Sie eine Kopie von Produktionsdaten bekommen. Das kann natürlich auch unmöglich sein – stellen Sie sich etwa vor, Sie entwickeln eine neue Anwendung, die nur wenige Benutzer und kaum Daten hat. Wenn Sie wissen wollen, wie sie funktioniert, wenn sie sehr groß wird, bleibt Ihnen keine andere Wahl, als die Daten und die Arbeitslast der größeren Anwendung zu simulieren.

Was gemessen wird Bevor Sie mit dem Benchmarking beginnen, müssen Sie Ihre Ziele festlegen – genauer gesagt, bevor Sie Ihre Benchmarks entwerfen. Ihre Ziele bestimmen die Werkzeuge und Techniken, die Sie einsetzen, um exakte, sinnvolle Ergebnisse zu erhalten. Formulieren Sie Ihre Ziele als Fragen, wie etwa »Ist diese CPU besser als jene?« oder »Funktionieren die neuen Indizes besser als die aktuellen?«.

Benchmarking-Strategien |

37

Es ist vielleicht nicht so offensichtlich, aber manchmal brauchen Sie verschiedene Ansätze, um andere Dinge zu messen. So könnten Latenz und Durchsatz unterschiedliche Benchmarks erfordern. Betrachten Sie die folgenden Maße und wie sie zu Ihren Leistungszielen passen: Transaktionen pro Zeiteinheit Dies ist einer der Klassiker für das Benchmarking von Datenbankanwendungen. Standardisierte Benchmarks wie TPC-C (siehe http://www.tpc.org) sind weithin anerkannt, und viele Datenbankhersteller bemühen sich darum, sie gut zu erfüllen. Diese Benchmarks messen die Leistung bei der Online-Verarbeitung von Transaktionen (Online Transaction Processing; OLTP) und eignen sich am besten für interaktive Mehrbenutzeranwendungen. Die übliche Maßeinheit ist Transaktionen pro Sekunde. Der Begriff Durchsatz bedeutet üblicherweise das Gleiche wie Transaktionen (oder andere Arbeitseinheit) pro Zeiteinheit. Antwortzeit oder Latenz Dies misst die Gesamtzeit, die eine Aufgabe erfordert. Je nach Ihrer Anwendung müssen Sie sie in Millisekunden, Sekunden oder Minuten messen. Von diesem Wert können Sie dann durchschnittliche, minimale und maximale Antwortzeiten ableiten. Die maximale Antwortzeit ist meist kein sinnvolles Maß, da die maximale Antwortzeit wahrscheinlich umso länger wird, je länger der Benchmark läuft. Sie ist außerdem kaum reproduzierbar und wird wahrscheinlich zwischen den Durchläufen stark schwanken. Aus diesem Grund verwenden viele Leute stattdessen die Percentile Response Times (Antwortzeiten der Perzentile). Falls z.B. die Antwortzeit des 95. Perzentils bei 5 Millisekunden liegt, wissen Sie, dass die Aufgabe in 95 % der Fälle in weniger als 5 Millisekunden ausgeführt wird. Meist hilft es, wenn man die Ergebnisse dieser Benchmarks grafisch darstellt, entweder in Form von Linien (z.B. den Durchschnitt und das 95. Perzentil) oder als Streuungsdiagramm, damit Sie sehen können, wie die Werte verteilt sind. Diese Graphen zeigen Ihnen, wie sich die Benchmarks auf lange Sicht verhalten werden. Nehmen Sie einmal an, Ihr System setzt jede Stunde für eine Minute einen Kontrollpunkt. Während der Kontrolle hält das System an, und Transaktionen werden nicht abgeschlossen. Die Antwortzeit des 95. Perzentils zeigt keine Spitzen, die Ergebnisse weisen daher nicht auf das Problem hin. Eine grafische Darstellung dagegen zeigt periodisch auftretende Spitzen in der Antwortzeit. Abbildung 2-1 verdeutlicht dies. Abbildung 2-1 stellt auf der y-Achse die Anzahl der Transaktionen pro Minute dar (ADTPM). Diese Linie zeigt deutliche Spitzen, die im Gesamtdurchschnitt (gepunktete Linie) nicht zu erkennen sind. Die erste Spitze entsteht, weil die Caches des Servers noch leer sind (Cold Cache). Die anderen Spitzen zeigen, wann der Server intensiv »Dirty Pages« auf die Platte schreibt. Ohne das Diagramm sind die Abweichungen schlecht zu erkennen.

38 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

12000 10000

ADTPM

8000 6000 4000 2000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Zeit in Minuten

Abbildung 2-1: Ergebnisse eines 30-minütigen dbt2-Benchmark-Durchlaufs

Skalierbarkeit Messungen der Skalierbarkeit sind für solche Systeme sinnvoll, die ihre Leistungsfähigkeit unter sich ändernden Lasten beibehalten sollen. »Performance unter sich ändernder Arbeitslast« ist ein ziemlich abstraktes Konzept. Die Performance wird typischerweise mit einem Maß wie Durchsatz oder Antwortzeit gemessen, die Arbeitslast schwankt bei Änderungen von Datenbankgröße, Anzahl der nebenläufigen Verbindungen oder Hardware. Skalierbarkeitsmessungen bieten sich an, wenn man die Kapazität planen will, da man mit ihnen leicht die Schwächen in der Anwendung zeigen kann, die andere Benchmark-Strategien nicht zeigen. Falls Sie z.B. Ihr System so gestalten, dass es bei einem Antwortzeit-Benchmark mit einer einzigen Verbindung gut funktioniert (eine ziemlich schwache Benchmark-Strategie), wird die Leistung der Anwendung wahrscheinlich stark abfallen, sobald eine bestimmte Anzahl gleichzeitiger Verbindungen erreicht wird. Ein Benchmark, der auf konsistente Antwortzeiten bei einer zunehmenden Anzahl von Verbindungen achtet, würde diesen Entwurfsfehler aufdecken. Manche Aktivitäten, wie etwa Batch-Jobs zum Erzeugen von Zusammenfassungen aus Einzeldaten brauchen einfach schnelle Antwortzeiten, Punkt. Bei ihnen ist es in Ordnung, Benchmarks mit Blick auf die Antwortzeiten durchzuführen; versuchen Sie aber auch daran zu denken, wie sie mit anderen Aktivitäten interagieren. BatchJobs können dafür sorgen, dass interaktive Abfragen leiden und umgekehrt. Nebenläufigkeit Nebenläufigkeit ist ein wichtiges, aber häufig missbrauchtes und falsch verstandenes Maß. Beispielsweise wird gern davon gesprochen, wie viele Benutzer gleichzei-

Benchmarking-Strategien |

39

tig auf einer Website zu Besuch sind. Allerdings ist HTTP zustandslos, und die meisten Benutzer lesen einfach nur, was in ihren Browsern angezeigt wird, das hat also nichts mit Nebenläufigkeit, also der parallelen Abarbeitung auf dem Webserver zu tun. Nebenläufigkeit auf dem Webserver überträgt sich auch nicht unbedingt auf den Datenbankserver; die einzige Sache, mit der sie direkt zusammenhängt, ist die Frage, wie viele Daten der Speichermechanismus der Sitzung verarbeiten können muss. Ein genaueres Maß der Nebenläufigkeit auf dem Webserver ist etwa, wie viele Anforderungen pro Sekunde die Benutzer zu Spitzenzeiten generieren. Sie können Nebenläufigkeit auch an verschiedenen Stellen in der Anwendung messen. Die höhere Nebenläufigkeit auf dem Webserver kann auch eine höhere Nebenläufigkeit auf der Datenbankebene verursachen, das wird allerdings von der Sprache und den verwendeten Werkzeugen beeinflusst. So verursacht z.B. Java mit einem Verbindungspool wahrscheinlich eine geringere Anzahl gleichzeitiger Verbindungen zum MySQL-Server als PHP mit persistenten Verbindungen. Wichtiger ist immer noch die Anzahl der Verbindungen, die zu einem bestimmten Zeitpunkt Abfragen ausführen. Eine gut gestaltete Anwendung könnte Hunderte von Verbindungen zum MySQL-Server offen haben, aber nur ein Bruchteil von ihnen sollte zu einem Zeitpunkt Abfragen ausführen. Eine Website mit »50.000 Benutzern gleichzeitig« bräuchte also nur 10 oder 15 gleichzeitig laufende Abfragen auf dem MySQL-Server! Mit anderen Worten: Worum Sie sich beim Benchmarking wirklich kümmern sollten, ist die Nebenläufigkeit im Betrieb oder die Anzahl der Threads oder Verbindungen, die gleichzeitig aktiv sind. Messen Sie, ob die Leistung stark abfällt, wenn die Nebenläufigkeit zunimmt. Ist dies der Fall, dann kommt Ihre Anwendung mit Lastspitzen nicht zurecht. Sie müssen entweder dafür sorgen, dass die Leistung nicht stark abfällt, oder die Anwendung so gestalten, dass sie in den Teilen, die damit nicht zurechtkommen, keine hohe Nebenläufigkeit zulässt. Im Allgemeinen werden Sie die Nebenläufigkeit auf dem MySQL-Server mit Methoden wie dem Application Queuing beschränken. In Kapitel 10 finden Sie mehr Informationen zu diesem Thema. Nebenläufigkeit ist völlig anders als Antwortzeit und Skalierbarkeit: Es ist kein Ergebnis, sondern eine Eigenschaft dafür, wie Sie den Benchmark einrichten. Anstatt die Nebenläufigkeit zu messen, die Ihre Anwendung erreicht, messen Sie die Leistung der Anwendung auf verschiedenen Ebenen der Nebenläufigkeit. In der letzten Analyse sollten Sie testen, was für Ihre Benutzer wichtig ist. Benchmarks messen die Leistung, aber »Leistung« hat für alle Leute eine andere Bedeutung. Sammeln Sie (offiziell oder inoffiziell) Informationen über die Anforderungen an die Skalierbarkeit des Systems darüber, was als akzeptable Antwortzeiten angesehen wird, welche Art von Nebenläufigkeit erwartet wird usw. Versuchen Sie dann, Ihre Benchmarks so zu gestalten, dass sie all diese Anforderungen berücksichtigen, ohne dass Sie einen Tunnelblick entwickeln oder einige Dinge zum Nachteil anderer bevorzugen.

40 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

Benchmarking-Taktiken Nach den allgemeinen Anmerkungen wird es nun spezieller. Wir wollen uns anschauen, wie man Benchmarks gestaltet und ausführt. Zuerst schauen wir uns allerdings einige verbreitete Fehler an, die zu unnützen oder ungenauen Ergebnissen führen können: • die Verwendung einer Teilmenge der echten Datengröße, wie etwa die Verwendung nur eines Gigabyte an Daten, wenn die Anwendung eigentlich Hunderte von Gigabyte verarbeiten können muss, oder die Verwendung der aktuellen Datenmenge, wenn die Anwendung in der Zukunft eigentlich viel größer werden soll • die Verwendung falsch verteilter Daten, wie etwa gleichmäßig verteilter Daten, wenn die Daten des tatsächlichen Systems »Hot Spots« aufweisen (Zufällig generierte Daten weisen oft eine unrealistische Verteilung auf.) • die Verwendung unrealistisch verteilter Parameter, etwa wenn man so tut, als würden alle Benutzerprofile gleich wahrscheinlich betrachtet werden • die Verwendung eines Einbenutzerszenarios für eine Mehrbenutzeranwendung • Benchmarking einer verteilten Anwendung auf einem einzigen Server • falsch eingeschätztes Benutzerverhalten, wie etwa die »Zeit zum Nachdenken« auf einer Webseite. Echte Benutzer fordern eine Seite an und lesen sie dann – sie klicken nicht ohne Pause nacheinander auf Links. • die Ausführung identischer Abfragen in einer Schleife. Echte Abfragen sind nicht identisch, so dass der Cache nicht immer anspringt. Identische Abfragen liegen irgendwann vollständig oder teilweise im Cache vor. • das Verpassen der Fehlerprüfung. Wenn die Ergebnisse eines Benchmarks irgendwie sinnlos sind – z.B., wenn eine langsame Operation auf einmal sehr schnell abgeschlossen wird –, müssen Sie auf Fehler überprüfen. Vielleicht testen Sie mit dem Benchmark ja nur, wie schnell MySQL einen Syntaxfehler in der SQL-Abfrage entdecken kann! Prüfen Sie prinzipiell immer die Fehlerprotokolle nach einem Benchmark-Test. • ignorieren, wie das System läuft, wenn es noch nicht warmgelaufen ist, wie etwa direkt nach einem Neustart. Manchmal müssen Sie wissen, wie lange es dauert, bis der Server nach einem Neustart wieder die volle Kapazität erreicht hat, und schauen sich deshalb speziell die Aufwärmperiode an. Falls Sie andererseits die normale Leistung untersuchen wollen, müssen Sie daran denken, dass viele Caches nach einem Neustart noch kalt sind und die Benchmark-Tests nicht die gleichen Ergebnisse liefern wie nach einer gewissen Laufzeit des Servers. • die Verwendung von Standardservereinstellungen. In Kapitel 6 erfahren Sie mehr über das Optimieren der Servereinstellungen. Schon indem Sie diese Fehler vermeiden, können Sie die Qualität Ihrer Ergebnisse deutlich verbessern.

Benchmarking-Taktiken | 41

Abgesehen davon sollten Sie versuchen, die Tests so realistisch wie möglich zu gestalten. Manchmal allerdings ist es sinnvoll, einen etwas unrealistischen Benchmark einzusetzen. Nehmen Sie z.B. an, Ihre Anwendung befindet sich auf einem anderen Host als der Datenbankserver. Es wäre realistischer, die Benchmarks in der gleichen Konfiguration durchzuführen. Das würde aber gleichzeitig weitere Variablen einbringen, etwa wie schnell und belastet das Netzwerk ist. Benchmarking auf einem einzelnen Knoten ist normalerweise einfacher und in einigen Fällen genau genug. Sie müssen selbst abschätzen, welches Vorgehen passend ist.

Einen Benchmark entwerfen und planen Der erste Schritt beim Planen eines Benchmarks besteht darin, das Problem und das Ziel zu erkennen. Als Nächstes müssen Sie entscheiden, ob Sie einen Standard-Benchmark benutzen oder einen eigenen entwerfen wollen. Wenn Sie einen Standard-Benchmark verwenden, dann achten Sie darauf, dass dieser Ihren Anforderungen entspricht. Nehmen Sie z.B. keinen TPC-Benchmark, um ein ECommerce-System zu testen. Laut eigener Aussage veranschaulicht TPC Entscheidungsunterstützungssysteme, die große Datenmengen untersuchen. Daher ist dieser Benchmark nicht passend für ein OLTP-System. Das Entwerfen eines eigenen Benchmarks ist ein komplizierter und iterativ ablaufender Vorgang. Nehmen Sie als Einstieg einen Schnappschuss Ihrer Produktionsdatenmenge auf. Sorgen Sie dafür, dass Sie diese Daten für nachfolgende Durchläufe wiederherstellen können. Nun brauchen Sie Abfragen, die Sie an diesen Daten durchführen. Sie können eine Modultestsuite in einen rudimentären Benchmark umwandeln, indem Sie sie einfach viele Male durchlaufen lassen. Allerdings wird dies wahrscheinlich kaum der Art und Weise entsprechen, wie Sie die Datenbank wirklich benutzen. Ein besserer Ansatz sieht vor, alle Abfragen auf Ihrem Produktionssystem in einem repräsentativen Zeitrahmen zu protokollieren, etwa eine Stunde unter Spitzenlast oder einen ganzen Tag lang. Wenn Sie Abfragen während eines kurzen Zeitraums aufzeichnen, müssen Sie möglicherweise mehrere Zeitrahmen wählen. Auf diese Weise können Sie alle Systemaktivitäten erfassen, wie etwa Abfragen zur Erstellung von wöchentlichen Berichten oder Batch-Jobs, die Sie außerhalb der Spitzenzeiten eintakten.1 Sie können Abfragen auf unterschiedlichen Ebenen aufzeichnen. Falls Sie z.B. einen FullStack-Benchmark benötigen, können Sie die HTTP-Anforderungen auf einem Webserver protokollieren. Es ist natürlich auch möglich, das MySQL-Abfrage-Log zu aktivieren. Wenn Sie jedoch ein Abfrage-Log noch einmal abspielen, müssen Sie daran denken, die Threads zu trennen, anstatt einfach alle Abfragen linear abzuspielen. Es ist außerdem

1 All das natürlich unter der Voraussetzung, dass Sie einen perfekten Benchmark haben wollen. Normalerweise macht Ihnen das Leben einen Strich durch die Rechnung.

42 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

wichtig, einen eigenen Thread für jede Verbindung in dem Log einzurichten, anstatt die Abfragen in den Threads zu mischen. Das Abfrage-Log zeigt, über welche Verbindungen die einzelnen Abfragen kamen. Selbst wenn Sie keinen eigenen Benchmark herstellen, sollten Sie Ihren BenchmarkingPlan aufschreiben. Sie werden den Benchmark viele Male durchführen und müssen in der Lage sein, ihn exakt zu reproduzieren. Denken Sie bei der Planung auch an die Zukunft. Vielleicht sind Sie gar nicht derjenige, der den Benchmark das nächste Mal ausführt, und selbst wenn, erinnern Sie sich möglicherweise nicht mehr genau daran, wie Sie ihn das erste Mal ausgeführt haben. Ihr Plan sollte auch die Testdaten, die Schritte zum Einrichten des Systems und den Aufwärmplan umfassen. Denken Sie sich eine Methode zum Dokumentieren der Parameter und Ergebnisse aus, und dokumentieren Sie jeden Durchlauf sorgfältig. Ihre Dokumentationsmethode könnte so einfach wie eine Tabellenkalkulation oder ein Notizbuch sein oder so aufwendig wie eine selbst entworfene Datenbank. (Denken Sie daran, dass Sie wahrscheinlich einige Skripte schreiben werden, die Sie bei der Auswertung der Ergebnisse unterstützen. Je einfacher es daher ist, die Ergebnisse zu verarbeiten, ohne Tabellenkalkulations- oder Textdateien zu öffnen, umso besser.) Vermutlich ist es sinnvoll, ein Benchmark-Verzeichnis anzulegen, in dem es Unterverzeichnisse für die Ergebnisse der einzelnen Durchläufe gibt. Sie können dann die Ergebnisse, Konfigurationsdateien und Notizen für jeden Durchlauf in das entsprechende Unterverzeichnis legen. Falls Sie mit Ihrem Benchmark mehr messen, als Sie zunächst interessiert, zeichnen Sie die zusätzlichen Daten dennoch auf. Es ist besser, unnütze Daten zu haben, als wenn wichtige Daten fehlen, und vielleicht brauchen Sie die Zusatzdaten später doch noch. Versuchen Sie, so viele zusätzliche Informationen wie möglich während der Benchmarks aufzuzeichnen, wie etwa CPU-Auslastung, Festplatten-Ein-/ Ausgabe, Statistiken über den Netzwerkverkehr, Zähler von SHOW GLOBAL STATUS usw.

Exakte Ergebnisse erhalten Um wirklich exakte Ergebnisse zu erhalten, müssen Sie Ihren Benchmark so entwerfen, dass er tatsächlich Ihre möglichen Fragen beantwortet. Haben Sie den richtigen Benchmark gewählt? Erfassen Sie alle Daten, die Sie benötigen, um die Fragen zu beantworten? Testen Sie mit dem Benchmark die falschen Kriterien? Führen Sie etwa einen CPUgebundenen Benchmark durch, um die Leistung einer Anwendung vorherzusagen, von der Sie wissen, dass sie ein-/ausgabegebunden ist? Sorgen Sie als Nächstes dafür, dass Ihre Benchmark-Ergebnisse wiederholbar sind. Versuchen Sie sicherzustellen, dass das System sich am Anfang jedes Durchlaufs im gleichen Zustand befindet. Wenn der Benchmark wichtig ist, sollten Sie zwischen den Durchläufen booten. Falls Sie, was normal wäre, einen aufgewärmten Server testen müssen, sollten Sie dafür sorgen, dass die Aufwärmphase lang genug und dass sie wiederholbar ist. Besteht das Aufwärmen z.B. aus zufälligen Abfragen, werden Ihre Benchmark-Ergebnisse nicht reproduzierbar sein. Benchmarking-Taktiken | 43

Wenn der Benchmark Daten oder das Schema ändert, dann setzen Sie ihn zwischen den Durchläufen mit einem frischen Schnappschuss zurück. Das Einfügen in eine Tabelle mit 1000 Zeilen liefert nicht die gleichen Ergebnisse wie das Einfügen in eine Tabelle mit einer Million Zeilen! Auch die Datenfragmentierung und die Aufteilung auf der Festplatte können der Reproduzierbarkeit der Ergebnisse im Wege stehen. Damit das physische Layout immer annähernd gleich ist, könnten Sie eine Partition schnell formatieren und neu mit Daten füllen. Achten Sie auf externe Last-, Profilierungs- und Überwachungssysteme, ausführliches Logging, regelmäßig wiederkehrende Jobs und andere Faktoren, die Ihre Ergebnisse verfälschen können. Eine typische Überraschung ist ein cron-Job, der mitten in einem Benchmark-Durchlauf beginnt, oder ein Patrol-Read-Zyklus oder eine planmäßige Konsistenzprüfung auf Ihrer RAID-Karte. Sorgen Sie dafür, dass alle Ressourcen, die der Benchmark während des Durchlaufs benötigt, auch ihm zugeordnet sind. Wenn jemand anderes die Netzwerkkapazität belegt oder der Benchmark auf einem SAN stattfindet, den auch andere Server benutzen, werden die Ergebnisse möglicherweise nicht genau sein. Versuchen Sie, während der Durchführung eines Benchmarks so wenige Parameter wie möglich zu ändern. Man nennt dies in der Wissenschaft »die Variable isolieren«. Wenn Sie mehrere Dinge auf einmal ändern müssen, dann verpassen Sie vermutlich etwas. Parameter können auch voneinander abhängig sein, so dass sie sich manchmal gar nicht unabhängig voneinander ändern lassen. Vielleicht wissen Sie nicht einmal, dass sie miteinander verbunden sind. Das erhöht natürlich die Komplexität. Manchmal spielt das keine Rolle. Falls Sie etwa über eine Migration von einem Solaris-System auf SPARCHardware zu GNU/Linux auf x86 nachdenken, wäre es sinnlos, als Zwischenschritt Solaris auf x86 einem Benchmark-Test zu unterziehen! Im Allgemeinen hilft es, wenn man die Benchmark-Parameter schrittweise ändert und nicht alle auf einmal. Setzen Sie z.B. Techniken wie »Teile und Herrsche« (zum Halbieren der Unterschiede zwischen den Durchläufen) ein, um sich an einen guten Wert für die Servereinstellung heranzutasten. Wir kennen viele Benchmarks, die versuchen, die Leistung nach einer Migration, etwa von Oracle nach MySQL vorherzusagen. Diese sind oft problematisch, weil MySQLmit völlig anderen Arten von Abfragen gut funktioniert als Oracle. Falls Sie wissen wollen, wie gut eine Anwendung, die auf Oracle erstellt wurde, funktioniert, nachdem Sie sie nach MySQL migriert haben, müssen Sie normalerweise das Schema und die Abfragen für MySQL umgestalten. (In manchen Fällen, z.B. wenn Sie eine plattformübergreifende Anwendung herstellen, wird es Sie interessieren, wie die gleichen Abfragen auf beiden Plattformen laufen, aber das ist eher ungewöhnlich.) Auch aus den vorgegebenen Einstellungen der MySQL-Konfiguration werden Sie kaum sinnvolle Ergebnisse gewinnen, da diese auf winzige Anwendungen abgestimmt sind, die wenig Speicher beanspruchen.

44 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

Sollten Sie schließlich ein seltsames Ergebnis erhalten, dann verwerfen Sie es nicht einfach. Versuchen Sie lieber herauszufinden, was passiert ist. Vielleicht finden Sie ein wertvolles Ergebnis, ein großes Problem oder einfach einen Fehler in Ihrem BenchmarkDesign.

Den Benchmark ausführen und die Ergebnisse analysieren Nachdem Sie alles vorbereitet haben, können Sie den Benchmark ausführen und damit beginnen, Daten zu sammeln und zu analysieren. Meist ist es eine gute Idee, die Benchmark-Durchläufe zu automatisieren. Damit verbessern Sie Ihre Ergebnisse und deren Genauigkeit, da Sie auf diese Weise keine Schritte vergessen oder in den einzelnen Durchläufen unterschiedlich ausführen. Es hilft außerdem bei der Dokumentation des Benchmark-Tests. Jede Automatisierungsmethode eignet sich, etwa ein Makefile oder eine Reihe eigener Skripten. Sie können sich für eine beliebige Skriptsprache entscheiden: für eine Shell, PHP, Perl usw. Versuchen Sie, so viel wie möglich zu automatisieren, einschließlich des Ladens der Daten, des Aufwärmens des Systems, des Ausführens des Benchmarks und des Aufzeichnens der Ergebnisse. Wenn Sie das Benchmarking richtig eingerichtet haben, können Sie es in einem Schritt durchführen. Soll es dagegen eine einmalige Angelegenheit bleiben, dann lohnt sich das Automatisieren nicht.

Normalerweise führt man einen Benchmark mehrmals durch. Die genaue Anzahl der Durchgänge hängt von Ihrem Vorgehen bei der Auswertung ab und davon, wie wichtig die Ergebnisse sind. Falls Sie größere Sicherheit haben wollen, müssen Sie den Benchmark mehrfach durchführen. Es ist üblich, das beste Ergebnis zu suchen, einen Durchschnitt aus allen Ergebnissen zu bilden oder den Benchmark fünfmal ablaufen zu lassen und dann den Durchschnitt aus den drei besten Ergebnissen zu bilden. Sie können so exakt sein, wie Sie wollen. Möglicherweise möchten Sie ja statistische Methoden auf Ihre Ergebnisse anwenden, Konfidenzintervalle ermitteln usw., aber oft benötigen Sie diese große Sicherheit gar nicht.2 Wenn er Ihre Fragen zu Ihrer Zufriedenheit beantwortet, können Sie den Benchmark ruhig mehrere Male ausführen und feststellen, wie stark die Ergebnisse sich unterscheiden. Falls sie stark schwanken, führen Sie entweder den Benchmark öfter durch oder lassen ihn länger laufen, wodurch sich normalerweise die Abweichungen verringern. Sobald Sie Ihre Ergebnisse haben, müssen Sie sie analysieren, d.h., Zahlen in Wissen umwandeln. Das Ziel besteht darin, die Frage zu beantworten, die der Benchmark formu-

2 Falls Sie wirklich wissenschaftlich exakte, harte Ergebnisse haben wollen, sollten Sie ein gutes Buch darüber lesen, wie Sie kontrollierte Tests entwerfen und durchführen. Dieses Thema können wir nämlich aufgrund seines Umfangs hier nicht behandeln.

Benchmarking-Taktiken | 45

liert. Idealerweise werden Sie jetzt Aussagen treffen können wie »Das Aufrüsten auf vier CPUs erhöht den Durchsatz um 50 % bei gleichbleibender Latenz« oder »Die Indizes haben die Abfragen beschleunigt«. Wie Sie die Zahlen »würfeln«, hängt davon ab, wie Sie die Ergebnisse gesammelt haben. Es bietet sich an, zur Analyse der Ergebnisse Skripten zu schreiben, nicht nur, um den Arbeitsaufwand zu verringern, sondern aus den gleichen Gründen, aus denen Sie auch die Benchmarks automatisieren sollen: Reproduzierbarkeit und Dokumentation.

Benchmarking-Werkzeuge Sie müssen kein eigenes Benchmarking-System aufziehen. Das ist sowieso nur dann notwendig, wenn es einen wirklich dringenden Grund dafür gibt, dass Sie keines der verfügbaren Systeme einsetzen können. Ihnen stehen eine Vielzahl von Werkzeugen zur Verfügung. In den folgenden Abschnitten werden wir einige davon vorstellen.

Full-Stack-Werkzeuge Erinnern Sie sich daran, dass es zwei Arten von Benchmarks gibt: Full-Stack und SingleComponent. Es wird Sie nicht überraschen zu hören, dass es Werkzeuge gibt, um ganze Anwendungen einem Benchmark-Test zu unterziehen, und Werkzeuge, um an MySQL und anderen Komponenten isoliert Stresstests durchzuführen. Durch das Testen des vollständigen Systems erhalten Sie normalerweise ein klareres Bild von seiner Leistung. Zu den Werkzeugen für solche Tests gehören: ab ab ist ein bekanntes Benchmarking-Werkzeug für den Apache-HTTP-Server. Es zeigt, wie viele Anforderungen pro Sekunde Ihr HTTP-Server bedienen kann. Falls Sie eine Webanwendung testen, bedeutet dies, wie viele Anforderungen pro Sekunde die gesamte Anwendung erfüllen kann. Es ist ein sehr einfaches Werkzeug, sein Nutzen ist allerdings beschränkt, da es einfach nur, so schnell es kann, eine URL abarbeitet. Weitere Informationen über ab finden Sie unter http://httpd.apache. org/docs/2.0/programs/ab.html. http_load Dieses Werkzeug ist vom Konzept her mit ab vergleichbar; es ist ebenfalls dazu gedacht, einen Webserver zu laden, allerdings bietet es größere Flexibilität. Sie können eine Eingabedatei mit vielen verschiedenen URLs anlegen, http_load wählt dann zufällig eine aus. Darüber hinaus können Sie die Rate vorgeben, mit der die Anforderungen ausgeführt werden, anstatt sie einfach so schnell wie möglich abarbeiten zu lassen. Näheres erfahren Sie unter http://www.acme.com/software/http_load/. JMeter JMeter ist ein Java-Programm, das eine andere Anwendung laden und seine Performance messen kann. Es wurde zum Testen von Webanwendungen geschaffen, Sie können damit aber auch FTP-Server testen und über JDBC Abfragen an eine Datenbank auslösen. 46 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

JMeter ist viel komplexer als ab und http_load. Es besitzt z.B. Funktionen, mit denen Sie viel flexibler echte Benutzer simulieren können, indem Sie solche Parameter wie die Anlaufzeit (ramp-up time) kontrollieren. Es verfügt über eine grafische Oberfläche mit einer integrierten Darstellung der Ergebnisse in Diagrammform und bietet die Möglichkeit, Ergebnisse aufzuzeichnen und erneut abzuspielen. Weitere Informationen finden Sie unter http://jakarta.apache.org/jmeter/.

Single-Component-Werkzeuge Hier sind einige nützliche Werkzeuge, um die Leistung von MySQL und des Systems zu testen, auf dem es läuft. Im nächsten Abschnitt zeigen wir Beispiel-Benchmarks mit einigen dieser Werkzeuge: mysqlslap mysqlslap (http://dev.mysql.com/doc/refman/5.1/en/mysqlslap.html) simuliert die Last auf dem Server und liefert Zeitinformationen. Es ist Teil der MySQL-5.1-Server-Distribution, sollte aber auch mit MySQL 4.1 und neueren Servern funktionieren. Sie können angeben, wie viele nebenläufige Verbindungen es benutzen soll, und übergeben entweder eine SQL-Anweisung auf der Kommandozeile oder eine Datei, die auszuführende SQL-Anweisungen enthält. Falls Sie dem Programm keine Anweisungen übergeben, kann es auch automatisch SELECT-Anweisungen generieren, indem es das Schema des Servers untersucht. sysbench sysbench (http://sysbench.sourceforge.net) ist ein Multithread-fähiges System-Benchmarking-Werkzeug. Sein Ziel besteht darin, ein Gefühl für die Systemleistung zu gewinnen, und zwar in Bezug auf Faktoren, die zum Ausführen eines Datenbankservers wichtig sind. Sie können z.B. die Leistung von Datei-Ein-/Ausgabe, Betriebssystem-Scheduler, Speicherzuweisung und Übertragungsgeschwindigkeit, der POSIXThreads sowie des Datenbankservers selbst messen. sysbench unterstützt Skripten in der Sprache Lua (http://www.lua.org), wodurch man sehr flexibel eine Vielzahl von Szenarien testen kann. Database Test Suite Die Database Test Suite, die von den Open-Source Development Labs (OSDL) geschaffen wurde und auf SourceForge unter http://sourceforge.net/projects/osdldbt/ angeboten wird, ist ein Test-Kit zum Ausführen von Benchmarks, die mit einigen Industriestandard-Benchmarks vergleichbar sind, wie etwa denen des Transaction Processing Performance Council (TPC). Speziell beim dbt2-Testprogramm handelt es sich um eine freie (allerdings nicht zertifizierte) Implementierung des TPC-C-OLTPTests. Sie unterstützt InnoDB und Falcon. Zurzeit ist der Status für die anderen transaktionsfähigen MySQL-Storage-Engines unbekannt. MySQL Benchmark Suite (sql-bench) MySQL bietet zusammen mit dem MySQL-Server seine eigene Benchmark-Suite an, mit der Sie unterschiedliche Datenbankserver testen können. Sie ist Single-Thread-

Benchmarking-Werkzeuge |

47

fähig und misst, wie schnell der Server Abfragen ausführt. Die Ergebnisse zeigen, welche Arten von Operationen der Server gut ausführt. Der größte Vorteil dieser Benchmark-Suite besteht darin, dass sie viele vordefinierte Tests enthält, die einfach zu benutzen sind, so dass es leicht ist, unterschiedliche Storage-Engines oder Konfigurationen miteinander zu vergleichen. Man kann damit sogar sehr gut die Gesamtleistung zweier Server miteinander vergleichen. Sie können auch nur einen Teil ihrer Tests ausführen (um z.B. nur die UPDATE-Leistung zu testen). Die Tests sind größtenteils CPU-gebunden, einige kurze Zeiträume erfordern aber auch viele Festplatten-Ein-/Ausgaben. Die größten Nachteile dieses Werkzeugs bestehen darin, dass es nicht mehrbenutzerfähig ist, dass es eine sehr kleine Datenmenge benutzt, dass Sie die Site-spezifischen Daten nicht testen können und dass seine Ergebnisse zwischen den Durchläufen variieren können. Da es nur Single-Thread-fähig und vollständig seriell ist, hilft es Ihnen nicht dabei, die Vorteile mehrerer CPUs abzuschätzen. Allerdings lassen sich mehrere Server mit jeweils nur einer CPU miteinander vergleichen. Für den Datenbankserver, den Sie testen wollen, sind Perl- und DBD-Treiber erforderlich. Die Dokumentation finden Sie unter http://dev.mysql.com/doc/en/mysqlbenchmarks.html/. Super Smack Super Smack (http://vegan.net/tony/supersmack/) ist ein Stresstest-Werkzeug für MySQL und PostgreSQL. Es handelt sich hierbei um ein komplexes, leistungsfähiges Werkzeug, mit dem Sie mehrere Benutzer simulieren, Testdaten in die Datenbank laden und Tabellen mit zufällig generierten Daten füllen können. Die Benchmarks sind in sogenannten »Smack«-Dateien enthalten, die eine einfache Sprache verwenden, um Clients, Tabellen, Abfragen usw. zu definieren.

Benchmarking-Beispiele In diesem Abschnitt zeigen wir Ihnen einige Beispiele für tatsächliche Benchmarks mit einigen der oben erwähnten Werkzeuge. Wir können nicht auf jedes Werkzeug ausführlich eingehen, aber dennoch sollten Ihnen diese Beispiele bei der Entscheidung für einen sinnvollen Benchmark und bei den ersten Schritten helfen.

http_load Beginnen wir mit einem einfachen Beispiel für die Verwendung von http_load. Dazu benutzen wir die folgenden URLs, die wir in der Datei urls.txt gespeichert haben: http://www.mysqlperformanceblog.com/ http://www.mysqlperformanceblog.com/page/2/ http://www.mysqlperformanceblog.com/mysql-patches/ http://www.mysqlperformanceblog.com/mysql-performance-presentations/ http://www.mysqlperformanceblog.com/2006/09/06/slow-query-log-analyzes-tools/

48 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

Die MySQL-Funktion BENCHMARK( ) MySQL besitzt eine praktische BENCHMARK( )-Funktion, mit der Sie die Ausführungsgeschwindigkeit bestimmter Arten von Operationen testen können. Sie geben einen Ausdruck an, der ausgeführt werden soll, und legen fest, wie oft dies zu geschehen hat. Der Ausdruck kann ein beliebiger Skalar sein, wie etwa eine skalare Unterabfrage oder eine Funktion. Damit lässt sich sehr schön die relative Geschwindigkeit einiger Operationen testen, wie etwa ob MD5( ) schneller als SHA1( ) ist: mysql> SET @input := 'hello world'; mysql> SELECT BENCHMARK(1000000, MD5(@input)); +---------------------------------+ | BENCHMARK(1000000, MD5(@input)) | +---------------------------------+ | 0 | +---------------------------------+ 1 row in set (2.78 sec) mysql> SELECT BENCHMARK(1000000, SHA1(@input)); +----------------------------------+ | BENCHMARK(1000000, SHA1(@input)) | +----------------------------------+ | 0 | +----------------------------------+ 1 row in set (3.50 sec)

Der Rückgabewert ist immer 0. Sie messen die Ausführung, indem Sie nachschauen, welche Zeit die Clientanwendung für die Ausführung der Abfrage angegeben hat. In diesem Fall sieht es so aus, als sei MD5( ) schneller. Es ist allerdings nicht ganz einfach, BENCHMARK( ) richtig einzusetzen, wenn man nicht weiß, was es eigentlich tut. Es misst nämlich, wie schnell der Server den Ausdruck ausführen kann, liefert jedoch keinen Hinweis auf den Overhead für das Parsen und Optimieren. Und wenn der Ausdruck keine Benutzervariable enthält, dann wird unter Umständen ab der zweiten Ausführung des Ausdrucks durch den Server ein Ergebnis aus dem Cache zurückgeliefert.3 Auch wenn es praktisch ist, verwenden wir BENCHMARK( ) nicht für echte Benchmarks. Es ist einfach zu schwer festzustellen, was es wirklich misst, und beschränkt sich außerdem zu sehr auf einen kleinen Teil des gesamten Ausführungsprozesses.

Am einfachsten benutzt man http_load, indem man die URLs in einer Schleife abruft. Das Programm ruft sie so schnell wie möglich auf:3 $ http_load -parallel 1 -seconds 10 urls.txt 19 fetches, 1 max parallel, 837929 bytes, in 10.0003 seconds 44101.5 mean bytes/connection 1.89995 fetches/sec, 83790.7 bytes/sec msecs/connect: 41.6647 mean, 56.156 max, 38.21 min 3 Einer der Autoren machte diesen Fehler und stellte fest, dass 10.000 Ausführungen eines bestimmten Ausdrucks genauso schnell liefen wie eine Ausführung. Es war ein Cache-Ergebnis. Im Allgemeinen müssen Sie bei einem solchen Verhalten immer von einem Cache-Ergebnis oder einem Fehler ausgeben.

Benchmarking-Beispiele | 49

msecs/first-response: 320.207 mean, 508.958 max, 179.308 min HTTP response codes: code 200 – 19

Die Ergebnisse sind eigentlich selbsterklärend: Sie zeigen einfach Statistiken über die Anforderungen. Ein etwas komplexeres Benutzungsszenario sieht vor, dass die URLs so schnell wie möglich in einer Schleife abgerufen, damit aber fünf gleichzeitig agierende Benutzer emuliert werden: $ http_load -parallel 5 -seconds 10 urls.txt 94 fetches, 5 max parallel, 4.75565e+06 bytes, in 10.0005 seconds 50592 mean bytes/connection 9.39953 fetches/sec, 475541 bytes/sec msecs/connect: 65.1983 mean, 169.991 max, 38.189 min msecs/first-response: 245.014 mean, 993.059 max, 99.646 min HTTP response codes: code 200 – 94

Alternativ können wir, anstatt die URLs so schnell wie möglich abzurufen, die Last für eine vorherbestimmte Anforderungsrate (wie etwa fünf pro Sekunde) emulieren: $ http_load -rate 5 -seconds 10 urls.txt 48 fetches, 4 max parallel, 2.50104e+06 bytes, in 10 seconds 52105 mean bytes/connection 4.8 fetches/sec, 250104 bytes/sec msecs/connect: 42.5931 mean, 60.462 max, 38.117 min msecs/first-response: 246.811 mean, 546.203 max, 108.363 min HTTP response codes: code 200 – 48

Schließlich emulieren wir eine noch größere Last mit einer Rate von 20 eingehenden Anforderungen pro Sekunde. Beachten Sie, dass die Verbindungs- und Antwortraten mit höherer Last zunehmen: $ http_load -rate 20 -seconds 10 urls.txt 111 fetches, 89 max parallel, 5.91142e+06 bytes, in 10.0001 seconds 53256.1 mean bytes/connection 11.0998 fetches/sec, 591134 bytes/sec msecs/connect: 100.384 mean, 211.885 max, 38.214 min msecs/first-response: 2163.51 mean, 7862.77 max, 933.708 min HTTP response codes: code 200 -- 111

sysbench Das Programm sysbench kann eine Vielzahl von Benchmarks ausführen, die es als »Tests« bezeichnet. Es soll nicht nur die Datenbankleistung testen, sondern auch, wie gut ein System wahrscheinlich als Datenbankserver arbeiten wird. Wir beginnen mit einigen Tests, die nicht MySQL-spezifisch sind, und messen die Leistung für Subsysteme, die die Gesamtgrenzen des Systems bestimmen. Anschließend zeigen wir, wie die Datenbankleistung gemessen wird.

50 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

Der sysbench-CPU-Benchmark Der offensichtlichste Subsystemtest ist der CPU-Benchmark, der 64-Bit-Integer-Werte verwendet, um Primzahlen bis zu einem angegebenen Maximalwert zu berechnen. Wir führen diesen Test auf zwei Servern aus, die beide unter GNU/Linux laufen, und vergleichen die Ergebnisse miteinander. Hier sehen Sie die Hardware des ersten Servers: [server1 ~]$ cat /proc/cpuinfo ... model name : AMD Opteron(tm) Processor 246 stepping : 1 cpu MHz : 1992.857 cache size : 1024 KB

Und so führen wir den Benchmark aus: [server1 ~]$ sysbench --test=cpu --cpu-max-prime=20000 run sysbench v0.4.8: multi-threaded system evaluation benchmark ... Test execution summary: total time: 121.7404s

Der zweite Server besitzt eine andere CPU: [server2 ~]$ cat /proc/cpuinfo ... model name : Intel(R) Xeon(R) CPU stepping : 6 cpu MHz : 1995.005

5130

@ 2.00GHz

Hier ist sein Benchmark-Ergebnis: [server1 ~]$ sysbench --test=cpu --cpu-maxprime=20000 run sysbench v0.4.8: multi-threaded system evaluation benchmark ... Test execution summary: total time: 61.8596s

Das Ergebnis zeigt einfach die Gesamtzeit an, die erforderlich war, um die Primzahlen zu berechnen. Das lässt sich ganz leicht vergleichen. In diesem Fall führte der zweite Server den Benchmark fast doppelt so schnell aus wie der erste Server.

Der sysbench-Datei-Ein-/Ausgabe-Benchmark Der fileio-Benchmark misst, wie Ihr System unter verschiedenen Arten von Ein-/Ausgabe-Lasten arbeitet. Damit kann man Festplatten, RAID-Karten und RAID-Modi vergleichen und das Ein-/Ausgabe-Subsystem anpassen und verbessern. Zuerst müssen einige Dateien für den Benchmark vorbereitet werden. Sie sollten deutlich mehr Daten generieren, als in den Speicher passen. Passen die Daten komplett in den Speicher, schiebt das Betriebssystem die meisten von ihnen in den Cache, und das Ergebnis spiegelt die ein-/ausgabegebundene Last nicht korrekt wider. Wir erzeugen zuerst eine Datenmenge: $ sysbench --test=fileio --file-total-size=150G prepare

Benchmarking-Beispiele | 51

Im zweiten Schritt wird der Benchmark ausgeführt. Zum Testen verschiedener Arten von Ein-/Ausgabe-Leistung stehen mehrere Optionen zur Verfügung: seqwr

Sequenzielles Schreiben seqrewr

Sequenzielles Neuschreiben seqrd

Sequenzielles Lesen rndrd

Zufälliges Lesen rndwr

Zufälliges Schreiben rndrw

Kombiniertes zufälliges Lesen/Schreiben Der folgende Befehl führt den Benchmark mit zufälligem Lese-/Schreibzugriff aus: $ sysbench --test=fileio --file-total-size=150G --file-test-mode=rndrw --init-rnd=on --max-time=300 --max-requests=0 run

Hier sind die Ergebnisse: sysbench v0.4.8:

multi-threaded system evaluation benchmark

Running the test with following options: Number of threads: 1 Initializing random number generator from timer. Extra file open flags: 0 128 files, 1.1719Gb each 150Gb total file size Block size 16Kb Number of random requests for random IO: 10000 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync( ) each 100 requests. Calling fsync( ) at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Threads started! Time limit exceeded, exiting... Done. Operations performed: 40260 Read, 26840 Write, 85785 Other = 152885 Total Read 629.06Mb Written 419.38Mb Total transferred 1.0239Gb (3.4948Mb/sec) 223.67 Requests/sec executed Test execution summary: total time: 300.0004s total number of events: 67100 total time taken by event execution: 254.4601 per-request statistics:

52 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

min: avg: max: approx. 95 percentile: Threads fairness: events (avg/stddev): execution time (avg/stddev):

0.0000s 0.0038s 0.5628s 0.0099s

67100.0000/0.00 254.4601/0.00

Die Ausgabe enthält eine Menge an Informationen. Die interessantesten Zahlen zum Verfeinern des Ein-/Ausgabe-Subsystems sind die Anzahl der Anforderungen pro Sekunde und der Gesamtdurchsatz. In diesem Fall zeigen die Ergebnisse 223,67 Anforderungen/Sekunde bzw. 3,4948 MByte/Sekunde. Diese Werte liefern einen guten Hinweis auf die Performance der Festplatten. Wenn Sie fertig sind, löschen Sie die Dateien, die sysbench für die Benchmarks angelegt hat: $ sysbench --test=fileio –-file-total-size=150G cleanup

Der sysbench-OLTP-Benchmark Der OLTP-Benchmark emuliert die Last bei der Transaktionsverarbeitung. Wir zeigen ein Beispiel mit einer Tabelle, die eine Million Zeilen enthält. Der erste Schritt besteht darin, die Tabelle für den Test vorzubereiten: $ sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysqluser=root prepare sysbench v0.4.8: multi-threaded system evaluation benchmark No DB drivers specified, using mysql Creating table 'sbtest'... Creating 1000000 records in table 'sbtest'...

Das war schon die gesamte Vorbereitung. Nun lassen wir den Benchmark 60 Sekunden lang mit 8 nebenläufigen Threads im Read-Only-Modus laufen: $ sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --maxtime=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run sysbench v0.4.8: multi-threaded system evaluation benchmark No DB drivers specified, using mysql WARNING: Preparing of "BEGIN" is unsupported, using emulation (last message repeated 7 times) Running the test with following options: Number of threads: 8 Doing OLTP test. Running mixed OLTP test Doing read-only test Using Special distribution (12 iterations, Using "BEGIN" for starting transactions Using auto_inc on the id column Threads started!

1 pct of values are returned in 75 pct cases)

Benchmarking-Beispiele | 53

Time limit exceeded, exiting... (last message repeated 7 times) Done. OLTP test statistics: queries performed: read: write: other: total: transactions: deadlocks: read/write requests: other operations:

179606 0 25658 205264 12829 0 179606 25658

Test execution summary: total time: total number of events: total time taken by event execution: per-request statistics: min: avg: max: approx. 95 percentile: Threads fairness: events (avg/stddev): execution time (avg/stddev):

(213.07 per sec.) (0.00 per sec.) (2982.92 per sec.) (426.13 per sec.)

60.2114s 12829 480.2086 0.0030s 0.0374s 1.9106s 0.1163s

1603.6250/70.66 60.0261/0.06

Wie gehabt finden Sie auch hier viele Informationen in den Ergebnissen. Die interessantesten Teile sind: • der Transaktionszähler • die Rate der Transaktionen pro Sekunde • die Statistiken für die einzelnen Anforderungen (minimale, durchschnittliche und maximale Zeit sowie die Zeit des 95. Perzentils) • Statistiken für die Thread-Fairness, die zeigen, wie fair die simulierte Last war

Weitere sysbench-Funktionen Das sysbench-Programm kann verschiedene weitere System-Benchmarks ausführen, die nicht direkt die Leistung eines Datenbankservers messen: memory

Führt sequenzielle Speicher-Lese- oder Schreiboperationen aus. threads

Misst die Performance des Thread-Schedulers. Damit kann man vor allem das Verhalten des Schedulers unter hoher Last testen.

54 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

mutex

Misst die Mutex-Leistung, indem eine Situation emuliert wird, in der meist alle Threads parallel ablaufen, wobei nur kurzzeitig Mutex-Locks geholt werden. (Bei einem Mutex handelt es sich um eine Datenstruktur, die einen Zugriff unter wechselseitigem Ausschluss [engl. Mutual Exclusive] auf eine Ressource garantiert, so dass verhindert wird, dass ein nebenläufiger Zugriff Probleme verursacht.) seqwr

Misst die Leistung bei sequenziellen Schreiboperationen. Dies ist sehr wichtig, um die praktischen Leistungsgrenzen eines Systems zu testen. Es kann zeigen, wie gut der Cache Ihres RAID-Controllers funktioniert, und alarmiert Sie, wenn die Ergebnisse ungewöhnlich ausfallen. Falls Sie z.B. keinen batteriegesicherten SchreibCache haben, Ihre Platte aber 3.000 Anforderungen pro Sekunde erhält, dann stimmt etwas nicht und Ihre Daten sind nicht mehr sicher. Zusätzlich zum Benchmark-spezifischen Parameter (--test) akzeptiert sysbench weitere gebräuchliche Parameter, wie etwa --num-threads, --max-requests und --max-time. In der Dokumentation finden Sie Informationen dazu.

dbt2 TPC-C auf der Database Test Suite Das dbt2-Werkzeug der Database Test Suite ist eine freie Implementierung des TPC-CTests. TPC-C ist eine Spezifikation, die vom TPC (Transaction Processing Performing Council) veröffentlicht wurde und eine komplexe Online-Transaktionsverarbeitungslast emuliert. Es weist seine Ergebnisse in Transaktionen pro Minute (tpmC) aus, zusammen mit den Kosten für die einzelnen Transaktionen (Preis/tpmC). Die Ergebnisse hängen stark von der Hardware ab, weshalb veröffentlichte TPC-C-Ergebnisse ausführliche Spezifikationen der Server enthalten, die in dem Benchmark verwendet wurden. Der dbt2-Test ist eigentlich nicht TPC-C. Er ist nicht vom TPC zertifiziert, und seine Ergebnisse können auch nicht direkt mit TPC-C-Ergebnissen verglichen werden.

Schauen wir uns ein Beispiel für das Einrichten und Ausführen eines dbt2-Benchmarks an. Wir haben Version 0.37 von dbt2 verwendet. Das ist die neueste Version, die wir zusammen mit MySQL einsetzen konnten (neuere Versionen enthalten Erweiterungen, die MySQL nicht vollständig unterstützt). Wir haben folgende Schritte unternommen: 1. Vorbereitung der Daten

Der folgende Befehl erzeugt Daten für 10 Warehouses in dem angegebenen Verzeichnis. Die Warehouses nehmen zusammen einen Platz von etwa 700 MByte ein. Der erforderliche Platzbedarf ändert sich proportional zur Anzahl der Warehouses, Sie können also den Parameter -w ändern, um eine Datenmenge mit der von Ihnen benötigten Größe anzulegen.

Benchmarking-Beispiele | 55

# src/datagen -w 10 -d /mnt/data/dbt2-w10 warehouses = 10 districts = 10 customers = 3000 items = 100000 orders = 3000 stock = 100000 new_orders = 900 Output directory of data files: /mnt/data/dbt2-w10 Generating data files for 10 warehouse(s)... Generating item table data... Finished item table data... Generating warehouse table data... Finished warehouse table data... Generating stock table data...

2. Laden der Daten in die MySQL-Datenbank

Der nächste Befehl erzeugt eine Datenbank namens dbt2w10 und lädt in sie die Daten, die wir im vorhergehenden Schritt erzeugt haben (-d ist der Datenbankname, und -f ist das Verzeichnis mit den generierten Daten): # scripts/mysql/mysql_load_db.sh -d dbt2w10 -f /mnt/data/dbt2-w10 s /var/lib/mysql/mysql.sock

3. Ausführen des Benchmarks

Im letzten Schritt wird der folgende Befehl aus dem Verzeichnis scripts ausgeführt: # run_mysql.sh -c 10 -w 10 -t 300 -n dbt2w10 -u root -o /var/lib/mysql/mysql.sock -e ************************************************************************ * DBT2 test for MySQL started * * * * Results can be found in output/9 directory * ************************************************************************ * * * Test consists of 4 stages: * * * * 1. Start of client to create pool of databases connections * * 2. Start of driver to emulate terminals and transactions generation * * 3. Test * * 4. Processing of results * * * ************************************************************************ DATABASE NAME: DATABASE USER: DATABASE SOCKET: DATABASE CONNECTIONS: TERMINAL THREADS: SCALE FACTOR(WARHOUSES): TERMINALS PER WAREHOUSE: DURATION OF TEST(in sec): SLEEPY in (msec) ZERO DELAYS MODE:

56 |

dbt2w10 root /var/lib/mysql/mysql.sock 10 100 10 10 300 300 1

Kapitel 2: Engpässe finden: Benchmarking und Profiling

Stage 1. Starting up client... Delay for each thread 300 msec. Will sleep for 4 sec to start 10 database connections CLIENT_PID = 12962 Stage 2. Starting up driver... Delay for each thread 300 msec. Will sleep for 34 sec to start 100 terminal threads All threads has spawned successfuly. Stage 3. Starting of the test. Duration of the test 300 sec Stage 4. Processing of results... Shutdown clients. Send TERM signal to 12962. Response Time (s) Transaction % Average : 90th % Total ------------ ----- ----------------- -----Delivery 3.53 2.224 : 3.059 1603 New Order 41.24 0.659 : 1.175 18742 Order Status 3.86 0.684 : 1.228 1756 Payment 39.23 0.644 : 1.161 17827 Stock Level 3.59 0.652 : 1.147 1630

Rollbacks --------0 172 0 0 0

% ----0.00 0.92 0.00 0.00 0.00

3396.95 new-order transactions per minute (NOTPM) 5.5 minute duration 0 total unknown errors 31 second(s) ramping up

Das wichtigste Ergebnis ist diese Zeile kurz vor dem Ende: 3396.95 new-order transactions per minute (NOTPM)

Sie zeigt uns, wie viele Transaktionen pro Minute das System verarbeiten kann – je mehr, desto besser. (Der Begriff »new-order« steht nicht für eine bestimmte Art von Transaktion, sondern bedeutet einfach, dass der Test jemanden simuliert hat, der eine neue Bestellung auf der imaginären E-Commerce-Website abgegeben hat.) Sie können einige der Parameter ändern, um andere Benchmarks zu erzeugen: -c

-e

-t

Die Anzahl der Verbindungen zur Datenbank. Sie können dies ändern, um unterschiedliche Nebenläufigkeitsstufen zu emulieren und festzustellen, wie das System skaliert. Dies aktiviert den Zero-Delay-Modus, was bedeutet, dass es zwischen den Abfragen keine Verzögerungen gibt. Das ist ein Stresstest für die Datenbank, der aber in gewisser Weise unrealistisch ist, da echte Benutzer Zeit zum Nachdenken benötigen, bevor sie neue Abfragen generieren. Die Gesamtdauer des Benchmarks. Wählen Sie diese Zeit sorgfältig, da Ihre Ergebnisse ansonsten keine Bedeutung haben. Eine zu kurze Zeit für den Benchmark-Test einer ein-/ausgabegebundenen Last liefert unkorrekte Ergebnisse, da das System nicht genug Zeit hat, um die Caches zu füllen und eine normale Arbeit zu beginnen. Falls Sie andererseits eine CPU-gebundene Last einem Benchmark unterziehen wollen, dürfen Sie die Zeit nicht zu lang wählen, da sonst die Datenmenge möglicherweise zu stark anwächst und ein-/ausgabegebunden wird. Benchmarking-Beispiele | 57

Die Ergebnisse dieses Benchmarks können Informationen über mehr als nur die Performance liefern. Falls Sie z.B. zu viele Rollbacks sehen, wissen Sie, dass wahrscheinlich etwas nicht stimmt.

Die MySQL-Benchmark-Suite Die MySQL-Benchmark-Suite besteht aus einem Satz von Perl-Benchmarks; Sie brauchen also Perl, um sie auszuführen. Sie finden die Benchmarks im Unterverzeichnis sql-bench/ Ihrer MySQL-Installation. Auf Debian GNU/Linux-Systemen befinden sie sich z.B. in /usr/share/mysql/sql-bench/. Bevor Sie beginnen, lesen Sie die mitgelieferte README-Datei, in der erläutert wird, wie die Suite benutzt wird, und die die Kommandozeilenargumente dokumentiert. Um alle Tests auszuführen, verwenden Sie solche Befehle: $ cd /usr/share/mysql/sql-bench/ sql-bench$ ./run-all-tests --server=mysql --user=root --log --fast Test finished. You can find the result in: output/RUN-mysql_fast-Linux_2.4.18_686_smp_i686

Die Ausführung der Benchmarks kann, je nach verwendeter Hardware und Konfiguration, länger als eine Stunde dauern. Wenn Sie die Kommandozeilenoption --log angeben, dann können Sie den Fortschritt während der Abarbeitung beobachten. Die Tests schreiben ihre Ergebnisse in ein Unterverzeichnis namens output. Jede Datei besteht aus einer Reihe von Zeitangaben für die Operationen in dem jeweiligen Benchmark. Hier ist ein Ausschnitt, der für den Druck nur ein wenig schöner formatiert wurde: sql-bench$ tail -5 output/select-mysql_fast-Linux_2.4.18_686_smp_i686 Time for count_distinct_group_on_key (1000:6000): 34 wallclock secs ( 0.20 usr 0.08 sys + 0.00 cusr 0.00 csys = 0.28 Time for count_distinct_group_on_key_parts (1000:100000): 34 wallclock secs ( 0.57 usr 0.27 sys + 0.00 cusr 0.00 csys = 0.84 Time for count_distinct_group (1000:100000): 34 wallclock secs ( 0.59 usr 0.20 sys + 0.00 cusr 0.00 csys = 0.79 Time for count_distinct_big (100:1000000): 8 wallclock secs ( 4.22 usr 2.20 sys + 0.00 cusr 0.00 csys = 6.42 Total time: 868 wallclock secs (33.24 usr 9.55 sys + 0.00 cusr 0.00 csys = 42.79

CPU) CPU) CPU) CPU) CPU)

Der count_distinct_group_on_key (1000:6000)-Test brauchte z.B. für die Ausführung 34 »Wall-Clock-Sekunden« (also echte Sekunden). Das ist die Gesamtzeit, die der Client für die Ausführung des Tests benötigte. Die anderen Werte (usr, sys, cursr, csys), die sich zu 0,28 aufsummiert haben, geben den Overhead für diesen Test an. So viel Zeit wurde also zum Ausführen des Client-Codes aufgebracht, anstatt auf die Antwort des MySQL-Servers zu warten. Der für uns interessante Wert – also die Zeit, die mit Dingen verbracht wurde, die nicht der Kontrolle des Clients unterliegen – beträgt daher 33,72 Sekunden. Statt der gesamten Suite können Sie die Tests auch einzeln ausführen. Vielleicht wollen Sie sich z.B. auf den Insert-Test konzentrieren. Dieser bietet Ihnen mehr Details als die Zusammenfassung, die von der kompletten Test-Suite erzeugt wird:

58 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

sql-bench$ ./test-insert Testing server 'MySQL 4.0.13 log' at 2003-05-18 11:02:39 Testing the speed of inserting data into 1 table and do some selects on it. The tests are done with a table that has 100000 rows. Generating random keys Creating tables Inserting 100000 rows in order Inserting 100000 rows in reverse order Inserting 100000 rows in random order Time for insert (300000): 42 wallclock secs ( 7.91 usr 5.03 sys + Testing insert of duplicates Time for insert_duplicates (100000): 16 wallclock secs ( 2.28 usr 1.89 sys +

0.00 cusr

0.00 csys = 12.94 CPU)

0.00 cusr

0.00 csys =

4.17 CPU)

Profiling Beim Profiling erfahren Sie, wie stark die einzelnen Teile eines Systems zu den Gesamtkosten beitragen, die zum Herstellen eines Ergebnisses nötig sind. Das einfachste Maß für die Kosten ist die Zeit. Beim Profiling kann aber auch die Anzahl der Funktionsaufrufe, Ein-/Ausgabe-Operationen, Datenbankabfragen usw. gemessen werden. Das Ziel besteht darin, zu verstehen, weshalb ein System so arbeitet, wie es das tut.

Eine Anwendung profilieren Wie beim Benchmarking können Sie ein Profil auf Anwendungsebene oder auf einer einzelnen Komponente, wie dem MySQL-Server, erstellen. Ein Profiling auf Anwendungsebene liefert normalerweise eine bessere Einsicht in die Frage, wie man die Anwendung optimieren kann, und stellt genauere Ergebnisse bereit, da die Ergebnisse die Arbeit umfassen, die von der gesamten Anwendung geleistet wurde. Falls Sie etwa die MySQLAbfragen der Anwendung optimieren wollen, werden Sie möglicherweise versucht sein, die Abfragen auszuführen und zu analysieren. In diesem Fall verpassen Sie allerdings viele wichtige Informationen über die Abfragen, wie etwa Einblicke in die Arbeit, die die Anwendung erledigen muss, wenn die Ergebnisse in den Speicher gelesen und verarbeitet werden.4 Da Webanwendungen einen sehr verbreiteten Anwendungsfall für MySQL darstellen, verwenden wir eine PHP-Website als Beispiel. Typischerweise müssen Sie die Anwendung global profilieren, um festzustellen, wie das System geladen wurde. Vielleicht wol-

4 Wenn Sie einen Engpass untersuchen, dann können Sie das möglicherweise abkürzen und feststellen, wo er liegt, indem Sie einige grundlegende Systemstatistiken unter die Lupe nehmen. Falls die Webserver untätig sind und der MySQL-Server 100 % der CPU nutzt, müssen Sie wahrscheinlich nicht die gesamte Anwendung profilieren, vor allem, wenn es dringend ist. Die ganze Anwendung können Sie sich immer noch anschauen, nachdem Sie die Krise überwunden haben.

Profiling | 59

len Sie aber auch einige interessante Subsysteme isolieren, wie etwa die Suchfunktion. Jedes teure, d.h. aufwendige Subsystem bildet einen guten Kandidaten für ein isoliertes Profiling. Wenn wir optimieren müssen, wie eine PHP-Website MySQL verwendet, dann ziehen wir es vor, Statistiken über die Granularität der Objekte (oder Module) im PHP-Code zu sammeln. Das Ziel besteht darin, zu messen, wie viel der Antwortzeit der einzelnen Seiten von den Datenbankoperationen verbraucht wird. Der Zugriff auf die Datenbank stellt in Anwendungen oft, aber nicht immer, den Flaschenhals dar. Flaschenhälse können auch von folgenden Faktoren verursacht werden: • externen Ressourcen, wie etwa Aufrufen an Webservices oder Suchmaschinen • Operationen, die die Verarbeitung großer Datenmengen in der Anwendung erfordern, wie etwa das Parsen großer XML-Dateien • aufwendigen Operationen in engen Schleifen, wie beim Missbrauch von regulären Ausdrücken • schlecht optimierten Algorithmen, wie etwa naiven Suchalgorithmen zum Suchen von Objekten in Listen Bevor Sie sich MySQL-Abfragen anschauen, müssen Sie die tatsächliche Quelle Ihrer Performance-Probleme ermitteln. Das Profiling von Anwendungen kann Sie bei der Suche nach Engpässen unterstützen und ist ein wichtiger Schritt bei der Überwachung und Verbesserung der Gesamtleistung.

Wie und was gemessen wird Für die meisten Anwendungen ist die Zeit ein gutes Maß für das Profiling, da die meisten Benutzer sich am meisten um die Zeit sorgen. Bei Webanwendungen benutzen wir gern einen Debug-Modus, der für jede Seite die Abfragen zusammen mit ihren Zeiten und der Anzahl der Zeilen anzeigt. Bei langsamen Abfragen können wir dann EXPLAIN ausführen (in späteren Kapiteln finden Sie weitere Informationen über EXPLAIN). Zur genaueren Analyse kombinieren wir diese Daten mit Maßen vom MySQL-Server. Wir empfehlen Ihnen, in jedes neue Projekt, das Sie beginnen, Profiling-Code aufzunehmen. Bei bestehenden Anwendungen mag es schwierig sein, in eine neue Anwendung können Sie dagegen leicht Profiling-Code einbinden. Viele Bibliotheken enthalten Funktionen, die das erleichtern. So besitzen etwa Javas JDBC und PHPs mysqli Funktionen für das Profiling des Datenbankzugriffs. Profiling-Code ist darüber hinaus ausgesprochen sinnvoll zum Verfolgen seltsamer Probleme, die nur im Betrieb auftreten und in der Entwicklung nicht reproduziert werden können. Ihr Profiling-Code sollte wenigstens die folgenden Daten sammeln und protokollieren: • die Gesamtausführungszeit oder »Wall-Clock«-Zeit (Bei Webanwendungen ist das die Gesamtzeit zum Seitenaufbau.)

60 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

• jede ausgeführte Abfrage sowie deren Ausführungszeit • jede Verbindung, die zum MySQL-Server geöffnet wurde • jeden Aufruf einer externen Ressource, wie etwa von Webservices, memcached und extern ausgeführten Skripten • potenziell teure Funktionsaufrufe, wie etwa XML-Analysen • Benutzer- und System-CPU-Zeit Mit diesen Informationen können Sie die Leistung besser überwachen. Sie liefern Ihnen Einblicke in die Performance, die Sie sonst nur schwer erlangen können, wie etwa: • • • •

globale Leistungsprobleme sporadisch erhöhte Antwortzeiten Systemengpässe, die nicht bei MySQL liegen müssen Ausführungszeiten »unsichtbarer« Benutzer, wie etwa der Spider von Suchmaschinen

Bremst Profiling Ihre Server? Ja. Profiling und routinemäßige Überwachung erhöhen den Overhead. Die wichtigen Fragen lauten, wie viel Overhead sie hinzufügen und ob der Vorteil den zusätzlichen Aufwand rechtfertigt. Viele Leute, die leistungsstarke Anwendungen entwerfen und herstellen, glauben, dass man alles messen muss, was messbar ist, und dass man die Kosten des Messens einfach als Teil der Arbeit der Anwendung akzeptieren sollte. Selbst wenn Sie dem nicht zustimmen, ist es doch eine gute Idee, wenigstens eine Art von leichtem Profiling hinzuzufügen, das Sie permanent aktivieren können. Es ist schließlich nicht lustig, auf einen Leistungsengpass zu treffen, den Sie nicht kommen sahen, weil Ihre Systeme nicht darauf ausgelegt sind, täglich auftretende Leistungsänderungen zu erfassen. Wenn Ihnen ein Problem auffällt, können historische Daten von unschätzbarem Wert sein. Mithilfe von Profiling-Daten ist es sogar möglich, Hardware-Anschaffungen zu planen, Ressourcen zuzuweisen und die Last für Spitzenzeiten vorherzusagen. Was meinen wir mit »leichtem« Profiling? Das Aufzeichnen der Zeiten für die SQL-Abfragen sowie der Gesamtausführungszeit des Skripts ist mit Sicherheit nicht sehr teuer. Sie müssen dies auch nicht für jeden Seitenaufruf erledigen. Bei einem anständigen Verkehrsaufkommen können Sie auch einfach ein zufälliges Sample profilieren, indem Sie in der Setup-Datei Ihrer Anwendung das Profiling aktivieren:

Schon das Profiling von 1 % Ihrer Seitenbesuche sollte Ihnen dabei helfen, die schlimmsten Probleme zu finden. Denken Sie daran, die Kosten für Logging, Profiling und Messungen mit in Ihre Betrachtungen aufzunehmen, wenn Sie Benchmarks ausführen, da diese Ihre Benchmark-Ergebnisse verfälschen können.

Profiling | 61

Ein PHP-Profiling-Beispiel Um Ihnen eine Vorstellung davon zu vermitteln, wie einfach und unauffällig das Profiling einer PHP-Webanwendung sein kann, wollen wir uns einige Codebeispiele anschauen. Das erste Beispiel zeigt, wie man die Anwendung anpasst, die Abfragen und weitere Profiling-Daten in einer MySQL-Tabelle aufzeichnet und die Ergebnisse analysiert. Um die Wirkung des Logging zu reduzieren, erfassen wir alle Logging-Informationen im Speicher und schreiben sie erst dann in eine einzelne Zeile, wenn die Ausführung der Seite beendet ist. Das ist besser, als wenn man jede Abfrage einzeln protokolliert, da das Logging jeder einzelnen Abfrage die Anzahl der Abfragen verdoppelt, die an den MySQLServer gesandt werden müssen. Das separate Protokollieren aller Profiling-Daten würde es noch schwerer machen, Engstellen zu analysieren, da Sie selten eine solche Granularität vorfinden, um Probleme in der Anwendung zu erkennen und zu beheben. Wir beginnen mit dem Code, den Sie benötigen, um die Profiling-Informationen zu erfassen. Hier ist ein vereinfachtes Beispiel einer grundlegenden PHP-5-Logging-Klasse namens class.Timer.php, in die bereits Funktionen wie getrusage( ) integriert sind, um den Ressourceneinsatz des Skripts festzustellen: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

62 |



Es ist ganz leicht, die Timer-Klasse in Ihrer Anwendung einzusetzen. Sie müssen potenziell teure (oder anderweitig interessante) Aufrufe einfach mit dem Timer umhüllen. Und so packen Sie z.B. einen Timer um jede MySQL-Abfrage. Die neue PHP-Schnittstelle mysqli erlaubt es Ihnen, die grundlegende Klasse mysqli zu erweitern und die Methode query neu zu deklarieren: 1 2 3 4 5 6 7 8 9 10 11



Profiling | 63

Diese Technik erfordert nur wenige Codeänderungen. Sie können einfach mysqli global auf mysqlx ändern, und Ihre Anwendung beginnt, alle Abfragen zu protokollieren. Mit diesem Ansatz haben Sie die Möglichkeit, den Zugriff auf jede externe Ressource zu messen, wie etwa Abfragen an die Volltextsuchmaschine Sphinx: $timer->startTime('Sphinx'); $this->sphinxres = $this->sphinx_client->Query ( $query, "index" ); $timer->stopTime('Sphinx', "Query: $query\n");

Jetzt wollen wir uns anschauen, wie wir die Daten aufzeichnen, die Sie sammeln. In diesem Beispiel wäre es klug, die Storage-Engine MyISAM oder Archive zu verwenden. Beide eignen sich gut zum Speichern von Logs. Wir benutzen INSERT DELAYED, wenn wir Zeilen zu den Logs hinzufügen, damit das INSERT auf dem Datenbankserver als Hintergrund-Thread ausgeführt wird. Dies bedeutet, dass die Abfrage sofort zurückkehrt und damit die Antwortzeit der Anwendung nicht merklich beeinflusst. (Selbst wenn wir nicht INSERT DELAYED benutzen, geschieht das Einfügen nebenläufig, solange wir es nicht ausdrücklich deaktivieren, so dass externe SELECT-Abfragen nicht das Logging blockieren.) Schließlich richten wir ein datumsbasiertes Partitionierungsschema ein, indem wir jeden Tag eine neue Log-Tabelle anlegen. Hier ist die CREATE TABLE-Anweisung für unsere Logging-Tabelle: CREATE TABLE logs.performance_log_template ( ip INT UNSIGNED NOT NULL, page VARCHAR(255) NOT NULL, utime FLOAT NOT NULL, wtime FLOAT NOT NULL, mysql_time FLOAT NOT NULL, sphinx_time FLOAT NOT NULL, mysql_count_queries INT UNSIGNED NOT NULL, mysql_queries TEXT NOT NULL, stime FLOAT NOT NULL, logged TIMESTAMP NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, user_agent VARCHAR(255) NOT NULL, referer VARCHAR(255) NOT NULL ) ENGINE=ARCHIVE;

Tatsächlich fügen wir niemals Daten in diese Tabelle ein; es handelt sich nur um ein Template für die CREATE TABLE LIKE-Anweisungen, die wir benutzen, um die Tabellen für die Daten der einzelnen Tage anzulegen. Mehr dazu erläutern wir in Kapitel 3. Im Moment sollten Sie nur wissen, dass es ganz gut ist, wenn man den kleinsten Datentyp benutzt, der die vorgesehenen Daten aufnehmen kann. Wir verwenden ein vorzeichenloses Integer, um die IP-Adresse zu speichern. Darüber hinaus verwenden wir eine 255 Zeichen lange Spalte für die Seite und den Referrer. Diese Werte können länger als 255 Zeichen sein, allerdings genügen für unsere Zwecke normalerweise die ersten 255.

64 |

Kapitel 2: Engpässe finden: Benchmarking und Profiling

Das letzte Stück des Puzzles besteht darin, die Ergebnisse aufzuzeichnen, wenn die Ausführung der Seite beendet ist. Hier ist der dazu notwendige PHP-Code: 1 2 3 4 5 6 7 8 9



Die Timer-Klasse verwendet die Helper-Klasse DBQueryLog, die dafür verantwortlich ist, dass in die Datenbank protokolliert und jeden Tag eine neue Log-Tabelle erzeugt wird. Hier ist der Code: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30