Benchmarks kranken oft an Definitionsnotstand und Ungereimtheiten:Zu simpler Testaufbau kann Ergebnis verzerren

09.05.1986

Die steigende Nachfrage nach Datenbanksystemen hat inzwischen zu einer Angebotsvielfalt und teilweise zu Marketingmethoden geführt, die dem künftigen Anwender solcher Systeme Test, Auswahl und Bewertung nicht gerade erleichtern. So mancher Marketier verrenkt sich, wenn es darum geht, alte DBMS-Produkte werblich in neue, "relationale" Kleider zu hüllen. Da begeben sich doch einige leicht in die Nähe dessen, was man in anderen Branchen sofort als Etikettenschwindel und Mogelpackung bezeichnen würde.

Software vergleichend und neutral zu beurteilen, ist immer schon schwierig gewesen. Datenbanken machen hier keine Ausnahme. Im Gegenteil: Ihre unterschiedlichen Architekturen und die nicht unproblematische Definition von Transaktionen erschweren vor allen Dingen generelle Vergleiche. Es stellt sich die Frage, inwieweit Benchmarks - für viele noch eine heilige Kuh - bei der Leistungs- und Funktionsbeurteilung einer DBMS noch sinnvoll sind.

Die Anforderungen an Datenbanken sind gestiegen. Der Benutzer erwartet ständig mehr von seinem System. Dies betrifft die Funktionalität und die Performance gleichermaßen. So braucht der Anwender möglichst vor seiner DB-Entscheidung Antworten auf solch scheinbar einfache Fragen wie:

- Bietet mir dieses oder jenes DBMS die Funktionen, um das heutige und künftige Spektrum meiner Anwendung abzudecken?

- Unterstützt das System die unterschiedlichsten Arten von Anwendungen und ist es offen für neue Gebiete der Anwendungsentwicklung?

- Wie effizient sind die Tools und die Datenbanksprachen, so daß Anwendungsprogrammierer produktiver werden und den Anwendungsrückstau verringern können?

- Wie einfach ist das System anzuwenden und zu erlernen?

- Inwieweit ist auf dem jeweiligen DBMS basierende Anwendungssoftware hardwareunabhängig, um die Softwareinvestitionen längerfristig zu schützen und die Möglichkeit offenzulassen, neue Hardwaretechnologien mit verbessertem Preis-Leistungs-Verhältnis zu nutzen?

- Nutzt das DBMS die Möglichkeiten der Hardware, und wie ist das Zeitverhalten und der Durchsatz?

- Kann das DBMS zusätzliche Anwendungen, die wachsende Zahl von Transaktionen und weitere Benutzer in der vorgeschriebenen Zeit bedienen?

Dies sind in der Tat simple Fragen. Aber beantworten lassen sie sich nur schwer, da es sich hier weitestgehend um schlecht quantifizierbare Faktoren handelt. Insbesondere die auf die Performance zielenden Fragen lassen sich nur dann befriedigend beantworten, wenn die Anwendung erstellt wird. Da dieser Aufwand in der Mehrheit der Fälle von niemandem zu vertreten ist, verwendet man zur quantitativen Messung eines Datenbanksystems und auch zur Beurteilung der Funktionalität "Benchmarks" (engl. benchmark = Höhenmarke).

Das Verhalten der Datenbanksysteme soll auf verschiedenen Rechnern unter unterschiedlichsten Variationen getestet werden. Bezüglich der Programme wird auf Standard-Benchmarks und synthetische Benchmarks, die nicht dem laufenden Betrieb entnommen werden, oder auf eine Programm-Auswahl der derzeitigen Produktion zurückgegriffen, wobei natürlich Anwendungsverlagerungen unberücksichtigt bleiben.

Die Fragwürdigkeit dieser Methode ist hinreichend bekannt. Viele Kritiker haben darauf hingewiesen, daß Benchmarks nur begrenzte Aussagekraft haben. Dies hindert allerdings weder Unternehmensberater noch Hochschulen, DB-Auswahlgremien oder die Marketiers einiger Datenbank-Anbieter daran, auf die "Glaubwürdigkeit" des ansonsten "wissenschaftlich fundierten" Verfahrens zu pochen. Für Strenggläubige in Sachen Benchmark und für Alibisucher wird ausreichend Material bereitgestellt.

Die Vertreter dieses Verfahrens treten auf, als verfügten sie über eine "wissenschaftlich objektive " Methode, die von Anwendungen und Hardwarearchitekturen unabhängig sei. Brian Cassidy, Vice-President eines bekannten DBMS-Anbieters, sagte jüngst, daß die Verfechter von Benchmarks dem erlegen sind, was man die "Tyrannei der Quantifizierung" nennen kann, und es sei nicht nur die Idee, die mit Fehlern behaftet sei, sondern es sei auch die Objektivität der Methode, die in Zweifel gezogen werden muß. Cassidy meint, daß Benchmarks und deren Interpretation auf zwei wesentlichen Trugschlüssen beruhen: Quantifizierung und Rangzuweisung.

