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! 🙂
Dass die SAN-Gruppe gute Arbeit leistet, glaube ich gerne. Und dennoch will ich noch etwas kräftiger in die Vergleichbarkeitskerbe hauen. Und zwar gar nicht mal hauptsächlich wegen der theoretischen Maximalbandbreite (3 vs. 2*8 Gbps, Faktor ~5). Sondern eher dahingehend, wie gut diese ausgenutzt wird (Leistung ~Faktor 12).
Dass durch mehr Parallelisierung (RAID) und mehr Bandbreite mehr drin wäre, ist klar.
Da steht lapidar SSD an SATA2. Das kann viel heißen. Insbesondere aber, dass es nicht “Stand der Technik” ist 😉 Ja, im Vergleich zu HDD ist das stets ein spürbarer Fortschritt, aber unter richtiger Last ist die Performance einer alten SSD meist nicht so berauschend. Da hat sich in den letzten Jahren schon noch einiges getan. Ich vermute mal, dass eine Samsung SSD 840 Pro an SATA3 locker um den Faktor 3 schneller wär (und maximal Faktor 2 ließe sich auf die 6Gbps schieben). Je nach den Details deiner SSD und deines Benchmarks kann der Unterschied aber auch noch deutlich größer ausfallen, weil viele (insbesondere ältere) SSDs irgendeine (verschiedene) erhebliche Performance-Schwachstelle haben (insbesondere bei kleineren und zufälligen Zugriffen). Bei 100 Threads dürfte darüber hinaus allein schon das Vorhandensein von Native Command Queueing einen spürbaren Unterschied machen.
Guckst du z.B. auch http://www.anandtech.com/show/6388/intel-ssd-335-240gb-review
Und (erst) dann kommt dazu, dass es nur so richtig Sinn hat, 2 Komponenten mit 16Gbps zu verbinden, wenn die das auch ansatzweise ausnutzen können. Dass du das mit einer (noch so effizienten) 6- oder gar 3Gbps-Lösung nicht wirst erreichen können, war sogesehen absehbar. Aber dichter dran solltest du sehr wohl kommen.
Wenn es um wüste lokale Massenspeicherperformance ginge, lohnte auch ein Blick auf Intel SSD 910 800GB & Co: http://www.anandtech.com/show/6124/the-intel-ssd-910-review