MySQL-Performance-Tuning durch neue Datenbank-Engines
Moderne MySQL-Forks und -Patches
MySQL ist die Standard-Lösung für freie relationale Datenbank-Systeme im Web-Bereich. In den letzten Jahren ist durch neue Forks, weitere Storage-Engines und gepatchte Versionen das Feld deutlich unübersichtlicher geworden. Höchste Zeit, sich einen Überblick über die wichtigsten Angebote zu verschaffen.
Einleitung
Ist der MySQL-Server zu langsam, gibt es verschiedene Lösungsstrategien: neben dem Optimieren von Abfragen und Indizes, Überarbeiten der Konfiguration und Aufrüsten der Hardware bietet sich der Umstieg auf eine angepasste Version des MySQL-Servers an. In den letzten Jahren wurde eine kaum überschaubare Anzahl an Patches, Forks und neuen Storage-Engines veröffentlicht. Für anspruchsvolle Entwickler und Datenbank-Administratoren bedeutet dies eine Abkehr von der einfachen Wahl der MySQL-Standard-Distribution.
Kleine Pflaster
){kind=small}
Admin-Magazin
MySQL-Forks
Viele Verbesserungen für MySQL kommen von großen Unternehmen wie Facebook und Google, das unter anderem seinen Adwords-Dienst auf der Basis von MySQL betreibt, wie auch von MySQL-Spezialisten wie Percona, die durch das zur Pflichtlektüre gewordene MySQL Performance Blog bekannt wurden. Prinzipiell lassen sich die Patches in drei Kategorien einteilen: 1. Verbesserungen am Reporting, 2. Funktionserweiterungen des MySQL-Kerns und der Datenbank-Engines, 3. reine Performance-Optimierungen.
In der Regel erweist sich ein Zusammenspiel von Patches aus allen drei Kategorien als sinnvoll. Der Umstieg auf einen selbst gepatchten und kompilierten Datenbankserver mag jedoch abschrecken. Erfreulicherweise bieten Projekte wie ourdelta.org Repositorien mit sinnvoll gepatchten und vorkompilierten MySQL-Paketen für gängige Distributionen wie Debian, Ubuntu und CentOS/RHEL an. Die im folgenden besprochenen Patches sind ein Auszug aus den aktuellen Ourdelta.org-Versionen des MySQL-Servers, deren vollständige Patch-Liste mit Hinweisen zur Nutzung online einsehbar ist.
Reporting
Ein erweitertes Reporting ermöglicht es, genauere Daten über das Verhalten des MySQL-Servers unter Last zu sammeln. Bisher war vor allem das wenig konfigurierbare »slow.log« erste Anlaufstelle. Dessen Nutzen beschränkte sich aber darauf, einzelne rechenintensive Queries anhand verbrauchter Zeit und nicht genutzter Indizes aufzuspüren. Der Patch »Microslow« bietet neue Filter, um gezielter nach ungünstig formulierten Abfragen zu suchen. So können Queries geloggt werden, die für das Schreiben temporärer Tabellen auf der Festplatte, vollständige Tabellen-Scans oder das Lesen einer frei definierbaren Mindestzahl von Tabellenzeilen verantwortlich sind. Das eher unbekannte, aber zur MySQL-Standard-Distribution gehörende Slow.log-Statistik-Tool »mysqldumpslow« ist so angepasst, dass es auch die erweiterten Einträge einlesen und auswerten kann.
Ebenso hilfreich sind kumulierte Laufzeit-Statistiken über das tatsächliche Nutzungsverhalten. Der Userstats-Patch erweitert MySQL hierfür um Statistiken für Benutzer, Clients, Tabellen und Indizes. Nachdem der Administrator die Datensammlung in der my.cnf oder zur Laufzeit per SQL-Befehl SET GLOBAL userstat_running = 1 aktiviert hat, befüllt MySQL die vier Tabellen USER_STATISTICS, CLIENT_STATISTICS, INDEX_STATISTICS und TABLE_STATISTICS im Schema information_schema kontinuierlich mit statistischen Daten. Die Statistiken lassen sich über den SHOW-Befehl abrufen. Ein SHOW TABLE_STATISTICS zeigt entsprechend eine tabellenweise Auswertung über gelesene Zeile, geänderte Zeilen und aktualisierte Indizes.
Besonders hilfreich ist der direkte Zugriff auf die Statistik-Tabellen in information_schema, da diese als normale Tabelle angesprochen und die Ergebnisse gezielt manipuliert werden können. Listing 1 zeigt eine Abfrage nach den fünf Tabellen mit den meistgelesenen Zeilen. Dieses Beispiel aus dem Live-Betrieb der Rails-basierten Film-Community Moviepilot und der zugrunde liegenden Film-Datenbank OMDB (beide für diese Auswertung anonymisiert) zeigt einen auffällig häufigen Lese-Zugriff auf die images-Tabelle. Im nächsten Schritt kann der Datenbankanwender ausprobieren, ob Code-Optimierungen die Zugriffe minimieren können oder weitere Änderungen am Format der Tabelle Zeitersparungen bringen. Verdächtig ist außerdem die verhältnismäßig schreibintensive Tabelle movies mit zugleich hoher Anzahl von Index-Aktualisierungen.
| Listing 1: Der Userstats-Patch im Einsatz |
|---|
01 mysql> select * from information_schema.TABLE_STATISTICS ORDER BY ROWS_READ DESC LIMIT 0,5; |
Da sich die Statistiken zum Beispiel per FLUSH TABLE_STATISTICS bequem zurücksetzen lassen, bietet sich eine Intervall-basierte Auswertung über ein selbst geschriebenes Munin-Plugin oder ähnliche Methoden an. Hier kann der Administrator nachträglich Lastspitzen in Relation zur Tabellen-Zugriffen und -Änderungen untersuchen.
