Die letzten Tage habe ich etwas Zeit damit verbracht nach Benchmark-Tools für MaxDB zu suchen. Ohne allzu großen Erfolg. Am Ende habe ich mich mit Benchmark Factory von Quest und sql-bench aus der MySQL-Distribution rumgeschlagen. Leider ohne durchschlagenden Erfolg.

Es lassen sich nur ein paar allgemeine Worte anbringen.

Benchmark Factory

Benchmark Factory von Quest ist eigentlich eine ganz nette Software. Das Programm simuliert eine beliebige Anzahl von Benutzern, die Anfragen an eine Datenbank schicken. Benchmark Factory greift in der einfachsten Variante über ODBC auf eine Datenbank zu. Mit dieser Standardschnittstelle kann praktisch jede Datenbank angesprochen werden. Natürlich auch MySQL und MaxDB.

Das Programm führt wahlweise zuvor aufgezeichnete Queries aus, die z.B. aus einem Logfile stammen können, oder es benutzt einen Standardbenchmark für den Stresstest: AS3AP, TPC-B, TPC-C, TPC-D. Standardschnittstelle (ODBC) und Standardbenchmark klingt zunächst vielversprechend. Doch dann kamen die Enttäuschungen. Beim TPC-B fällt MySQL 5.0 bei einem CREATE TABLE auf die Nase und MaxDB 7.6 kommt auf die Idee eine Tabelle während des Tests zu leeren, die wahrscheinlich nicht geleert werden soll, wie hunderte von Warnings während des Tests zeigen. Der Unterschied zwischen einem TPC-C und einem TPC-D Benchmark würde mir zumindest in der Testversion nicht klar. Mir ist sehr wohl bekannt, daß es sich um zwei völlig andere Benchmarks handelt, aber die späteren Ausführungsprotokolle ließen mich zweifeln, daß wirklich ein TPC-C bzw. TPC-D Benchmark durchgeführt wurde. Nein, das war nicht kompatibel.

Immerhin konnte man MySQL 5.0 während der Initialisierungsphase eine aufgrund von Syntaxproblemen nicht automatisch angelegte Tabelle manuell “unterschieben”, bevor der eigentliche Testlauf begann. Bei 200MB Caches langweilte sich MySQL 5.0.13 RC (InnoDB). Es begann bei einem Benutzer mit rund 45 Transaktionen pro Sekunde und schaukelte sich bei mehr parallelen Benutzern bei rund 60 Transaktionen ein. Leider ist in der Testversion schon bei 20 gleichzeitigen Benutzern das Ende der Fahnenstange erreicht. MaxDB 7.6.00.12, was sich etliche UPDATE Statements ersparte, weil aus irgendeinem Grund Daten aus einer der Testtabellen gelöscht wurden und die Datensätze nicht mehr aktualisiert werden konnten, startete bei rund 32 Transaktionen pro Sekunde. Das sind fast 50% weniger als MySQL 5.0.13 RC erreichte. Es war aber auch etwas, was ich erwartet hatte.

Die ODBC-Logfiles zeigten sehr einfache SQL-Anfragen. MySQL ist unglaublich schnell bei vielen Basisoperationen. ALTER TABLE ist eine der wenigen, unrühmlichen Ausnahmen. Subselects sind ein anderes Thema. Dennoch, kaum eine Datenbank kann mit MySQL (InnoDB) mithalten, wenn die SQL-Anfragen einfach sind. Und bei komplexeren Operationen holt MySQL mit Riesenschritten auf. So verwunderte es mich nicht, dass MaxDB bei nur einem Benutzer nicht mithalten konnte. Bei mehreren Benutzern kam es schnell zum “Gleichstand”, genauer: bei nur 4 parallelen Benutzern. “Gleichstand” ist hier mit sehr großer Vorsicht zu lesen. MaxDB zeigte im Testprotokoll von Benchmark Factory sehr viele Warnings. MaxDB hat etliche UPDATE table SET column = value WHERE column = value versucht auszuführen, aber keine Datensätze in der Tabelle gefunden, die es aktualisieren konnte. Warum berichte ich dann überhaupt über diese Werte? Nun, es waren maximal 10 Datensätze in der Tabelle und MaxDB wird Row-Locks gesetzt haben egal ob am Ende ein Datensatz aktualisiert wurde oder nicht. Bei nur 10 Datensätzen wird die Aktualisierung selbst auf eine einzelnen Datenseite stattfinden. Das ist etwas memcpy() was MaxDB nicht ausgeführt hat. Es dürfte nichts am Trend ändern.

