Zur Zeit besuche ich eine Lehrveranstaltung zum Thema Implementation von Datenbanksystemen (was berufliche Fortbildungen angeht, ist es durchaus nützlich, an einer Uni zu arbeiten).
In einer der ersten Vorlesungen ging es um das Thema, auf welchen Medien man Datenbanken prinzipiell ablegen kann/sollte und welche Vor-/Nachteile insbesondere bzgl. Geschwindigkeit mit einer konkreten Wahl verbunden sind.
Auch wenn die Wahl auf den von mir betreuten Uni-Datenbankservern längst getroffen wurde – alle unsere Datenbanken liegen aus verschiedenen Gründen im SAN – und Geschwindigkeit bei unseren DB-Servern eine eher untergeordnete Rolle spielt, war dennoch meine Neugierde geweckt, die prinzipiell zur Verfügung stehenden Optionen mal grob quantitativ zu untersuchen.
Eines vorneweg: die Testszenarien sind zugegebenermaßen alles andere als perfekt – mir ging es primär darum, grobe Größenordnungen zu ermitteln.
Als Testrechner fungierte mein Arbeitsplatzrechner, über den ich folgende Medien testen konnte:
- eine Solid-State-Disk, angeschlossen per SATA (3.0 Gbps)
- eine normale Festplatte, angeschlossen per SATA (3.0 Gbps)
- eine NFS-Platte, angebunden per Ethernet (1.0 Gbps)
- eine SAN-Platte, angebunden per zweier Fibre-Channel-Karten (je 8.0 Gbps)
Man sieht sofort, dass sich die ersten beiden Testszenarien nur schwer auf einen echten Server übertragen lassen. Bei Servern sind die lokale Platten üblicherweise per RAID-Controller angebunden, der wiederum via PCI-Express angeschlossen ist und so, mehrere parallel arbeitende Platten vorausgesetzt, den SATA-Engpass überwinden kann. Dafür kann man dank dieser beiden Szenarien schön SSD und HD miteinander vergleichen.
Das dritte und das vierte Szenario sind hingegen durchaus realistisch. In unseren Servern stecken exakt die gleichen Fibre-Channel-Karten und die (virtuelle) SAN-Platte liegt auf den gleichen Platten wie die unserer “echten” Server (und konkurrierte auch bei Zugriffen mit diesen). Auch an das LAN sind unsere Server nicht schneller als 1Gbps angebunden. Allerdings muss man erwähnen, dass der verwendete NFS-Fileserver die Daten selbst auch wieder auf einer SAN-Platte speichert. Beim LAN-SAN-Vergleich kann man also lediglich den zusätzlichen Overhead des LANs ermitteln.
Zusammenfassend kann man bis hierher also festhalten, dass man nur die Testergebnisse der ersten und der letzten beiden Szenarien (und letztere mit der genannten Einschränkung) untereinander vergleichen sollte.
Als Testsystem kam PostgreSQL 9.2.1 zum Einsatz – zum einen, da ich nach wie vor ein unverbesserlicher Postgres-Fan bin und zum anderen, weil PostgreSQL standardmäßig ein Benchmark-Programm, pgbench, mitbringt. Alle Parameter des Datenbanksystems wurden in der Default-Stellung belassen.
Die von pgbench verwendete Test-Datenbank, mit deren Hilfe das Programm eine Art TPC-B-Test durchführt, wurde einmal mit folgenden Parametern initialisiert:
pgbench -i -F 100 -s 250 pgbench
Durch diese Parameterwahl wurde die Testinstanz ca. 3.9GB groß (insbesondere für die Vergleichbarkeit der SAN-Messungen wichtig, da bei kleineren Testinstanzen die Gefahr besteht, dass sich der gesamte DB-Benchmark im Cache des SAN-Virtualisierungsservers abspielt). Danach wurde die Instanz per rsync
auf die verschiedenen Medien verteilt, so dass jedes Postgres initial auf einer identischen Instanz arbeitete.
Zum Testen wurde pgbench mit folgenden drei Parameter-Mengen gestartet:
pgbench -v -c 1 -T 3600 pgbench
pgbench -v -c 10 -T 3600 pgbench
pgbench -v -c 100 -T 3600 pgbench
d.h. die Tests liefen jeweils eine Stunde und es wurden nacheinander Benchmarks mit einem, zehn und hundert pseudoparallel arbeitenden DB-Clients durchgeführt.
Im folgenden sind die gemessenen Ergebnisse aufgelistet (alle Angaben in tps):
SSD | HD | LAN | SAN | |
---|---|---|---|---|
1 Client | 143 | 45 | 72 | 125 |
10 Clients | 211 | 135 | 160 | 1758 |
100 Clients | 228 | 188 | 267 | 2888 |
Die einzelnen Schlußfolgerungen überlasse ich dem geneigten Leser selbst. Wie mehrfach oben beschrieben, lassen sich die Testszenarien nur mit Einschränkungen untereinander vergleichen.
Ich muss allerdings zugeben, dass mich die SAN-Performance wirklich überrascht hat (und das, obwohl ich bereits vorher Verfechter von SAN-Lösungen – auch im DB-Bereich – war) und zwar insbesondere im (nicht ganz sauberen – siehe oben) Vergleich zur SSD.
Insofern kann ich diesen Blogpost eigentlich nur mit einem herzlichen Dank an die SAN-Gruppe des CMS abschließen: Macht weiter so! 🙂