PostgreSQL oder MySQL: Wer skaliert besser?

Das Datenbankduell

Die Konkurrenz von MySQL und PostgreSQL ist so alt wie die Datenbanken selbst und kennt keinen endgültigen Sieger. Nichtsdestotrotz ist das Kräftemessen immer wieder reizvoll und aufschlussreich. Das ADMIN-Magazin arrangierte deshalb jetzt ein Duell, das es so noch nicht gab.
Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Um beim großen Datenbankduell MySQL versus PostgreSQL einerseits für maximale Fairness und andererseits dafür zu sorgen, dass die Zweikämpfer wirklich alle Register ziehen und sich in Bestform messen können, hat sich die ADMIN-Redaktion mit erfahrenen Sekundanten verstärkt. Jeder Beistand steuerte für "seine" Datenbank die besten Insider-Tuning-Tipps bei. Im Fall von MySQL half dankenswerterweise Oli Sennhauser, früherer Senior Database Consultant für MySQL bei Sun und heute als selbstständiger und neutraler MySQL-Berater mit der eigenen Firma FromDual unterwegs. Bei PostgreSQL unterstützte die Redaktion Susanne Ebrecht, PostgreSQL-Entwicklerin und unter anderem Mitbegründerin der europäischen PostgreSQL User Group. Heute ist sie beim PostgreSQL-Spezialisten 2ndQuadrant unter Vertrag.

Mithilfe dieser beiden Datenbankprofis sollte sich erweisen, was jeder der Kontrahenten im untersuchten konkreten Fall zu leisten vermag. Ein endgültiges Ergebnis war von vornherein nicht zu erwarten, denn mit anderen Parametern – etwa einem anderen Workload oder einer anderen Datenbankgröße – würden sich wahrscheinlich andere Resultate ergeben. Deshalb ging es auch nicht vordergründig um Sieg oder Niederlage, sondern vor allem um den Weg zum Ziel: Was muss ich messen? An welchen Stellschrauben kann ich drehen? Welchen Effekt hat welche Maßnahme? Welche Leistungssteigerung lassen die beiden Datenbanken relativ zu ihrer Default-Konfiguration zu? Wer profitiert besser von schneller Hardware?

Schließlich bleibt anzumerken, dass Geschwindigkeit nicht das einzige Kriterium sein kann, wenn man zwischen den beiden Datenbanken zu wählen hat. Da geht es außerdem häufig um Applikationen, die die Datenbank unterstützen können soll, um die Administrierbarkeit und eventuell bereits vorhandenes Know-how der einen oder anderen Sorte, um Ausfallsicherheit und damit um solche Dinge wie Clustering und Replikation, um Supportfragen oder Migrationsmöglichkeiten und manches mehr, das leicht wichtiger sein kann als ein paar Prozente mehr Performance. Nichtsdestotrotz ist die Performance ein nicht unwichtiger Faktor in der Gesamtschau.

Zu guter Letzt: Das SQL in den Prozeduren des Benchmarks ist als gegeben hinzunehmen – in der Praxis und mit dem nötigen Know-how läge aber gerade dort das größte Tuning-Potenzial, denn was durch ungünstig gestaltete Abfragen oder ein mangelndes Datenbank-Design an Geschwindigkeit verloren geht, das lässt sich kaum durch trickreich konfigurierte Einstellungen wieder aufholen.

Der Benchmark

Für den Datenbankvergleich verwendete das ADMIN-Magazin den Benchmark DBT-2 [1] , der ursprünglich einmal von den Open Source Development Labs entwickelt wurde (von dem er heute aber leider nicht mehr gepflegt wird). Der Vorzug dieses Benchmarks ist, dass er nicht nur einen relativ komplexen und vielfältig konfigurierbaren OLTP-Work-load erzeugt, sondern darüber hinaus auf eine anerkannte Methodik zurückgreift. Er benutzt nämlich dasselbe System wie der Industriestandard TPC-C, dem er nachempfunden ist. Zwar sind die resultierenden TPC-C- und DBT-2-Werte nicht direkt vergleichbar, doch prinzipiell absolvieren die Datenbanken in beiden Fällen dasselbe Prozedere.

Die Installation des Benchmarks hält allerdings ein paar Fallstricke in Gestalt kleinerer Fehler bereit: Da ist mal die Syntax in SQL-Skripten nicht korrekt, mal steht die Bourne-Shell in der Shebang-Line, wo es die Bash sein müsste, mal finden sich fest verdrahtete Pfade in den Skripten, die ins Nirgendwo weisen und so weiter. Alles nichts, was ein einigermaßen geübter Admin nicht fixen könnte, aber es kostet Zeit. Einzelne Fehler soll allerdings eine spätere Version bereinigen. Die Redaktion hatte vor einiger Zeit sogar versucht, die ehemaligen Entwickler wieder für ihr verwaistes Projekt zu interessieren – ohne Erfolg.

Wenn der Benchmark läuft, simuliert er eine Großhandelsanwendung, bei der eine Anzahl Mitarbeiter an Terminals Transaktionen auslösen, die Bestellungen, Auslieferungen, die Zahlungsabwicklung, die Überwachung der Bestellabwicklung und die Überwachung des Lagerbestands umfassen. Diese Transaktionen werden in einem festgelegten Mix in der Datenbank gestartet, am häufigsten "New Order" gefolgt von "Payment", "Order Status", "Delivery" und "Stock Level". Die zentrale Messgröße sind die neuen Bestellungen pro Minute, die das Datenbanksystem bewältigen kann.

