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:

1. eine Solid-State-Disk, angeschlossen per SATA (3.0 Gbps)
2. eine normale Festplatte, angeschlossen per SATA (3.0 Gbps)
3. eine NFS-Platte, angebunden per Ethernet (1.0 Gbps)
4. 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):

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! 🙂

Unser täglich MySQL-Rant gib uns heute…

Mein heutiger Quell der Freude: das Buch “High Performance MySQL”.

Im Einleitungskapitel werden nacheinander die beiden wesentlichen Storage-Engines (InnoDB und MyISAM) vorgestellt, wobei die Eigenschaften von MyISAM erfrischend … nunja, ehrlich beschrieben werden.

MyISAM features
As one of the oldest storage engines included in MySQL, MyISAM has many features that have been developed over years of use to fill niche needs:

Soweit, so gut. Mal sehen, welche “niche needs” erfüllt wurden:

Locking and concurrency
[…] Writers obtain exclusive (write) locks. However, you can insert new rows into the table while select queries are running against it.

Ok… – an dieser Stelle sei erinnert, dass MyISAM keine Transaktionen beherrscht. Aber es geht noch beeindruckender:

Repair
MySQL supports manual and automatic checking and repairing of MyISAM tables […]. After repairing a table, you’ll likely find that some data ist simply gone. Repairing is slow, too.

“Und langsam ist es auch noch!” – na dagegen ist das “Einige deiner Daten sind hochwahrscheinlich verlustig gegangen” ja fast nebensächlich.

Zur Einleitung zurückkehrend haben wir also gelernt, dass MyISAM jahrelang konsequent weiterentwickelt wurde, um unter anderem endlich die lang vermisste Eigenschaft sich sporadisch selbst entleerender Tabellen anzubieten?

Unser täglich MySQL-Rant gib uns heute…

Ich war ja vor einiger Zeit auf einer MySQL-Schulung (siehe auch die zugehörigen Essensbilder) und zwar mit dem Ziel oder zumindest der Hoffnung, von einem “ernsthaften” MySQL-Administrator Lösungen oder zumindest Workarounds für die unzähligen, bisher bei uns aufgetretenen Unzulänglichkeiten dieses Pseudo-DBMS zu erhalten.

Leider wurden meine ob des Themas zugegebenermaßen niedrigen Erwartungen an die Schulung noch deutlich unterboten, aber wenigstens konnte ich einen wertvollen Einblick erhalten, wie Leute ticken, die mit MySQL-Consulting ihr Geld verdienen: Zu so ziemlich allen Problemen, die mein ebenfalls anwesender Kollege und ich nannten (z.B. die Unmöglichkeit, MyISAM-Dumps im laufenden Betrieb zu ziehen), lautete die hochprofessionelle Antwort, dass das halt so sei und man daran auch nichts ändern könne.

Mein absolutes Highlight war allerdings seine Aussage (inhaltlich wiedergegeben):

“Wozu braucht man denn Fremdschlüssel? Für die Konsistenz der Daten reicht es doch, wenn die zugreifenden Applikationen nur konsistente Daten an die Datenbank liefern. Eine Prüfung der referentiellen Integrität in der Datenbank verbraucht doch nur unnötig Zeit!”

Ich lass das einfach mal unkommentiert so stehen, erinnere aber nochmal daran, dass der Herr sein Geld mit Datenbankconsulting (nagut, MySQL-Consulting) verdient…

Anyway, heute wurde mir dieses Zitat noch einmal in Erinnerung gerufen, als ich vor dem Problem stand, dass sich ein frisch gezogener MySQL-Dump nicht in eine jungfräuliche MySQL-Datenbank einspielen ließ (ziemlich genau das hier beschriebene Problem mit der Universalfehlermeldung “ERROR 1005 (HY000)”).

Das grundsätzliche Problem besteht darin, dass gleich am Anfang des Dumps die Anlage der Tabellen und der Fremdschlüssel synchron erfolgt (jeweils alles in einem CREATE-TABLE-Statement). Dadurch existieren jedoch zu etlichen, frisch definierten Schlüsseln die referenzierten Tabellen (noch) nicht, so dass infolgedessen das gesamte CREATE TABLE fehlschlägt. (Kurz bei Postgres vorbeigeschaut: Bei pgdump werden im Dumpfile erst die Tabellen ohne Schlüssel angelegt, dann die Tabellen gefüllt und erst zum Ende die Fremdschlüsselbeziehungen definiert und dabei natürlich auch geprüft).

Nun gibt es aber auch für dieses Problem eine MySQL-Lösung, deren schlichte Existenz einen DBA zum Schreien bringen sollte: Man kann in MySQL die gesamte Prüfung der referentiellen Integrität abschalten!!!!!111elf.

Und zwar so richtig abschalten. Richtig im Sinne von: auch wenn die referentielle Integrität wieder aktiviert wird, führt dies nicht zu einer Prüfung, ob die Datenbank überhaupt noch in einem konsistenten Zustand ist!

Kleines Beispiel zum Gruseln:

Wir legen zwei Tabellen an, wobei die zweite die erste via Fremdschlüssel referenziert:

mysql> create table foo (a int not null, PRIMARY KEY(a) );
Query OK, 0 rows affected (0.02 sec)
mysql> create table bar (b int, FOREIGN KEY (b) REFERENCES foo (a));
Query OK, 0 rows affected (0.01 sec)


Ein Einfügen von Werten in foo ist generell unproblematisch, in bar sind hingegen nur Werte erlaubt, die schon in foo stehen:

mysql> insert into foo values (1);
Query OK, 1 row affected (0.01 sec)
mysql> insert into bar values (1);
Query OK, 1 row affected (0.00 sec)
mysql> insert into bar values (0);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`mytest`.`bar`, CONSTRAINT `bar_ibfk_1` FOREIGN KEY (`b`) REFERENCES `foo` (`a`))


Und nun kommt’s:

mysql> set foreign_key_checks = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into bar values (0);
Query OK, 1 row affected (0.00 sec)
mysql> set foreign_key_checks = 1;
Query OK, 0 rows affected (0.00 sec)


Und ja, die Daten sind wirklich drin:

mysql> select * from bar;
+------+
| b |
+------+
| 0 |
| 1 |
+------+
2 rows in set (0.00 sec)


Wer noch mehr schlechte Laune braucht, kann sich mal das MySQL-Handbuch zum Thema “Fremdschlüssel-Beschränkungen” zu Gemüte führen. Darin sind solche Perlen enthalten wie:

Abweichung von SQL-Standards: Ein FOREIGN KEY-Constraint, der einen Nicht-UNIQUE-Schlüssel referenziert, ist nicht Standard-SQL, sondern eine InnoDB-Erweiterung dieses Standards.

oder

Hinweis: Trigger werden von kaskadierenden Fremdschlüsselaktionen derzeit nicht aktiviert.

So, Feierabend, mir reicht’s für heute…