MySQL Falcon (Teil II):

Transaktionspower: Performance-Vergleich Falcon vs. InnoDB

In Ausgabe 2/2008 [1] stellten wir Ihnen die neue Storage Engine Falcon vor. Nun möchten wir diesen neuen Tabellentyp genauer untersuchen und einen Vergleichstest mit InnoDB, dem heutigen "Marktführer" unter den transaktionsfähigen MySQL-Engines, vornehmen. Wer von beiden bietet die bessere Performance?

//define a query query "select_by_number" { query "select * from fmitarbeiter where mitarbeiternr = '$word'"; // $word will be substitute with the read from // the 'word' dictionary type "select"; // query stats will be grouped by type has_result_set "y"; // the query is expected to return a result set parsed "y"; // the query string should be first processed by // super-smack to do dictionary substitution } ... //define a query query "delete_by_number" { query "delete from fmitarbeiter where mitarbeiternr = '$word'"; // $word will be substitute with the read // from the 'word' dictionary type "delete"; // query stats will be grouped by type has_result_set "y"; // the query is expected to return a result set parsed "y"; // the query string should be first processed by // super-smack to do dictionary substitution } // define database client type client "smacker1" { user "test"; // connect as this user pass ""; // use this password host "localhost"; // connect to this host db "test"; // switch to this database socket "/tmp/mysql.sock"; // this only applies to MySQL and is // ignored for PostgreSQL query_barrel "14 select_by_number 4 update_by_number 1 delete_by_number 1 insert"; // on each round, // run select_by_username query 2 times } ... Abb. 1: SMACK: Auszüge aus einem Benchmark-Szenario. CREATE TABLE 'mitarbeiter' ( 'mitarbeiternr' int(11) DEFAULT NULL, 'nachname' varchar(40) DEFAULT NULL, 'vorname' varchar(40) DEFAULT NULL, 'gehalt' int(11) DEFAULT NULL, 'beruf' varchar(40) DEFAULT NULL, 'mail' varchar(40) DEFAULT NULL, 'eintrittsdatum' int(11) DEFAULT NULL, 'abteilungsnr' int(11) DEFAULT NULL, KEY 'i_pk' ('mitarbeiternr') ) ENGINE=InnoDB DEFAULT CHARSET=latin Abb. 2: Das Datenmodell des Performance-Tests. Abb. 3: Nutzungsmuster inklusive der dahinterstehenden SQL-Befehle. shell> super-smack szenario.smack 5 100 Query Barrel Report for client smacker1 connect: max=48ms min=6ms avg= 26ms from 5 clients Query_type num_queries max_time min_time q_per_s delete 500 0 0 321.70 insert 500 8 0 321.70 select 7000 0 0 4503.84 update 2000 0 0 1286.81 Abb. 4: Performance-Testergebnis: Gemessen wurden die einzelnen Teilkomponenten des Barrel, wenn 5 Clients das Query Barrel jeweils 100x ausführen. Falcon Parameter --falcon_min_record_memory=500M --falcon_max_record_memory=500M --falcon_page_cache_size=500M InnoDB Parameter --key-buffer-size=500M --innodb-buffer-pool-size=500M --innodb-log-file-size25M --innodb-thread-concurrency=8 Abb. 5: Parameter zur Einstellung der spezifischen Cache-Bereiche. Abb. 6: Auswertung SELECT: Anzahl der m&öglichen SELECT-Statements pro Sekunde in Abhängigkeit von der jeweiligen Storage Engine. Abb. 7: Auswertung UPDATE: Anzahl der möglichen UPDATE-Statements pro Sekunde in Abhängigkeit von der jeweiligen Storage Engine. Abb. 8: Auswertung Testszenario: Auch beim kombinierten Test gibt es keine Überraschungen. Falcon ist in diesem(!) Szenario InnoDB deutlich überlegen.

Wer, Wie, Was?

Performance-Messungen bzw. Benchmarktests sind schwierige Aufgaben im Leben eines Datenbankadministrators. Vor der eigentlichen Messung sind zunächst einige wichtige Fragen zu klären:

• Gibt es ein Datenmodell inklusive Daten, das für die Messung verwendet werden kann?
• Handelt es sich um reale Daten oder müssen Testdaten generiert werden (und wenn ja, wie)?
• Sollen mehrere Anwender simuliert werden (Lasttest-Szenario)?
• Gibt es ein geeignetes Tool, welches für die Messung verwendet werden kann, bzw. wie kann ein Anwenderverhalten sinnvoll simuliert werden?