Die Umgebung, in der sich das alles abspielt, besteht aus Warehouses. Zu jedem Warehouse gehören 10 Districts. Jeder District hat 3000 Kunden. Jedes Warehouse verwaltet 100000 Artikel. Jede zehnte Bestellung muss an ein anderes Warehouse abgegeben werden, weil nicht immer alle Artikel am Lager sind. Pro Warehouse starten per Default zehn Terminalprozesse.

Alle Transaktionen des Benchmarks sind als Stored Procedures in der Datenbank hinterlegt. Den Benchmark steuern zur Laufzeit zwei Software-Komponenten: Zuerst öffnet ein Client eine vorzugebende Anzahl Datenbankverbindungen, was während einer Einschwingphase abgewartet wird. Danach löst ein Driver über den Client die Transaktionen aus, wobei er entweder eine Think Time zwischen zwei Transaktionen einbaut oder nicht.

Der Benchmark ist in weiten Grenzen konfigurierbar. Insbesondere kann man einstellen

  • die Anzahl Warehouses (der zentrale Skalierungsfaktor) (-w)
  • die Anzahl paralleler Datenbankverbindungen (-c)
  • die Laufzeit (-d)
  • ob eine Think Time verwendet werden soll oder nicht (-n)

Bei den hier diskutierten Ergebnissen haben wir immer auf die Think Time verzichtet, weil andernfalls die Belastungsgrenze erst bei einer hohen Anzahl Warehouses erreicht würde, was aber gleichzeitig eine ebenfalls hohe Anzahl Terminalprozesse mit sich brächte. Dabei würde die Konkurrenz dieser Terminal-Threads mit einem übermäßigen Gewicht in das Ergebnis eingehen.

Alle hier wiedergegebenen Messwerte sind Mittelwerte, die Ausreißer nivellieren. Das ADMIN-Magazin hat jeweils mindestens drei Durchläufe pro Setup gemessen, manchmal auch wesentlich mehr. Die Tester versuchten, jede Datenbank nacheinander durch eine Reihe von Tuningmaßnahmen zu beschleunigen. Erfolglose Versuche übergeht dieser Beitrag, der im Folgenden nur die Datenbankoptionen vorstellt, die zu einer signifikanten Geschwindigkeitssteigerung geführt haben oder die zumindest unter anderen Umständen sicher einen positiven Effekt gehabt hätten. Die Performanceverbesserungen machen sich normalerweise an mindestens drei Mess-Serien fest, bei der die Tester die Last ohne Think Time von 1 bis 20 Warehouses ansteigen ließen und nach der Einschwingphase zum Aufbau der Datenbankverbindungen den Lasttest jeweils fünf Minuten laufen ließen.

Start mit MySQL

Die grobe Marschrichtung für das Tuning muss bei beiden Datenbanken sicher lauten: Plattenzugriffe einsparen. Davon produziert der Benchmark reichlich, und sie sind jeweils um Größenordnungen langsamer als die Hauptspeicheroperationen, mit denen sie sich substituieren lassen. Beide Datenbanken bieten eine Vielzahl von Stellschrauben an, unter MySQL liefert beispielsweise »SHOW GLOBAL VARIABLES;« einen Überblick. Die Liste ist lang, doch keine Angst: Für das Tuning sind nur eine Handvoll Parameter wirklich interessant.

Um einen Ausgangswert als Vergleichspunkt zu bestimmen, maß die Redaktion zuerst die Performance mit der Konfiguration, die jeweils die Paketinstallation der Datenbank mitbrachte. Danach visierte sie im Fall von MySQL verschiedene Stoßrichtungen an.

Zuerst das Parameter-Tuning als die kostengünstigste Variante, weil dafür nur Datenbankeinstellungen zu ändern sind und nichts neu zu installieren ist. Zweitens sollte aber auch eine aktuellere MySQL-Version getestet werden, als sie das Repository des verwendeten Ubuntu LTS 10.04 zu bieten hat. Theoretisch wären drittens auch MySQL-Ableger wie MariaDB, der Percona-Server oder Drizzle einen Versuch wert gewesen, allerdings können sich hier in der Praxis leicht höhere Hürden ergeben, etwa in Form zusätzlicher Kosten oder weil damit der für MySQL eingekaufte Support verloren ginge. Diesen Weg hat die Redaktion deswegen nicht weiter verfolgt.

Zudem zwang der Aufwand zu einer Beschränkung. Allein für beide Datenbanken zusammen startete der Benchmark an die 2000 Mal. Dabei lief er im Mittel zwischen sieben und acht Minuten, macht insgesamt um die 250 Stunden oder mehr als zehn Tage rund um die Uhr. Viertens – und das haben wir wieder praktisch getestet – wollten wir wissen, was es ausmacht, die zunächst eingesetzte Festplatte gegen eine schnelle SSD zu tauschen.

Alle Messungen unternahmen wir auf ein und derselben Hardware, einem Dell PowerEdge T110 mit zwei Intel Dual-Core Prozessoren i3 530, die mit 2,93 GHz getaktet wurden. Der Server war mit 8 GByte RAM ausgestattet. Als Massenspeicher diente eine interne 300-GByte-Platte von Western Digital beziehungsweise eine Intel SSD der 320er-Serie (160 GByte), auf die wir versuchsweise die Data Directories der Datenbanken verlegten. Das System war zum Messzeitpunkt ausschließlich mit den Benchmarks beschäftigt.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023