Vorteile einzelner Faktoren nicht isoliert betrachten

Besteht die Auswahl zwischen mehreren Möglichkeiten, so glauben viele Entscheider, daß sich die Wahl (...)on selbst ergibt, wenn sie die Vorteile jeder Möglichkeit isoliert zu einem Einzelposten herunterbrechen. Die Isolierung eines einzelnen Faktors schließt eine willkürliche Definition jenes Faktors und seine Prüfung unter ungerechtfertigt vereinfachten Bedingungen ein.

Da werden Tabellen von Möglichkeiten erstellt und für jede wünschenswerte Eigenschaft Punkte aus zum Beispiel zehn möglichen Punkten vergeben. Der Gewinner wird durch einfache Rangzuweisung ermittelt. Durch Variationen und Gewichtungen verpaßt man dieser Methode schnell noch den wissenschaftlichen Hintergrund. Aber warum werden gerade zehn mögliche Punkte bestimmt; warum nicht zwanzig oder hundert? Wenn das so wäre, könnten die Endergebnisse in geradezu dramatischer Weise anders ausfallen.

Das Ziel wissenschaftlicher Methoden ist Objektivität. Experimente sollten wiederholbar und veröffentlichte Ergebnisse vollständig sein. Statistische Verfahren sollten detailliert erläutert und Schlußfolgerungen frei von Vorurteilen aufgrund eigener Erwartungen und Wünsche sein. Wie objektiv sind Benchmarks? Die exakte Wiederholung eines Benchmarks ist reine Theorie. Die Reproduktion erfordert verhältnismäßig hohe Investitionen an Geld und Zeit. Auch ist es oft nicht möglich, die Hardware- und Betriebssystemkonfiguration in allen getesteten Variationen - zum Beispiel Zu- und Abschalten von Memorykapazität oder Cache-Speichern, Multiprozessorvariationen, Peripherievariationen, Systemsoftwarevariationen - genau zu duplizieren.

Die publizierten Beschreibungen eines Benchmarks sind häufig unvollständig und schnell veraltet. So kursieren Testergebnisse, die einerseits auf überholten Softwareversionen beruhen und andererseits mit den neuesten Versionen alternativer Systeme verglichen werden. Immerhin ist es leichter, die Glaubwürdigkeit eines veröffentlichten Benchmarks zu akzeptieren, als sich der harten Arbeit zu stellen und das Experiment zu wiederholen.

Benchmarks können in die Irre führen, wenn sie - aus Mangel an Kenntnis oder absichtlich - in keiner Weise das AnforderungspIofil widerspiegeln. Beispiel: Bevorzugung von Aufgabenstellungen, die CPU-intensiv sind, wenn l/O-orientierte Aufgaben tatsächlich gefordert sind.

Oder die auf frühere Beurteilungen gerichtete subjektive Betrachtungsweise: Wenn das Experiment es zuläßt, das Ergebnis im Sinne der Erwartungen zu beeinflussen, werden die Resultate entsprechend ausfallen. Ein Mechanismus, der häufig unbewußt abläuft.

Benchmarks können keine Aussagen liefern, wenn der Test zu stark vereinfacht wird. Die meisten DBMS-Benchmarks konzentrieren sich zum Beispiel auf Einzelbenutzerbetrieb, während eine Mehrbenutzer-Umgebung erwartet wird. Man kann nicht die Ergebnisse einer Einzelbenutzer-Umgebung hochrechnen und mit Zuverlässigkeit sagen, was im Falle des Mehrbenutzerbetriebes geschehen wird.

Ebenso gibt es Aufgaben, für die Benchmarks objektiv kaum zusammenzustellen sind, zum Beispiel Platzbuchungs- und Reservierunqssysteme der Fluggesellschaften. Die Erfahrungen lehren, daß das Testen mit einer synthetischen Datenbank - die man in diesem Falle bilden müßte - nicht die Anwendungsdatenbank ersetzen kann und der Test einfach Verzerrungen liefern muß.

Wie groß sollte überhaupt die Testdatenbank sein, und was ist mit Größe gemeint? Einfach die tatsächliche Größe in Bytes, oder die Anzahl der Transaktionen - oder beides? Und was verstehen die einzelnen unter einer Transaktion? Sollte es etwa Standardtransaktionen geben?

Geht es darum, verschiedene relationale Systeme zu vergleichen, können detaillierte Fragen gestellt werden. Eine relationale Datenbank wird von den Benutzern als eine Ansammlung von Tabellen gesehen, die sich wie irgendwelche andere Tabellen (Telefonbücher, Flugpläne) aus Spalten und Zeilen aufbauen. Hier können Fragen zum Beispiel so gestellt werden:

