Gute Nachbarschaft
Welche Datenbanken sind für den Einsatz in Unternehmen geeignet? c't bläst zum Wettbewerb zwischen populären kommerziellen und Open-Source-Datenbanken.
- Michael Kunze
- Hajo Schulz
Der Westfälische Friede beendete 1648 den Dreißigjährigen Krieg. Zwar beantwortete der Friedensschluss nicht die Frage nach dem wahren Glauben. Er sorgte jedoch eine lange Zeit dafür, dass religiöse Differenzen nicht mehr mit Pike und Muskete ausgetragen wurden.
Die Zahl der Glaubenskonflikte hat derweil nicht abgenommen, wie ein Blick in jedes besser besuchte IT-Forum im Internet nahe legt. Die Missionare der allein selig machenden Religionen Windows/Linux, PHP/Java oder MySQL/PostgreSQL erinnern in ihrem Eifer bisweilen an einen bekannten Kardinal.
Doch wer in modernen Zeiten neue Jünger gewinnen will, muss durch Tatsachen überzeugen. Wie die für populäre Datenbanken aussehen, möchte c't anhand eines offenen Entwickler-Wettbewerbs klären: Überzeugen Sie uns und die c't-Leser davon, dass Ihre Lieblingsdatenbank die beste ist! Dabei geht es um weit mehr als die üblichen Benchmarks: Neben Informationen über das Verhalten von Datenbanken in lebensnahen Szenarien soll der Wettbewerb Auskunft über die Tauglichkeit von Middleware und Server-Plattformen geben.
Als friedensstiftende Maßnahme soll der Test gerade nicht die Anbetung des Säulenheiligen namens Featuritis fördern - ebenso wenig wie die Verkündigung des einzig wahren IT-Dogmas. Wir wollen vielmehr die Mühsal dokumentieren, die den Gläubigen beim Beschreiten des jeweiligen Pilgerpfades erwartet. Dabei interessieren uns pfiffige Abkürzungen ebenso wie Gelegenheiten, sich den Ablass schlicht zu erkaufen. Im Unterschied zu eher abstrakten Leistungs-Benchmarks wie denen des TPC [1] wollen wir die Gesamtleistung einer Lösung gemessen am benötigten Aufwand würdigen.
Shoppen und Beten
Deshalb liegt diesem Wettbewerb lediglich die Referenzimplementierung einer typischen e-Commerce-Anwendung zu Grunde. Anhand dieser Blaupause können interessierte Entwickler ihre eigene Lösung erstellen und der Redaktion zur kritischen Würdigung übergeben. Dabei müssen sich die Kandidaten allesamt auf der gleichen Hardware-Plattform unter Windows oder Linux bewähren. Im Sinne eines offenen Wettbewerbs sind für die Implementierung ausdrücklich alle Tricks erlaubt, solange sie dokumentiert werden. Ähnliches gilt für Software-Versionen: Solange sie im Test stabil laufen und die gewünschten Ergebnisse bringen, können auch Beta-Versionen der entsprechenden Software-Komponenten zum Einsatz kommen. Die genauen Voraussetzungen lassen sich im Kasten „Im Labor“ nachlesen.
Zur Auswahl der e-Commerce-Testanwendung hat die Redaktion diverse Open-Source-Projekte unter die Lupe genommen. Die Bandbreite reichte von reinen Labor-Applikationen wie Rubis [2] bis zu aufwendigen Auktionsanwendungen wie PHPBB-Auction [3]. Letztlich haben wir uns für den „DVD-Store“ entschieden, ein Projekt aus der Linux-Abteilung des Computerherstellers Dell. Die Firma hat den Test in den letzten Jahren für ihr internes Server-Labor entwickelt, mittlerweile liegt er unter dem Kürzel DS2 für den freien Einsatz vor [4].
Die Zielrichtung bei der Entwicklung von DS2 lag in einer Art „TPC light“. So hat Dell den Test ursprünglich für Studien verwendet, die beweisen sollen, wie schön man unternehmenskritische Datenbankanwendungen von teuren Sun-Maschinen auf Standard-PC-Hardware aus eigenem Hause migrieren kann. Dieser professionelle Ansatz kommt den Absichten des c't-Datenbank-Contest klar entgegen.
Das karge Benutzer-Interface der Testplattform erklärt sich so aus ihrer Herkunft als Laboranwendung. Dafür bringt sie jedoch einige Eigenschaften mit, die sie für einen Datenbanktest besonders geeignet erscheinen lassen. Zum einen verwendet der DS2-Shop Ausstattungsmerkmale moderner Datenbanken wie Stored Procedures, sichere Transaktionen und referentielle Integrität. Solche Features laufen beim großem Bruder TPC-W unter der Abkürzung OLTP (On-Line Transaction Processing) und gehören zu den essenziellen Anforderungen der TPC-Suite. Zum anderen bringt DS2 bereits fertige Backend-Implementierungen für MySQL, Oracle und MS SQL mit, die einen interessanten Einblick in die Unterschiede und Gemeinsamkeiten der Datenbanksysteme erlauben.
Ebenso vielfältig wie beim SQL-Anteil geht es bei der Middleware zu. Jede Datenbankvariante verfügt über jeweils drei Middleware-Implementierungen, und zwar in ASP.NET, JSP und PHP. Solche Vielfalt hat allerdings einen Preis, den schon das simple Benutzer-Interface nahe legt: Die Autoren haben nur einen sehr dünnen Programm-Layer erstellt und dabei lediglich die Basisfunktionen der jeweiligen Plattform verwendet. Die Implementierungen verzichten beispielsweise auf jegliches interne Session-Management und schleppen die Session-Parameter wie in alten Zeiten als verborgene Formularfelder mit. Doch der Verzicht auf schmückendes Beiwerk offenbart verblüffende Gemeinsamkeiten der drei Sprachkonzepte. Wären da nicht die um ihre Machtbasis besorgten Päpste Balmer und McNeally, könnte man schon fast von einer Ökumene der Web-Programmiersprachen träumen.
Für den automatisierten Leistungstest bringt DS2 einen eigenen Client-Simulator mit. Dieser Simulator ist als .NET-Programm in einer C#-Implementierung ausgeführt. Dank Mono läuft er nicht nur unter Windows, sondern problemlos auch unter Linux. Wie bei solchen Projekten üblich ruft das Programm nach dem Start eine frei wählbare Zahl von virtuellen Clients ins Leben, welche das Datenbank-Backend mit den hart kodierten Anfragen bombardieren. Der Simulator liegt in zwei Varianten vor: Die eine verhält sich ähnlich wie ein Web-Client und steuert den entsprechenden HTTP-Stack aus Web-Server, Middleware und Datenbank an. Die andere Version eignet sich zum direkten Leistungstest der Datenbanken, denn sie agiert als klassischer SQL-Client und erlaubt so eine direkte Ansteuerung. Beide Varianten liefern nach Abschluss der Messungen eine detaillierte Statistik der Ergebnisse.
Geht es besser?
Grundsätzlich stehen Ihnen zwei verschiedene Wege offen, am c't Datenbank-Contest teilzunehmen: Zum einen können Sie eine der Referenzimplementierungen hernehmen und durch Schrauben an einzelnen Datenbankparametern oder durch Verbesserungen am Programmcode versuchen, das letzte Quäntchen Performance aus der Plattform herauszuholen. Wer seine Lieblings-Datenbank oder seine Leib-und-Magen-Programmiersprache unter den angebotenen Plattformen vermisst, kann natürlich eine komplett eigenständige Lösung entwickeln. Dabei bleibt jedoch zu bedenken, dass die Redaktion den Test aller eingereichten Lösungen mit dem Web-Client-Simulator vornehmen wird. Eine alternative Lösung muss sich daher bei der Ansteuerung durch den Simulator ebenso wie die Referenz verhalten.
Auch die Selbermacher werden aber kaum darum herumkommen, sich DS2 in der vorliegenden Form zu besorgen und in Betrieb zu nehmen. Von der Download-Seite [4] benötigen Sie in jedem Fall den datenbankunabhängigen Teil, der in der 2,3 MByte großen Datei ds2.tar.gz steckt. Dazu kommt noch mindestens eines der datenbankspezifischen Archive ds2_mysql.tar.gz, ds2_sqlserver.tar.gz und ds2_oracle.tar.gz.
Alle Archive müssen in ein gemeinsames Verzeichnis entpackt werden. Das enthält danach unter anderem das Unterverzeichnis data_files mit den zum Importieren in die Datenbank vorgesehenen Kunden-, Bestell- und Produktdaten in der kleinsten Ausprägung. Zum Messen der Performance verwendet DS2 Testdaten in drei verschiedenen Größenordnungen von etwa 10 MByte, 1 und 100 GByte, von denen wir bei der Beurteilung der Einsendungen nur die ersten beiden verwenden werden. Um die Testdaten mittlerer Größe zu erzeugen, müssen Linux-Anwender lediglich die drei Shell-Skripte ds2_create_*_med.sh aus den Unterverzeichnissen cust, orders und prod durchlaufen lassen. Die eigentlichen Generatoren liegen als Linux-Binaries und im C-Quelltext vor, den Windows-Nutzer zunächst mit einem geeigneten Compiler übersetzen müssen. (Einen kostenlosen C++-Compiler enthalten zum Beispiel Borlands „Free Command Line Tools“, siehe Soft-Link.) Die Parameter, mit denen die dabei entstehenden Programme aufzurufen sind, entnehmen Sie bitte den oben erwähnten .sh-Dateien.
Das Unterverzeichnis drivers des DS2-Ordners enthält den Test-Client: Die beiden .exe-Dateien simulieren einen Web-Client und laufen unter .NET beziehungsweise Mono. Wer sie neu erzeugen will, muss die beiden Quelltextdateien ds2xdriver.cs und ds2webfns.cs zusammen kompilieren. Ein Client, der direkt auf die Datenbank zugreift, entsteht, indem man ds2xdriver.cs zusammen mit einer der Dateien ds2*fns.cs aus dem jeweiligen datenbankspezifischen Unterverzeichnis kompiliert.
Innerhalb der Ordner für eine konkrete Datenbank finden sich jeweils die Unterordner build mit SQL-Skripten zum Aufsetzen der Datenbank, load mit solchen zum Importieren der Testdaten in die Datenbank und web. Hier steckt in weiteren Unterordnern alles, was man braucht, um DS2 als PHP-, JSP- oder ASP.NET-Anwendung im Web-Server ans Laufen zu bringen. In fast jedem Ordner erklärt eine README-Datei weitere Einzelheiten, und die Orientierung in den Quelltexten erleichtern teils sehr ausführliche Kommentare.
Ans Werk!
Der c't-Datenbank-Contest richtet sich ausdrücklich nicht nur an Hobbyisten und Open-Source-Entwickler. Besonders gespannt sind wir auch auf Beiträge von Datenbankherstellern und Anbietern von professionellen Plattformen für Web-Anwendungen.
Als Einsendeschluss für den Wettbewerb gilt der 13. November 2005. Sobald die Lösungen getestet und bewertet sind, werden wir die besten Einsendungen ausführlich vorstellen. Preise gibt es in mehreren Kategorien: Zunächst einmal werden wir natürlich den insgesamt schnellsten DVD-Shop prämieren. Daneben wollen wir aber auch wissen, mit welchem Ansatz die Einsender bei möglichst geringem Aufwand an Zeit und Geld zu performanten und robusten Lösungen gekommen sind. Punkte sammeln kann zudem, wer mit besonders originellen Einfällen die Beschränkungen der jeweiligen Plattform umgeht, trickreiche Wege zur Leistungssteigerung findet oder mit eleganten Lösungen überzeugt.
Ein Forum für potenzielle Kombattanten haben wir unter ctmagazin.de/dbcontest eingerichtet. Hier gibt es auch ein Formular, mit dem Sie Ihre Lösung einreichen können. Die Redaktion freut sich schon jetzt auf eine Vielzahl von Teilnehmern.
Literatur
[1] Transaction Processing Performance Council
[2] RUBiS: Rice University Bidding System
[3] PHPBB-Auction
[5] c't Datenbank-Contest
| "Datenbanken" | |
| Weitere Artikel zum Thema "Datenbanken" finden Sie in der c't 5/2005: | |
| Kostenlose SQL-Server | S. 146 |
| Grafische Oberflächen | S. 150 |
| Der c't-Datenbank-Contest | S. 156 |
Im Labor
Die Redaktion wird jede Implementierung des DVD-Shops auf einheitlicher Hardware testen. Dabei werden zwei unterschiedliche Versuchsaufbauten zum Einsatz kommen: Im ersten Fall laufen Webserver, Middleware und Datenbank auf einer einzigen Maschine. Dieses Szenario entspricht den Standardangeboten der großen Webhoster für professionelle Kunden und kleinere Unternehmen. In einem zweiten Schritt werden wir die Datenbank auf einen zweiten gleichartigen Server auslagern. Dieses Frontend/Backend-Setup kommt typischerweise bei Firmen mit höheren Anforderungen zum Einsatz, die ihre Netzinfrastruktur selbst verwalten oder von speziellen Dienstleistern bereitstellen lassen. Bei hoher Nutzung einer Website würde dieses Setup sowohl im Frontend als auch im Backend als Cluster mehrerer Maschinen ausgeführt. Die Clusterfähigkeit der einzelnen Datenbanken soll jedoch nicht als Kriterium in den Wettbewerb eingehen.
Bei der Hardware selbst handelt es sich um Server-PCs mit einem 3-GHz-Intel-Prozessor, einem Gigabyte RAM sowie einer 150-GByte-SATA-Festplatte. Als Betriebssysteme kommen Windows 2003 Server sowie Suse-Linux 9.3 zum Einsatz, als Web-Server stehen die aktuellen Versionen von Apache2 und dem IIS für Windows zur Verfügung. Für Middleware und Zusatzprogramme gelten grundsätzlich keine Beschränkungen. Wer hier allerdings kommerzielle Komponenten einsetzt, muss dafür sorgen, dass der Redaktion eine entsprechende Testversion der Komponente unentgeltlich zur Verfügung steht. Die Komponenten selbst sollen ohne Entwicklungsumgebung installierbar sein, das heißt sie müssen für die gegebenen Plattformen vorkompiliert und im entsprechenden Installationsformat (.exe,.msi,.rpm) vorliegen.
Die eingereichten Lösungen sollten mindestens so weit dokumentiert werden, dass eine problemlose Installation möglich ist. Wir bitten um entsprechend ausführliche Dokumentation, sobald exotischere Varianten von Datenbanken und Middleware oder ungewöhnliche Lösungswege zum Einsatz kommen. Darüber hinaus interessiert uns besonders der zeitliche Aufwand, den die Erstellung der Anwendung beansprucht hat. Sollten zur Entwicklung externe Bibliotheken oder Software verwendet worden sein, deren Herkunft sich nicht auf den ersten Blick erschließt, bitten wir um entsprechende Hinweise. Schließlich muss jeder Teilnehmer aus nahe liegenden Gründen unwiderruflich der Veröffentlichung seiner Einsendung in Print- und Online-Medien des Heise-Verlages zustimmen. (hos)