Das Werkzeug: Super Smack

Beginnen wir zunächst mit der letzten Frage. Auf dem Open Source Markt sind viele kleine Skripte und Programme verfügbar, mit denen Performance- und/oder Lasttests gegen My-SQL gefahren werden können.

Ein wirklich brauchbares Werkzeug ist das von Sacha Pachev entwickelte und von Jeremy Zawodny geförderte Super Smack [2]. Zwar wurde dieses Werkzeug seit längerem nicht weiterentwickelt (zumindest ist dem Autor nichts bekannt), allerdings hat dies keine negativen Auswirkungen auf die Anwendung. Die aktuelle Version 1.2 vom Stand September 2003 ist auch mit den neuesten MySQL-Versionen voll kompatibel.

Super Smack kann übrigens auch für Oracle und PostgreSQL verwendet werden.

Negativ stößt lediglich die Tatsache auf, dass die Dokumentation zu Super Smack nicht sehr umfangreich ist. Der geneigte Anwender muss sich mit einem 83-zeiligen Tutorial begnügen. In Kombinationen mit den beiden mitgelieferten Beispielszenarien sollte aber jeder erfahrene MySQL-Datenbankadministrator in der Lage sein, sich seine eigene Teststellung aufzubauen. Darüber hinaus lohnt sich eventuell auch ein Blick in das Buch "High Performance MySQL" [3] von Jeremy Zawodny, in dem das Tool ebenfalls beschrieben wird.

Bedienungsanleitung

Das Tool Super Smack bedient sich so genannter "smacks", frei definierbarer Testszenarien, die gegen die Datenbank ausgeführt werden können. Im Wesentlichen bestehen diese "smacks" aus Query Barrels, die wiederum aus einzelnen, frei wählbaren SQL-Statements zusammengesetzt sind. Ein Query Barrel sollte dabei einen typischen Nutzerzugriff simulieren. Die Teilkomponenten eines Barrel (also die einzelnen SQL-Statements) können unterschiedlich gewichtet werden. Hierzu kann einfach die Anzahl der Ausführungen der Teilkomponenten festgelegt werden.

Abbildung 1 zeigt Auszüge aus einem Benchmark-Szenario. Rot hervorgehoben sind die Teilkomponenten des Barrel - in diesem Fall ein SELECT- und ein DELETE-Statement - sowie die Gewichtung der Teilkomponenten im Barrel.

Da für eine sinnvolle Messung auch Testdaten benötigt werden, liefert Super Smack ein weiteres Tool gleich mit: GEN-DATA. Mit Hilfe dieses Werkzeuges können im Bedarfsfall schnell Testdaten generiert und in die Datenbank geladen werden.

Testszenario

Für unseren Vergleichstest wählen wir ein recht einfaches Datenmodell, welches lediglich aus einer einzigen Tabelle besteht (siehe Abbildung 2). Neben der Tabelle wurde ein Primärschlüssel (und damit ein unique Index) auf die Spalte mitarbeiternr gelegt. Die Tabelle repräsentiert Mitarbeiterstammdaten einer fiktiven Firma. Durch eine Protokollierung des Anwenderverhaltens - z. B. über den Parameter bin-log [4] - wird das aktuelle Nutzerverhalten direkt über die Datenbank aufgezeichnet. Für unseren Testfall wurde das Nutzungsmuster aus Abbildung 3 ermittelt.

Die ermittelten SQL-Statements gehen mit ihrer Gewichtung direkt in das Query Barrel ein und gewährleisten damit eine aussagekräftige Teststellung (siehe Abbildung 4). Für unseren Performance-Vergleich werden wir unterschiedliche Lasttestszenarien unterstellen (Anzahl paralleler Anwender). Die SELECT-Statements werden parallel von jeweils 1, 10, 25, 50 und 100 Clients ausgeführt. Bei den DML -Statements begnügen wir uns aufgrund der längeren Ausführungszeit mit 1, 5, 10, 15, 25 und 50 Clients.

Teststellung

Zur Durchführung unserer kleinen Messreihe bedienen wir uns der aktuellen MySQL-Version 6.0.6-alpha. Beide Storage Engines werden mit vergleichbaren Speicherbereichen ausgestattet und gestartet (siehe Abbildung 5).