- Anzahl der Tabellen?

- Anzahl der Zeilen pro Tabelle?

- Die Verteilung von Attributwerten in den Zeilen?

Dennoch ist die Frage bezüglich der Größe der Datenbank und der Anzahl der Transaktionen sowie deren Komplexität nicht leicht zu beantworten. Definitionsnotstand und Ungereimtheiten begleiten so manchen Benchmark.

Seit es Datenbanksysteme gibt, existieren auch Versuche, sie zu vergleichen und in einer Rangfolge zu bewerten. Wenn man Benchmarks aufgibt, müssen sie durch Alternativen ersetzt werden. Wichtiger als vergleichende Verfahren sind Mechanismen, die die Kalibrierung eines gegebenen DBMS anhand eines bekannten Anwendungsmix gestatten. Im Idealfall muß ein Kalibrierwerkzeug vorhanden sein, das im Mehrbenutzerbetrieb die Fähigkeiten des DBMS demonstriert und ein reales Anwendungsmix in unterschiedlichsten Systemumgebungsvariationen unterstützt.

Welche Funktionen sollte ein geeignetes Kalibrierwerkzeug aufweisen?

Portabilität: Das Werkzeug muß in der Lage sein, das Verhalten des Ziel-DBMS über möglichst viele Hardware-/Betriebssystem-Kombinationen festzustellen - sei es auf mehrplatzfähigen Mikros, Minis oder Mainframes.

Das Werkzeug muß die Simulation eines umfangreichen Transaktionsumfeldes zulassen. Beispiele: 1 bis n Terminals simulieren; das Locking-Verhalten feststellen, indem man eine Transaktion auf allen Terminals laufen läßt; Transaktionssequenzen von einem Terminal und von mehreren Terminals starten. Die Transaktionen dürfen nicht trivialer Natur sein, da die meisten realen Transaktionen komplexerer Art sind.

Daß Kalibrierwerkzeuge Benchmarks ersetzen können, ist in der Praxis bewiesen worden. So hat zum Beispiel ein Anwender aus der chemischen Industrie mit der Kombination von Prototyping-Verfahren und einem Kalibrierwerkzeug die Eignung eines Ziel-DBMS erfolgreich untersuchen können und direkt festgestellt, ob das DBMS für seine Anwendungen geeignet ist. Dieser Anwender wird dasselbe Werkzeug nutzen, um zukünftige Hardware-/Softwarekonfigurationen zu bestimmen, die für die Lösung vorgegebener Anwendungen benötigt werden.

Wenn es um das Thema Datenbank-Auswahl geht und dabei insbesondere die Performance berücksichtigt wird, so führt kein Weg daran vorbei, auch auf die allzuoft falschen Schlußfolgerungen über die Performance von relationalen Systemen einzugehen. Denn leider wird immer noch der übliche Fehler begangen: Die Zeit, die für eine einfache, statisch vordefinierte Transaktion eines herkömmlichen Systems verbraucht wird, vergleicht man mit der für eine komplexe, durch ein relationales Datenbanksystem zu lösenden Aufgabenstellung, bei der gleichzeitig der Komfort eines RDBMS genutzt wird.

Es sollte sorgfältiger darauf geachtet werden, daß an beide Systeme gleiche Bedingungen gestellt werden. Mit Sicherheit würden sich die Ergebnisse zugunsten der relationalen Systeme deutlich verbessern.

Ein relationales System befaßt sich mit dem logischen Datenmodell, das heißt mit der Art, wie Daten dem Endbenutzer präsentiert werden. Die Performance des Datenbanksystems muß aber nicht von dem logischen Datenmodell abhängen, sondern von der Art, wie die Daten physikalisch gespeichert sind, das heißt vom physikalischen Datenmodell. Auf der Basis einer Technik, die als "Multi-Table-Clustering" bekannt ist, optimiert man beispielsweise mit dem DBMS-Oracle das physikalische Datenmodell und bleibt gleichzeitig hundertprozentig unabhängig von dem logischen Datenmodell.

Für Benchmarks gilt zusammenfassend, was Fritjof Capra, der bekannte Physiker und Heisenberg-Schüler, in seinem Buch "Wendezeit" für unser allgemeines Denken und unsere akademischen Disziplinen als so charakteristisch bezeichnete - der weitverbreitete Reduktionismus, der Glaube, alle Aspekte komplexer Phänomene könnten verstanden werden, wenn man sie auf ihre Bestandteile reduziert. Capra empfiehlt, komplex statt linear zu denken - in Netzen und Bögen statt in Zielgeraden, in Werten statt in Quantitäten. Denn die Welt ist mehr als die Summe ihrer Teile. Und Datenbanken sind die Abbildungen realer Welten.

*Gisela Mayer ist Marketingleiterin bei der Oracle Deutschland GmbH, Eschborn.