sql-bench ist ein sehr einfacher Performanztest aus der MySQL-Distribution. Er führt einige, meist einfache Anfragen etliche Male nacheinander aus, um SELECT, INSERT, UPDATE, ALTER zu vermessen. Mit der Realität hat der Test so viel zu tun wie Monk mit dem Durchschnittsbürger. Das passt einfach nicht. Dennoch ist der Test ganz interessant, um herauszufinden welche Basisoperation langsam und welche schnell ist.

sql-bench

Wie bei Benchmark Factory mißt man bei sql-bench auch ein klein wenig die Geschwindigkeit einer bestimmten Programmierschnittstelle. sql-bench verwendet Perl. Welchen Einfluss dies auf die Ergebnisse hat, habe ich nicht untersucht. sql-bench aus der MySQL 5.0.13 RC Distribution hat keinen expliziten MaxDB Support. Hier firmiert MaxDB noch unter dem alten Namen SAPDB. Damit man einen Testlauf ausführen kann, sollte man die Datei server-cfg anpassen: das aktuelle Perl-Interface ist DBI::MaxDB. Ein bisserl Schrauben anziehen für den MaxDB Testlauf ist auch noch in test-alter-table gefragt. MaxDB möchte ein ALTER TABLE tablename ADD (col1 INT, col2 INT...) statt ALTER TABLE tablename ADD col1 INT, col2 INT oder ähnlichem. Danach kann es aber auch schon losgehen mit: ./run-all-tests --user=DBADMIN --password=DBADMIN --database=TEST --server=SAPDB --cmp=mysql,sapdb --dir=output_maxdb --log.

Beim späteren Vergleich der Ergebnisse von InnoDB und MaxDB mit compare-results gab es wieder die Ergebnisse, die ich erwartet habe. MySQL lag beim Großteil der Tests vorne. Teilweise sind die Faktoren erschreckend: was wird aus MySQL, wenn es irgendwann einmal 6.0 im Namen trägt und der Optimizer full-featured ist? Hier wächst ein Monster.

Bedeutet das jetzt, MaxDB ist langsam? Nein, bei weitem nicht! Auf vergleichbarer Hardware liefert MaxDB unter SAP eine Geschwindigkeit, die mit allen Mitbewerbern vergleichbar ist. Performanz ist kein Killer-Argument bei der Entscheidung für oder gegen MaxDB. Es gibt einige Operationen, die unter MaxDB langsam sind. MaxDB verteilt Datenseiten gleichmäßig über alle Datenvolumes. Bei Commodity-Hardware ist das eine schlechte Taktik für Scanoperationen, weil diese nicht von sequentiellen Leseoperationen profitieren können. Teure und sehr leistungsstarke Storage-Hardware kann durch eigene Abstraktionsschichten diesen Effekt kompensieren. Aber ich habe auf SATA-Platten getestet. Nicht gerade High-End… Für zufällige Zugriffe ist die Verteilung immer noch eine klasse Idee.

Kristallkugel

Beim Blick in die Kristallkugel zeigt sich Multiversioning am MaxDB 7.7 Horizont. Gerüchte berichten von signifikanten Geschwindigkeitssteigerungen. Pre-fetching ist ein weiteres Thema für 7.7. Meine eigenen Erfahrungen mit MaxDB sind begeisterte Kunden, die berichten, daß eingeschwungene Systeme in weiten Teilen Oracle Performanz erreichen oder übertreffen. Immer nur dann, wenn die MaxDB Features ausreichen, um Oracle zu ersetzen. Ich habe auch Joins aus der Praxis gesehen, die MaxDB 7.5 um Größenordnungen schneller ausgeführt hat als MySQL 5.0. MySQL zeigte einen guten Ausführungsplan, verwendete komprimierte MyISAM-Tabellen und hatte dennoch keine Chance.

Das alles macht die Frage ungemein spannend wie die Geschwindigkeit von MaxDB im Vergleich zu MySQL ist. Leider gibt auch dieser Blogeintrag keine Antwort. Vielleicht eine: MySQL führt Basisoperationen auf einfacher Hardware unglaublich schnell aus. Wer diese Geschwindigkeit in eine reale Applikation unter hoher paralleler Benutzerlast retten kann, darf sicher sein eine der schnellsten Datenbanken überhaupt zu benutzen.

Beim Schnellvergleich mit PHP wird MaxDB keinen Stich kriegen. Es sei denn, man hat komplexere Queries. Die hat weder Benchmark Factory noch sql-bench ausgeführt. Und der Trend geht in Richtung Komplexität. Es bleibt mir also nur weiter zu suchen nach Vergleichswerten und einem passenden Tool. Vielleicht hat ja jemand eine super-smack Testsuite, die in Frage kommt…