Alle weiteren Parameter werden auf den MySQL-Defaultwerten belassen. Als Datenbasis werden mit Hilfe von GEN-DATA vor Testbeginn 500.000 Datensätze generiert und in die jeweiligen Testtabellen geladen. Um eine saubere Analyse der Storage Engines in den Teilbereichen der SELECT-, UPDATE-, INSERT- und DELETE-Statements zu erhalten, erfolgte die Messung dieser Statements initial separat. Abschließend wurde das gewichtete und kombinierte Testszenario gegen die Datenbank ausgeführt. Alle Teststellungen wurden mehrfach (10x) gegen die Datenbank ausgeführt und die Messergebnisse über die Testreihe gemittelt. Die einzelnen Statements (mit Ausnahme der INSERT-Statements) enthalten jeweils eine WHERE-Klausel, die auf eine indizierte Spalte (Primärschlüssel mitarbeiternr) zugreift. Bei dem eingesetzten Rechner handelt es sich um einen handelsüblichen Desktop PC mit einer 2 GHz Intel CPU und 2 GB RAM. Als Betriebssystem wurde ein OpenSuSe 10.1 eingesetzt.

Falcon versus InnoDB

Bei den indexbasierten SELECT-Statements ist zu erkennen, dass die Engine Falcon einen deutlich höheren Durchsatz an Statements pro Sekunde abarbeiten kann (ca. +50 % gegenüber InnoDB). Erstaunlich ist die Tatsache, dass beide Engines mit einer zunehmenden Anzahl von parallel arbeitenden Clients nicht skalieren (siehe Abbildung 6). Der limitierende Faktor dürfte in diesem Fall eindeutig in der CPU des verwendeten Systems liegen. Für einen höheren Durchsatz stehen hier einfach keine weiteren Ressourcen zur Verfügung.

Das Verhalten bei den DML-Statements weicht von diesem konstanten Ergebnis ab. Hier ist ein deutlicher Anstieg des Durchsatzes bei einer steigenden Anzahl von Clients zu verzeichnen (siehe Abbildung 7). Erstaunlich ist das Verhalten von Falcon im Single-User Betrieb. Die Durchsatzrate ist für diesen Fall extrem hoch und wird selbst durch eine hohe Anzahl paralleler Sessions nicht wieder erreicht. Falcon bestätigt diese Eigenart über alle in diesem Benchmarking getesteten DML-Statements (INSERT, UPDATE, DELETE).

Im Vergleich zu InnoDB schneidet Falcon im Parallelbetrieb deutlich besser ab. Dies dürfte an dem in Falcon neu implementierten MVCC-Konzept liegen, das auch im Vorfeld als Performance Feature mehrfach angekündigt wurde.

Bei den Teilergebnissen lag Falcon in den meisten Bereichen vorne. Beim kombinierten Szenario gab es ebenfalls keine Überraschungen. Falcon bietet im Schnitt gegenüber InnoDB einen Performance-Vorteil von 50 - 60 % (siehe Abbildung 8). Wenig überraschend ist, dass durch die wachsende Zahl der Clients der Durchsatz nicht wirklich steigt, da das Testszenario zu 70 % aus SELECT-Anweisungen besteht. Gerade in diesem Bereich konnten ja bereits zuvor keine Zuwächse durch parallele Client-Anfragen generiert werden.

Fazit

In dem von uns unterstellten Szenario kann Falcon ohne Weiteres mit InnoDB mithalten. In Teilbereichen bietet es sogar die bessere Performance. Ob dieses Verhalten konsequent auch für andere Szenarien und Datenmodelle gilt, muss im Einzelfall geprüft werden. Zu vielfältig sind die unterschiedlichen Anwendungsfälle und Konfigurationsmöglichkeiten von MySQL und seinen Storage Engines. Bei einem im Internet veröffentlichten Benchmarktest [5] wurden so z. B. andere Ergebnisse für das SELECT-Verhalten der beiden hier betrachteten Storage Engines gemessen. Allerdings wurden in diesem Benchmarking auch andere Rahmenbedingungen gesetzt.

Vielleicht haben Sie ja nun ebenfalls Lust bekommen, ein kleines Benchmarking gegen Ihre MySQL-Datenbanken durchzuführen, um zu überprüfen, ob Sie die für Ihre Zwecke optimale Storage Engine einsetzen. Wir unterstützen Sie gerne dabei!

Matthias Jung (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen