Moderne MySQL-Forks und -Patches

Wer die Wahl hat…

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 gepatchten Versionen das Feld deutlich unübersichtlicher geworden. Höchste Zeit, sich einen Überblick über die wichtigsten Angebote zu verschaffen.

Ist der MySQL-Server zu langsam, gibt es verschiedene Lösungsstrategien: neben dem Optimieren von Abfragen und Indizes [1], Ü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

Viele Verbesserungen für MySQL kommen von großen Unternehmen wie Facebook [2] und Google [3], das unter anderem seinen Adwords-Dienst auf der Basis von MySQL betreibt, wie auch von MySQL-Spezialisten wie Percona [4], die durch das zur Pflichtlektüre gewordene MySQL Performance Blog [5] 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 http://ourdelta.org Repositories 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 Hinweisung zur Nutzung online einsehbar ist [6].

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 Livebetrieb 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 schreib-intensive Tabelle »movies« mit zugleich hoher Anzahl von Index-Aktualisierungen.

Listing 1

Der Userstats-Patch im Einsatz

mysql> select * from information_schema.TABLE_STATISTICS ORDER BY ROWS_READ DESC LIMIT 0,5;
+--------------------+---------------+-------------+--------------+------------------------+
| TABLE_SCHEMA       | TABLE_NAME    | ROWS_READ   | ROWS_CHANGED | ROWS_CHANGED_X_INDEXES |
+--------------------+---------------+-------------+--------------+------------------------+
| moviepilot         | images        | 13138219791 |        14778 |                 118224 |
| moviepilot         | events        |  3957858216 |        59964 |                 359784 |
| moviepilot         | comments      |  2650553183 |         3408 |                  20448 |
| moviepilot         | movies        |  2013076357 |       598505 |                7780565 |
| omdb               | log_entries   |  1106683022 |         2737 |                   5474 |
+--------------------+---------------+-------------+--------------+------------------------+

Da sich die Statistiken zum Beispiel per »FLUSH TABLE_STATISTICS« bequem zurückgesetzen lassen, bietet sich eine Intervall-basiertes 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.

Ähnliche Artikel

comments powered by Disqus
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Ausgabe  04/2014