XML Database Benchmarking
Werbung
XML Database Benchmarking Schriftliche Ausarbeitung im Rahmen des Seminars „Data on the Web“ bei Prof. Dr. Marc H. Scholl und André Seifert im Masterprogramm Information Systems Engineering von Peter Cavadini im Sommersemester 2001 Inhaltsverzeichnis Abstract (Deutsch, English) 3 1. Einführung 3 3 4 1.1 Überblick 1.2 Motivation 2. Typische Charakteristika von Benchmark-Verfahren 5 3. Übersicht verschiedener Benchmark-Verfahren 5 6 7 7 3.1 Beispiele aus der TPC-Benchmark-Familie 3.2 007-Benchmark 3.3 XMach-1 Benchmark 4. Beispiel: XMark Benchmark, Version 1.0 4.1 4.2 4.3 4.4 4.5 4.6 8 8 10 11 12 13 14 Einleitung Beschreibung der Datenbank Hierarchie der Elementstruktur Einschränkungen bezüglich XML-Konstrukten Benchmark-Queries Ergebnisse 5. Zusammenfassung 15 6. Anhang 16 16 17 6.1 Literaturverzeichnis 6.2 Abbildungsverzeichnis 2 Abstract Deutsch Mit den Standardisierungsanstrengungen bei Anfragesprachen für XML-Dokumente steigt das Interesse von Wissenschaft und Industrie an Datenbanktechnologien, die in der Lage sind, die grossen Datenmengen effizient zu handhaben. Wichtige Stichworte sind hierbei die Gültigkeit der Daten, Performancekriterien und die Optimierung der Query-Prozessoren. Das vorliegende Papier begründet, weshalb es sich lohnt, verschiedene XML-Datenbanken bezüglich der genannten Kriterien zu vergleichen. Im weiteren werden dem Verständnis dienliche Grundlagen erläutert und typische Charakteristika verschiedener Benchmark-Tests herausgearbeitet. Sodann werden einige Benchmark-Verfahren kurz erläutert. Zur Veranschaulichung wird schliesslich ein Benchmark-Verfahren für XML-Datenbanken exemplarisch erläutert: Es handelt es sich um den XMark Benchmark des National Research Institute for Mathematics and Computer Science, Amsterdam/Niederlande. Eine Zusammenfassung rundet das Arbeitspapier ab. Abstract English With the standardisation efforts of a query language for XML documents, researchers and users increasingly focus their attention on the database technology. That has to deliver answers on the new challenges of the sheer amount of XML documents produced by applications of the data management: Validation, performance evaluation and optimisation of XML query processors are upcoming issues. This paper illustrates, why it is rewarding to compare different benchmark tests for XML databases. In addition, some basic knowledge necessary for understanding will be explained as well as some typical characteristics. Further, the reader will be informed about some benchmarks. For illustration reasons, one example will be shown: The XMark Benchmark of the National Research Institute for Mathematics and Computer Science, Amsterdam/The Nederlands. Finally, the paper will be completed with a summery. 1. Einführung 1.1 Überblick Im Rahmen dieses Papiers soll in kurzer Form aufgezeigt werden, warum es sich lohnt, Vergleiche zwischen den verschiedenen XML1-Datenbanken anzustellen (Kapitel 1.2ff). Im weiteren wird versucht, in kurzer Form typische Charakteristika von Benchmark2-Verfahren herauszuarbeiten (Kapitel 2). Abschnitt 3 gibt einen groben Überblick über einige Benchmark-Tests und Kapitel 4 behandelt exemplarisch ein Beispiel, nämlich den XMark Benchmark, Version 1.0 des CWI3. Abschnitt 5 fasst den Text abschliessend zusammen. Zwecks Vollständigkeit wird in Kapitel 6 das Literatur- und Abbildungsverzeichnis aufgeführt. 1 2 3 XML = eXtensible Markup Language (engl.): Wörtlich „erweiterbare Auszeichnungssprache“; Ende 1997 vom World Wide Web Consortium (W3C) vorgestellte Beschreibungssprache, die eine reduzierte Variante von SGML (Standardized Generalized Markup Language) darstellt. XML wurde als professionelle Variante zu HTML (Hypertext Markup Language) konzipiert. Das Besondere an XML ist, dass sich eigene Befehle definieren lassen, die die Sprache um Fähigkeiten erweitert, die HTML nicht bietet [Irlbeck 98]. Benchmark (engl.): Wörtlich „Massstab“; numerischer Wert, der mit einem Messverfahren ermittelt wird und Rückschlüsse auf die Leistungsfähigkeit eines Computers, einer Software, einer Bildschirmkarte u.a. Hardwarebestandteile erlauben soll. Benchmarks lassen sich sowohl mit Hilfe einer Stoppuhr als auch mit über speziell für diesen Zweck entwickelte Programme ermitteln. Z.B. werden bei Festplatten die mittlere Zugriffszeit (Access Time) und die Übertragungsgeschwindigkeit (Transfer Speed) gemessen [Irlbeck 98]. CWI: National Research Institute for Mathematics and Computer Science, Amsterdam, Niederlande. 3 1.2 Motivation XML als erweiterbare Auszeichnungssprache berührt mittlerweile alle Felder der Internet-Applikationen und die damit verbundenen riesigen Datenmengen. Aus diesem Grunde interessiert sich eine steigende Anzahl von Content Providern4 für die Weiterentwicklung von Data Management Systemen für grosse Datenmengen. Die Komplexität dieser Herausforderung hat nun auch die Aufmerksamkeit der DatenbankForschungsgemeinde auf sich gezogen. Frühere Anstrengungen konzentrierten sich dabei auf Themen bezüglich Schemata und die Theorie, wie Daten zu organisieren sind, denen ein fixes Schema fehlt und die infolgedessen auf den ersten Blick als nicht kompatibel mit existierenden Technologien scheinen. Unter dem Eindruck des steigenden Einflusses von XML und den damit verbunden kommerziellen Produkten schwenkte der Blick der Forschungsgemeinde schliesslich auf spezifische Themen wie beispielsweise Fragen bezüglich der Performance. Dies wiederum beeinflusst Erfolg oder Misserfolg von Lösungen, die sich noch in der Entwicklungsphase befinden. In jüngster Zeit versuchen Datenbankhersteller, ihre Produkte über die Unterstützung grundlegender XML-Funktionen (z.B. Konvertieren von relationalen Daten in XML-Dokumente) hinaus mit einer Vielzahl an Features zu verkaufen, um die kundenspezifischen Bedürfnisse zu befriedigen. Aber trotz grossen Fortschritten und obwohl die Differenzen zwischen XML- und relationalen- bzw. objekt-relationalen Daten überbrückbar sind, sind die Implikationen der zugrundeliegenden Datenspeicherung heute noch nicht ganz verstanden. XML, definiert als erweiterbare Auszeichnungssprache, bietet im Gegensatz zu (O)RDBMS5 eine natürliche Ordnung der Datenelemente; der String6 ist der Hauptdatentyp, von welchem weitere Datentypen abgeleitet werden, beispielsweise Integer7, Float8 oder gar benutzerdefinierte Datentypen. Extern unterstütze Schemainformationen helfen, exzessive und kostspielige Zwangssituationen zwischen den Datentypen zu vermeiden. Gemessen an der Baumstruktur von XML-Dokumenten und den resultierenden, komplizierten hierarchischen Beziehungen unter den Daten stellen reguläre Pfadausdrücke einen weiteren, essentiellen Bestandteil von Anfragesprachen dar, welche es lohnt zu untersuchen. Frühere Arbeiten haben sich vorwiegend damit beschäftigt, die Fülle der Möglichkeiten zu erfassen, welche durch die neuen Datenmodelle geboten wurden und haben zweifellos wertvolle Hilfe geleistet. Aber die meisten dieser Prototypen wurden "on top", d.h. auf den Daten bzw. Objektspeichern implementiert. D.h. es wurden Standard-API's9 benutzt, ohne direkten Zugang zu den internen Mechanismen eines Produkts. Die Folgerungen sind also nur in bestimmtem Umfange gültig und die Effektivität bestimmter "Mappings" bleibt unklar. In vielen Fällen genügt eine einfache Produkterweiterung, um signifikante Performanceverbesserungen zu bewirken. Aus Komplexitäts-, Interaktions- und Interdependenzgründen10 sind die verschiedenen Systemkomponenten ohne einen abschliessenden, quantitativen Test (kurz: Den richtigen Benchmark) nur schwer einzuschätzen. 4 5 6 7 8 9 10 Content Provider (engl.): Wörtlich „Inhalte-Lieferant“; bieten Inhalte, also Nachrichten, Informationen, Datenbanken in Online-Diensten an [Irlbeck 98]. (O)RDBMS: (Object) Relational Database Management System [Irlbeck 98]. String (engl.): Zeichenkette; eine Zeichenkette ist eine in Anführungszeichen Folge von mehren Zeichen, einschliesslich Leer- und Sonderzeichen. Damit das Ende einer Zeichenkette eindeutig bestimmt ist, darf sie selbst kein Anführungszeichen enthalten. Beispiel: “Das ist eine Zeichenkette“ [Oberon 94]. Integer (engl.): Ganzzahlige (numerische Grund-)Typen [Oberon 94]. Float (engl.): Fliess- oder Gleitkomma; Bezeichnung für das Deklarieren einer Fliesskommavariablen [Irlbeck 98]. API = Application Programming Interface (engl.): Wörtlich Schnittstelle für die Programmierung von Anwenderprogrammen; genormte Schnittstelle, über die ein Programm Dienste vom Betriebssystem erhält. Der Vorteil liegt darin, dass nicht direkt auf die Hardware zugegriffen werden muss, wodurch u.a. Kompatibilitätsprobleme vermieden werden. Ausserdem lassen sich Programme, die API's nutzen, mit geringem Aufwand auf andere Systeme portieren [Irlbeck 98]. Interdependenz: Gegenseitige Abhängigkeit [DF 90]. 4 2. Typische Charakteristika von Benchmark-Verfahren Bisher wurden Benchmark-Verfahren benutzt, um alternative Mapping-Schemata für das Speichern von XML-Daten in relationalen Datenbanken zu vergleichen. Ein Benchmark war zunächst nicht Teil einer Real-World-Application und benutzte ein einziges, künstlich erzeugtes Dokument. Auch wurde Antwortzeit nur Single-Usern für eine Reihe unterschiedlicher Queries und Update-Funktionen auf Basis einer relativ kleinen Datenbank (80MB) zugestanden. Man konnte beobachten, dass für bestimmte Queries relativ kurze Antwortzeiten erreicht wurden, dass aber gleichzeitig die Rekonstruktion eines XML-Dokumentes unverhältnismässig lange dauerte. Ein Single-User-Benchmark misst dabei nicht, wie zu erwarten wäre, die Durchsatzleistung, für viele Benutzer eine Schlüsselgrösse beim XML-Daten-Management. Die Durchsatzleistung ist eine Grösse, die nur Multi-User-Verfahren erfassen können [X-Mach 01]. 3. Übersicht verschiedener Benchmark-Verfahren Es gibt eine Reihe mehr oder weniger standardisierter Benchmark-Verfahren, mit denen man die Leistungsfähigkeit unterschiedlicher DB-Produkte einschliesslich der eingesetzten Hardware und Betriebssystemsoftware bzw. die verschiedenen Anwendungsszenarien bewerten kann. Beispielsweise gibt es eine Anzahl domainspezifischer Benchmark-Verfahren für Entscheidungsunterstützung (z.B. APB-1, TPC-D, TPC-H, TPC-R), Information Retrieval (z.B. Conceptual Clustering in IR) und Spatial (räumliches) Data Management (z.B. Sequoia). Im weiteren gibt es Verfahren für objektorientierte DB (001, 007) bzw. für OLTP11 (z.B. TPC-C) und objekt-relationale DB (z.B. Bucky). Anfang 2000 wurde ausserdem der TPC-W-Benchmark für E-CommerceAnwendungen durch das führende Datenbankkomitee TPC12 released. Zwecks Übersicht seien für den Leser beispielhaft Benchmark-Verfahren für unterschiedliche Datenmodelle bzw. Anwendungsszenarien tabellarisch aufgelistet. Im folgenden Abschnitt werden daraus ausgewählte Verfahren aus der TPC-Benchmark-Familie, der 007-Benchmark sowie der XMach-1 Benchmark in kompakter Form erläutert. - - Benchmark Datenmodell Anwendungsszenario (Beispiele) Objektorientierte DBS: 001, 007 - Decision Support: APB-1, TPC-D, TPC-H, Objekt-relationale DBS: Bucky TPC-R Relationale DBS: Alternative Mapping - E-Commerce: TPC-W Schemes [AMS 99], TPC-C (OLTP), - Information Retrieval: Conceptual Clustering TPC-D in IR Semi-strukturierte /strukturierte DBS: - Spatial Data Management: Sequoia Alternative Mapping Schemes [AMS 99] - XML: XMach-1, XMark, Alternative Mapping Schemes [AMS 99] Abbildung 1: Benchmark-Verfahren mit Datenmodell und Anwendungsszenario. 11 12 OLTP = Online Transaction Processing (engl.): Man unterscheidet zwei Arten von Datenbankanwendungen, nämlich OLTP und OLAP (Online Analytical Transaction Processing). Unter OLTP fallen solche Anwendungen wie „Buchung eines Flugs“ in einem Flugreservierungssystem oder „Verarbeitung einer Bestellung“ in einem Handelsunternehmen. OLTP-Anwendungen realisieren das „operationale Tagesgeschäft“ eines Unternehmens. Sie zeichnen sich dadurch aus, dass sie nur begrenzte Datenmengen für eine auszuführende Transaktion zu verarbeiten haben und sie operieren auf dem jüngsten, aktuell gültigem Zustand des Datenbestands. Demgegenüber verarbeiten OLAP-Anwendungen grosse Datenmengen und greifen insbesondere auf „historische“ Daten zurück, um daraus Rückschlüsse zu gewinnen. Typische OLAP-Anfragen wären in den genannten Beispielszenarien wären z.B. „Entwicklung der Transatlantikflüge der letzten zwei Jahre“ oder „Wie haben sich besonders offensive Marketingstrategien für bestimmte Produktlinien auf die Verkaufszahlen ausgewirkt?“ [DBS 99]. TPC = Transaction Processing Council. 5 3.1 Beispiele aus der TPC-Benchmark-Familie • TPC-C: Der TPC-C-Benchmark modelliert die Auftragsbearbeitung in einem Handelsunternehmen. Diesen Anwendungsbereich eines Datenbanksystems bezeichnet man als OLTP (Online Transaction Processing). OLTP-Anwendungen zeichnen sich durch relativ kurze Transaktionen aus, die i.a. nur auf ein eng begrenztes Datenvolumen zurückgreifen. Das dem Benchmark zugrunde liegende Datenbankschema besteht aus den neun Relationen Warehouse, District, Customer, Order, New-Order, Order-Line, Stock, Item und History (vergleiche [DBS 99], S.443ff). Der TPC-C-Benchmark besteht aus fünf Transaktionen (präziser Transaktionstypen), von denen viele parallel auf der Datenbank ausgeführt werden: New-Order, Payment, Order-Status, Delivery und Stock-Level. Die Transaktion New-Order stellt das „Rückrat“ des TCP-C-Benchmarks dar. Die Leistungsfähigkeit des Systems wird in der Anzahl der pro Minute abgearbeiteten New-Order-Transaktionen angegeben, wobei natürlich pro New-Order auch eine bestimmte Anzahl der anderen vier Transaktionen gleichzeitig ausgeführt werden muss. Weiterhin verlangt der Benchmark, dass 90% der vier zuerst genannten Transaktionen eine Antwortzeit unter fünf Sekunden haben müssen. Die Stock-Level-Transaktion muss in 90% der Fälle innerhalb von 20 Sekunden abgearbeitet sein. Der TPC-C-Benchmark hat zwei Leistungskriterien: Den Durchsatz von New-Order-Transaktionen pro Minute (tpmC) und das Preis-Leistungsverhältnis. Hierbei wird der Gesamtsystempreis, der sich aus Hardware, Software und Softwarewartung für fünf Jahre berechnet, im Verhältnis zum Durchsatz angegeben [DBS 99]. • TPC-D: Genau wie der TPC-C-Benchmark orientiert sich der TPC-D-Benchmark an einem (hypothetischen) Handelsunternehmen. Der TPC-D-Benchmark modelliert aber eine andere Anwendungswelt, nämlich die sog. Decision-Support-Anfragen. Diese Anfragen zeichnen sich dadurch aus, dass die Ergebnismitteilung oft sehr grosse Datenmengen verarbeitet werden müssen. Die Anfragen in Decision-Support-Systemen sind deshalb i.a. recht komplex zu formulieren, zu optimieren und auszuwerten [DBS 99]. • TPC-W: Das TPC-W-Verfahren ist für das Vergleichen von Webtransaktionen bestimmt. Die Arbeitslast (workload) wird in einer kontrollierten E-Commerce-Umgebung des Internets erfasst, wobei die Aktivitäten von geschäftsorientierten Transaktionen eines Webservers simuliert werden. Die Tests beinhalten ein breites Feld an Komponenten, die durch folgende Stichpunkte charakterisiert werden können: Mehrfache Online-Benutzung von Browsern, dynamisches Generieren von Webseiten mit Datenbankanbindung, konsistente Webobjekte, simultanes Ausführen von Mehrfach-Transaktionstypen, Online-Transaktions-Ausführungsmodus, Datenbanken mit vielen unterschiedlich grossen Tabellen, ACID13-Kriterien sowie Gewährleistung des Datenzugangs/-updates. [TPC-W 01]. 13 ACID = Atomicity, Consistency, Isolation, Durability (engl.): Das ACID-Pradigma umfasst die Eigenschaften Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Atomarität: Diese Eigenschaft verlangt, dass eine Transaktion als kleinste, nicht weiter zerlegbare Einheit behandelt wird, d.h. entweder werden alle Änderungen einer Transaktion festgeschrieben oder gar keine. Konsistenz: Eine Transaktion hat nach Beendigung einen konsistenten Datenbankzustand zu hinterlassen. Zwischenzustände, die während der Transaktionsbearbeitung entstehen, dürfen inkonsistent sein, aber der Endzustand muss die Konsistenzbedingungen erfüllen. Isolation: Diese Eigenschaft verlangt, dass parallel ausgeführte Transaktionen sich nicht gegenseitig beeinflussen. Jede Transaktion muss (logisch gesehen) so ausgeführt werden, als wäre sie die einzige Transaktion, die während ihrer gesamten Ausführungszeit auf dem Datenbanksystem aktiv ist. Dauerhaftigkeit: Die Wirkung einer erfolgreich abgeschlossenen Transaktion muss dauerhaft in der Datenbank gespeichert bleiben. Die Transaktionsverwaltung muss sicherstellen, dass dies auch nach einem Systemfehler (z.B. Stromunterbruch) gewährleistet bleibt. Die einzige Möglichkeit, eine erfolgreich abgeschlossene Transaktion ganz oder teilweise aufzuheben besteht darin, eine andere, „kompensierende“ Transaktion auszuführen [DBS 99]. 6 3.2 007-Benchmark Der 007-Benchmark modelliert Objekthierarchien, wie sie in ingenieurwissenschaftlichen Anwendungen (z.B. CAD, CAM) vorkommen. Ein zusammengesetztes Objekt (composite part) besteht aus einem Textdokument und einem Objektnetz von 20, in grösseren Datenbankkonfigurationen 200, Grundbauteilen (atomic parts). Dieses Objektnetz ist in Abbildung 2 durch das Gitter angedeutet. Jede Baugruppe hat eine bidirektionale Beziehung zu drei zusammengesetzten Teilen, die ihrerseits aber Bestandteil mehrerer Baugruppen sein können (shared subobjects). Baugruppen sind nochmals in einer Hierarchie zu komplexen Bauteilen verknüpft. Den Einstiegspunkt zu dieser Hierarchie bildet ein Modul. Bislang wurden im Benchmark nur Datenbanken mit einem Modul generiert. Hier bieten sich Skalierungsmöglichkeiten für künftige Erweiterungen, insbesondere für Mehrbenutzersynchronisation, mit in die Untersuchungen einzubeziehen. In der in Abbildung 2 skizzierten Datenbankstruktur wurden eine Reihe von Traversierungs- und Änderungsoperationen definiert, anhand derer die Leistungsfähigkeit eines objektorientierten Datenbanksystems analysiert werden kann. Die Vorstellung dieser Operationen würde hier zu weit führen, es sei auf die Literatur zum 007-Benchmark verwiesen, wo auch für einige kommerzielle Systeme Leistungskennzahlen veröffentlicht sind [DBS 99]. Abbildung 2: Struktur der 007-Datenbank. 3.3 XMach-1 Benchmark Der XMach-1 Benchmark ist an der Universität Leipzig entwickelt worden und stellt ein MultiUser-Verfahren für Evaluation und Leistungsvergleich von XML-Datenmanagement-Systemen dar. Es basiert auf Webapplikationen und berücksichtigt verschiedene XML-Datentypen, d.h. Textdokumente, Daten ohne Schema oder auch strukturierte Daten. Das Verfahren enthält einen Mix von XML-Queries und Update-Operationen und kann sowohl bei natürlich-sprachlichen XML-DBMS als auch bei relationalen DBMS14 eingesetzt werden. 14 DBMS = Database-Management-System. 7 Abbildung 315 zeigt die Systemanordnung für den XMach-1 Benchmark, bestehend aus den vier Komponenten XML-Datenbank, mehreren Applikations-Servern, Loader- und Browser-Clients. Abbildung 3: Systemanordnung für XMach-1 Benchmark. Die Datenbank enthält die XML-Dokumente in einer Directory-Struktur, wobei die Dokumente von verteilten Quellen mittels Programmen (z.B. Roboter, Crawler u.a.) via Internet geladen werden. Jedes Dokument hat eine eindeutige URL16, die zusammen mit den Metadaten der Dokumente in der Directory-Struktur abgelegt ist. Die Application-Server benutzen einen WebServer sowie weitere Middleware-Komponenten, die den Prozess unterstützen bzw. mit der Backend-Datenbank interagieren. Gemessen werden Antwortzeiten und Durchsatz der XMLDokumente unter genau definierten Bedingungen. 4. Beispiel: XMark Benchmark, Version 1.0 4.1 Einleitung Der XMark Benchmark soll Entwicklern und Benutzern gleichermassen eine Hilfestellung bieten, XML-Datenbanken unabhängig voneinander in deren spezifischen Applikationsszenarien zu vergleichen. Einer langen Tradition in der Datenbankforschung folgend bevorzugt das XML Benchmark Project ein Framework, das ein breites Spektrum von verschiedenen Anfragen, typischerweise in Real-World-Szenarien, berücksichtigt. Dabei enthält das Set aus Sicht der Wissenschaftler des CWI die wichtigsten Aspekte des Query-Processing und reicht von der Betonung des textuellen Charakters eines Dokuments hin zu Queries zwecks Datenanalyse oder typischen Adhoc-Anfragen. Das Query-Set wurde entworfen, um den Query-Prozessor oder die Storage-Engine an partikularen Stellen herauszufordern. Das ist sinnvoll aus einer Reihe von Gründen: 1. Eine featurespezifische Prüfung des Query-Prozessors weist Vor- und Nachteile bei dessen Arbeitsweise in einer Reihe unterschiedlicher Architekturen nach, jede vorgesehen für verschiedene Applikationen mit den entsprechenden Charakteristiken. Beispielsweise bei der Ableitung der XML-Daten von relationalen bzw. objekt-relationalen Daten, von Hauptspeicher- bzw. objektorientierter Datenbanktechnologie oder von textueller Information in Retrieval-Datenstrukturen. Aus diesen Gründen ist bei unterschiedlichen Produkten ein divergierendes Verhalten bezüglich Performance und Stresstests in Abhängigkeit der Systemarchitektur zu erwarten. 15 16 SUT = System under Test. URL = Uniform Resource Locator: Genormte Methode zum Auffinden von Ressourcen im WWW [Irlbeck 98]. 8 2. Das Benchmark-Dokument kann bei der Verifikation des Query-Prozessors helfen, eine Herausforderung seit der Einführung von High-tech-Query-Sprachen. In der Welt der XMLSprachen hat sich die Frage nach der Äquivalenz von XML-Dokumenten verschärft. Der Grad an Freiheit verschieden möglicher physischer Darstellungen der Dokumente wird kombiniert mit dem Freiheitsgrad der Anfrage, Ausführungen bezüglich Attributen, Verschlüsselungen, Namespaces etc. Das XML Benchmark Projekt17 vertritt die Auffassung, dass diesbezüglich noch Forschungsanstrengungen unternommen werden müssen. 3. Das Ausführen des Benchmark-Query-Set bedingt Details bezüglich Workflow, was wiederum mit dem Query-Prozessor in der spezifischen Applikation verbunden ist. Ein Vergleichen hilft in der Konsequenz aber auch, Entwicklungskosten eines spezifischen Systems abzuschätzen und gibt Antworten auf die Frage, welches System die gestellten Anforderungen am besten erfüllt. XML-Prozesse enthalten üblicherweise verschiedene logische Schichten, physisch verteilt über ein Netzwerk. Um nun die Benchmarkresultate interpretierbar zu machen wird das SystemEngineering abstrahiert, d.h. man konzentriert sich auf die Hauptbestandteile: Der Query-Prozessor und dessen Interaktionen mit dem Datenspeicher. Nicht berücksichtigt werden Netzwerk-Overhead (z. B. http18, CORBA19, Java Beans20 etc.), Kommunikationskosten oder Transformationen des Outputs (z.B. XSL21). Abbildung 4 zeigt das Workflow Szenario für den XMark-Benchmark. Alle Applikationen sollen auf derselben Maschine laufen. Als Anfragesprache wurde XQuery22 gewählt, eine Verschmelzung verschiedener Sprachen für semi-strukturierte Daten oder XML. Es ist Teil des Standardisierungsprozesses, dass XQuery auch die Wahlsprache vieler Akteure auf diesem Felde ist. Abbildung 4: Workflow Szenario. 17 18 19 20 21 22 XML Benchmark Project: Mit XML Benchmark Project sei jeweils die Gruppe der Wissenschaftler des CWI gemeint. HTTP = Hypertext Transfer Protocoll (engl.): Hypertext-Übertragungsprotokoll, das zur Übertragung von Hypertext-Information im WWW dient [Irlbeck 98]. CORBA = Common Object Request Broker Architecture (engl.): Gemeinsame Architektur für Objektanforderungs-Vermittler; von IBM, DEC, AT&T und anderen Firmen entwickelte Architektur, die die Bearbeitung von Compound-Dokumenten regelt, speziell von solchen, auf die über ein Netzwerk zugegriffen wird. Der Datenaustauschstandard (OpenDoc) basiert auf CORBA [Irlbeck 98]. Java Beans (engl.): Wörtlich Kaffeebohnen; von Sun definiertes Model für austauschbare, universelle Softwarekomponenten, geschrieben in der Programmiersprache Java. Hierdurch soll vor allem die Programmierung in visuellen Entwicklungssystemen erleichtert und standardisiert werden. Java Beans ist das Konkurrenzprodukt der ActiveX-Steuerelemente von Microsoft. Java Beans bieten den Vorteil der Unabhängigkeit von der jeweiligen Plattform [Irlbeck 98]. XSL = eXtensible Stylesheet Language (engl.): Stellt eine Sprache für das Ausdrücken von CSS (Cascading Style Sheets) dar, bestehend aus den beiden Teilen „Transformieren von XML-Dokumenten“ und „XML-Vokabular zwecks Spezifikation der Formatierungs-Semantik“. XQuery: Relativ kleine, einfach implementierbare und flexible Anfragesprache für XML-Dokumente nach dem Standard des W3C (WWW-Council). 9 Das Zielpublikum von XMark kann in 3 Gruppen eingeteilt werden: • Datenbankhersteller, die ihre Query-Prozessoren verifizieren, vergleichen und verbessern wollen • DB-Kunden, die zwischen verschiedenen Produkten wählen möchten und mit XMark ein Instrument erhalten, die zentralen Elemente des Zielsystems einer Prüfung zu unterziehen. • Wissenschaftler/Forscher, denen der Test hilft, existierende Technologien bezüglich XMLEinstellungen zu prüfen und gegebenenfalls das Design der Algorithmen zu überarbeiten. 4.2 Beschreibung der Datenbank Die Entwicklung von XML unterscheidet sich signifikant von der Entwicklung relationaler Datenbanken, wo schon zu einem frühen Zeitpunkt eine Standardisierung zustande gekommen war, akzeptiert und unterstützt von einer breiten Gemeinde. Aus diesem Grunde glaubt das XML Benchmark Project, das eine Kombination von traditionellen und neuen Features in XML Processing Systemen eine neue Qualität des System-Engineering und ebenso einen neuen Benchmark verlangt. Während gezeigt wurde, dass sich datenzentrierte Dokumente, d.h. alle Dokumente mit logischen Datenstrukturen relativ elegant in relationalen (siehe [STZ 99], [FK 99], [SKWW 00] oder objekt-relationalen (siehe [KM 00]) Datenbanken erfassen lassen ist es weniger klar, wie sich natürlichsprachige, mit Markierungen durchsetzte Dokumente handhaben lassen. Deshalb führt das XML Benchmark Project zusammenfassend einige Hinweise auf, wie unterschiedliche DBMS-Architekturen auf die Herausforderung von XML reagieren können: 1. 2. 3. 4. Die textuelle Anordnung von XML-Strukturen im Originaldokument kann mit Queries geprüft werden: Ein Feature macht dies mit einfachen Look-up-Queries in Systemen möglich, die hierfür nicht vorgesehen sind. Der String ist der Basisdatentyp; sie können durch die Veränderung ihrer Länge zusätzliche Speicherprobleme aufwerfen. Typenprobleme können ausserdem durch Widersprüche zwischen Typingregeln oder Anfragesprache und den generischen String-Tokens23 von XML entstehen. Queries enthalten hierarchische Strukturen in Form von komplizierten Pfadausdrücken; speziell 1:n-Beziehungen in Verbindung mit einer Ordnung tendieren in relationalen Systemen zu aufwendigen Join24- und Aggregation25-Operationen. Aus Sicht des Anwenders können Query-Anfragen gegebenenfalls weitschweifig werden; lange Spezifikationen und komplizierte Pfadausdrücke erhöhen für den Anwender das Risiko, fehlerhafte Eingaben zu produzieren. Aus technischer Sicht besteht das Problem, dass NULL-Werte die Datenbank aufblähen. Eine Reihe von Aktivitäten versuchen, die genannten Problematiken dadurch zu entschärfen, dass datenzentrierte Dokumente vermehrt für (O)RDBMS mittels Neuformulieren der Bedingungen innerhalb des XML-Dokumentes zugänglich gemacht werden. Dieser Ansatz kann tatsächlich viele Probleme lösen, bedingt aber zusätzliche Entwicklungsanstrengungen, die 23 24 25 Token (engl.): Wörtlich Kurzzeichen bei Programmiersprachen eine platzsparende Form bei Speicherung von Befehlen im Quellcode. Statt den einzelnen Zeichen des Befehls PRINT USING wird z. B. nur ein numerischer Wert gespeichert, der aus einem oder zwei Byte(s) besteht. Die genauen Werte hängen vom eingesetzten Compiler bzw. Interpreter ab. Der Nachteil des Verfahrens liegt darin, dass der Quellcode nicht mit einem beliebigen Editor, sondern mit dem Compiler bzw. Interpreter gelieferten Editor bearbeitet werden kann [Irlbeck 98]. Join (engl.): Der natürliche Verbund (natural Join) ist logisch gesehen das Kreuzprodukt von zwei oder mehr Relationen, deren Attributwerte für gleich benannte Attribute der Argumentrelationen gleich sind [DBS 99]. Aggregation (engl.): Aggregatfunktionen führen Operationen auf Tupelmengen durch und komprimieren eine Menge von Werten zu einem einzelnen Wert. Zu ihnen gehört avg (average) zur Bestimmung des Durchschnitts einer Menge von Zahlen, max und min zur Bestimmung des grössten bzw. kleinsten Elementes und sum zur Bildung der Summe; count zählt die Anzahl der Zeilen einer Tabelle [DBS 99]. 10 einige der „Quick-and-easy-to-use-Eigenschaften“ von XML opfert, die XML so beliebt und so schnell verbreitet hat. Das Design von XML verlangt gut modellierte Datenbankbeispiele, um die Queries formulierbar und aussagekräftig zu halten. Aus diesem Grunde sollen im Folgenden die technischen Spezifikationen beim Generieren eines solchen Dokumentes genauer untersucht werden. 4.3 Hierarchie der Elementstruktur Das Ineinandernesten von Elementen verlangt eine Baumstruktur über das gesamte XMLDokument. In diesem Abschnitt wird deshalb die Struktur eines Dokumentes beschrieben, das nach einer Datenbank für Internet-Auktionen modelliert ist. Die wichtigsten Entities26 sind: person, open_auctions, closed_auctions, item und category. Die Beziehungen zwischen den Entities werden mittels Referenzen auf Notationsausnahmen und mittels Beschreibungen ausgedrückt, die gemäss natürlichsprachigen Text und dokumentzentrierten Elementstrukturen in Subbäumen schematisch zusammengehören. Das hierarchische Schema zwischen den meisten der benötigten Entities wird in Abbildung 5 dargestellt. Abbildung 5: Element Beziehungen zwischen den meisten der benötigten Entities. Die Semantik27 der Entities kann wie folgt interpretiert werden: 1. 26 27 Items (Gegenstände) sind jene Objekte, die zum Verkauf stehen oder die bereits verkauft wurden. Jedes Item hat eine eindeutige Bezeichnung und enthält Eigenschaften wie z. B. Zahlungsart (Kreditkarte, Überweisungsart etc.), Referenz zum Verkäufer, eine Produktbeschreibung usw. Alle Items sind als Elemente codiert und über die „Eltern“ einer Region der Erde zugeordnet. Entity (engl.): Wörtlich Gegenstände; sind wohlunterscheidbare physisch oder gedanklich existierende Konzepte der zu modellierenden Welt. Man abstrahiert ähnliche Gegenstandstypen (Entity-Typen oder Entity-Mengen), die man graphisch als Rechtecke darstellt, wobei der Name des Entity-Typs innerhalb des Rechtecks angegeben wird. Beziehungen (Relationships) werden auf analoge Weise zu Beziehungstypen abstrahiert. Die Beziehungstypen werden als Rauten mit entsprechender Beschriftung dargestellt. Die Rauten werden über ungerichtete Kanten verbunden [DBS 99]. Semantik: 1. Teilgebiet der Linguistik auf den man sich mit den Bedeutungen sprachlicher Zeichen und Zeichenfolgen befasst. 2. Bedeutung, Inhalt eines Wortes, Satzes oder Textes [DF 90]. 11 2. 3. 4. 5. Open auctions sind „aktive“ Auktionen. Deren Eigenschaften sind Status, Biethistorie mit entsprechenden Referenzen zum Anbieter und Nachfrager, das aktuelle Gebot, DefaultWerte, Auktionstyp, Zeitintervalle bis dahin Gebote akzeptiert werden sowie Transaktionsstatus. Closed auctions sind beendete Auktionen. Deren Eigenschaften sind Anbieter und Käufer (Referenzen zu Personen), eine Referenz zum entsprechenden Item, Preis, Anzahl verkaufte Items, Transkaktionsdatum, Transaktionstyp und Annotationen vor, während und nach dem Bietprozess. Personen (persons) sind charakterisiert durch Name, Emailadresse, Telefonnummer, Homepage URL, Creditkartennummer, Interessensprofil und das Set offener Auktionen, das sie beobachten. Kategorien (categories) enthalten einen Namen und eine Beschreibung; sie werden benutzt um Klassifikationen eines Items zu implementieren. Diese Entities stellen den strukturierten und datenorientierten Teil des Dokumentes dar. Das Schema ist regulär und Ausnahmen (eine Person hat beispielsweise keine Homepage) sind vorhersehbar. Abgesehen von gelegentlichen Listen (z.B. die Biethistorie) ist die Eingabereihenfolge nicht relevant. Das ist im starken Kontrast zur Annotation und Beschreibung der Elemente. Interne Struktur und Stringlänge der Subelemente variieren stark. Das „Markup“ fasst gegenstandsbezogene (itemized) Listen, Schlüsselwörter und sogar Formatierungsinstruktionen und Schriftinformationen zusammen und versucht, den natürlichsprachigen Text zu imitieren. Damit wird gewährleistet, dass Datenbanken den vollen Umfang der durch XML gebotenen Möglichkeiten enthalten. Abbildung 6 gibt einen Überblick über die Beziehungen der Entities untereinander: Abbildung 6: Referenzen. 4.4 Einschränkungen bezüglich XML-Konstrukten Die im XML-Standard definierten Konstrukte sind sinnvoll für das Produzieren von flexiblen Markups, rechtfertigen aber keine Query-Definitionen, die ihn direkt herausfordern. Aus diesem Grunde beschränkt sich das XML Benchmark Project auf ein Set von limitierten XML-Features im Datengenerator, der als essentiell angesehen wird. Es werden keine Entities oder Notationen generiert. Weiter wird nicht zwischen Zeicheninformationen von Parsern und Parserdaten unterschieden. Ausserdem werden keine Namespaces in den Queries berücksichtigt. 12 Das XML Benchmark Project verwendet den 7-Bit-ASCII28-Zeichensatz. Unterstützt werden DTD-29 und XML-Schemainformationen, welche einen effizienteren Transformationsvorgang erlauben. Im Rahmen des Projektes wurde ausserdem ein XML-Generator implementiert, der die Skalierung von XML-Datenbanken unterstützt. 4.5 Benchmark-Queries Exemplarisch und in verkürzter Form werden in diesem Abschnitt fünf der in [BP 01] aufgeführten Queries diskutiert. Die Anfragen wurden in XQuery formuliert. • Query 1: Gib den Namen des Items mit dem ID 20748, registriert in Nordamerika, zurück. Abbildung 7: Query 1. • Query 2: Gib das Initialangebot für alle offenen Auktionen zurück. Abbildung 8: Query 2. • Query 3: Gib das erste und das aktuelle Angebot für alle offenen Auktionen zurück, bei denen gilt, dass das aktuelle Angebot mindestens zweimal so hoch ist wie das ursprüngliche Angebot. Abbildung 9: Query 3. • Query 4: Liste jene offenen Auktionen auf, bei denen eine bestimmte Person ein Angebot vor einer anderen (bestimmten) Person gemacht hat. Abbildung 10: Query 4. • Query 5: Wieviel der verkauften Gegenstände kosten mehr als 40 (Währungseinheiten)? Abbildung 11: Query 5. 28 29 ASCII= American Standard Code for Information Interchange: Wörtlich: Amerikanischer Standardcode zum Informationsaustausch [Irlbeck 98]. DTD = Document Type Definition [Irlbeck 98]. 13 4.6 Ergebnisse Um dem Leser einen Eindruck über die Grössenverhältnisse der mit XMark gemessenen Werte zu geben, wird in diesem Kapitel die Liste mit den Resultaten publiziert. Die Ergebnisse korrespondieren mit den im vorherigen Kapitel auszugsweise aufgeführten Queries. Die Ergebnisse wurden auf einem Silicon Graphics 1400 Server mit 1GB Hauptspeicher und 18 GB SCSI Festplatte ermittelt. Als Betriebssystem wurde Linux Version 6.2 eingesetzt. Abbildung 12: Messresultate.30 Das Benchmark-Dokument war mit 1.0 skaliert. Das Einlesen der „Nutzlast“ (bulk load, 116 MB) dauerte 49.7 Sekunden. In dieser Zeit enthalten sind Parsen des Dokumentes, Transformieren des Textes in relationale Tabellen und das Schreiben der Tabellen in den Speicher. Der Mapping-Prozess von Monet-XML arbeitet ohne DTD’s und generiert das Datenbankschema „onthe-fly“. Es sollen im folgenden die Ergebnisse 1-5 interpretiert werden: • Ergebnis zu Query 1: Q1 enthält das Scannen der Tabelle über ca. 1000 Tupel sowie zwei Look-up’s. Da Monet einen Hauptspeicher-Kernel besitzt, sind diese Operationen (mit verhältnismässig kleiner Datenmenge) relativ schnell. • Ergebnisse zu Query 2 und 3: Q2 und Q3 haben Überraschendes zu bieten; es stellte sich heraus, dass Teile der Anfrage komplexe Aggregationen zur Folge hatten. Mit der hohen Komplexität der harmlos scheinenden Anfragen stieg die gemessene Zeit entsprechend an. Die Antwortzeit war relativ schlecht. • Ergebnis zu Query 4: Q4 enthält das „Before-Prädikat"; es konnte die globale Ordnung abgefragt werden, was keine besondere Herausforderung darstellte. Entsprechend schnell war der Response. 30 RP = Repetition Factor (engl.): Wörtlich Wiederholungsfaktor. Mit Monet ist ein Hauptspeicher-Kernel gemeint, dessen Operationen relativ schnell sind, der aber verhältnismässig wenig Datenvolumen enthält. 14 • Ergebnis zu Query 5: Q5 enthält ähnliche Elemente, wie sie zur Beantwortung von Q3 notwendig sind. Bedenkt man die relative Komplexität von Q3, so ist das Ergebnis auf die Anfrage mit 161ms doch schneller als erwartet. Es sei aber festgehalten, dass alle benötigten Informationen (inkl. Referenzen) im Originaldokument als Strings gespeichert sind und nicht wie in Q3 ein reicherer Datentyp zur Laufzeit generiert werden musste. 5. Zusammenfassung • Motivation: Mittlerweile berührt XML alle Felder der Internet-Applikationen mit den damit verbundenen riesigen Datenmengen. Aus diesem Grunde interessiert sich eine steigende Anzahl von Content Providern für die Weiterentwicklung von Data Management Systemen. Aus Komplexitäts-, Interaktions- und Interdependenzgründen sind die verschiedenen Systemkomponenten ohne einen abschliessenden, quantitativen Test (Benchmark) nur schwer einzuschätzen. • Charakteristika von Benchmark-Verfahren: Bisher wurden Benchmark-Verfahren benutzt, um alternative Mapping-Schemata für das Speichern von XML-Daten in relationalen Datenbanken zu vergleichen. Ein Benchmark war zunächst nicht Teil einer Real-World-Application und benutzte ein einziges, künstlich erzeugtes Dokument. Auch wurde Antwortzeit nur Single-Usern für eine Reihe unterschiedlicher Queries und Update-Funktionen auf Basis einer relativ kleinen Datenbank (80 MB) zugestanden. Man konnte beobachten, dass für bestimmte Queries relativ kurze Antwortzeiten erreicht wurden, dass aber gleichzeitig die Rekonstruktion eines XML-Dokumentes unverhältnismässig lange dauerte. Ein Single-UserBenchmark misst dabei nicht, wie zu erwarten wäre, die Durchsatzleistung, für viele Benutzer eine Schlüsselgrösse beim XML-Daten-Management. Die Durchsatzleistung ist eine Grösse, die nur Multi-User-Verfahren erfassen können. • Übersicht verschiedener Benchmark-Verfahren: In Kapitel 3 wurden diverse BenchmarkVerfahren für die Anwendungsszenarien Decision Support, E-Commerce, Information Retrieval, objektorientierte bzw. (objekt-) relationale DB-Systeme sowie für Spatial Data Management aufgelistet. Von den aufgeführten Verfahren wurden in kurzer Form Beispiele aus der TPC-Familie (TPC-C: OLTP-Anwendungen; TPC-D: Decision-Support; TPC-W: E-Commerce), der 007-Benchmark (ingenieurwissenschaftliche Anwendungen, z.B. CAD, CAM) sowie XMach-1 (Leistungsvergleich von XML-Datenbanken) erläutert. • XMark Benchmark: In Kapitel 4 wurde der XMark Benchmark, Version 1.0 vorgestellt. Der Benchmark soll Entwicklern und Benutzern gleichermassen eine Hilfestellung bieten, XMLDatenbanken unabhängig voneinander in deren spezifischen Applikationsszenarien zu vergleichen. Der Benchmark bevorzugt ein Framework, das ein breites Spektrum von verschiedenen Anfragen, typischerweise in Real-World-Szenarien, berücksichtigt. Dabei enthält das Set aus Sicht der Wissenschaftler des CWI die wichtigsten Aspekte des Query-Processing und reicht von der Betonung des textuellen Charakters eines Dokuments hin zu Queries zwecks Datenanalyse oder typischen Ad-hoc-Anfragen. Das Query-Set wurde entworfen, um den QueryProzessor oder die Storage-Engine an partikularen Stellen herauszufordern. Schliesslich wurde in Kapitel 4 die XMark-Systemanordnung, die Datenbank, die Hierarchie der Elementstruktur, Einschränkungen bezüglich XML-Konstrukte sowie fünf Queries erläutert und die entsprechenden Benchmark-Ergebnisse interpretiert. 15 6. Anhang 6.1 Literaturverzeichnis [1] [AMS 99]: D. Florescu, D. Kossmann. A Performance Evaluation of Alternative Mapping Schemes for Storing XML Data in a Relational Database. Technical Report No. 3680, INRIA, Le Chesnay Cedex, France, May 1999. Internet: http://dblab.comeng.chungnam.ac.kr/~dolphin/paper/collection/ [2] [BP 01]: A. R. Schmidt, F. Waas, M. L. Kersten, D. Florescu, I. Manolescu, M. J. Carey, R. Busse. The XML Benchmark Project. Technical Report INS-R0103, CWI, Amsterdam, The Netherlands, April 2001. Internet: http://www.xml-benchmark.org oder http://www.cwi.nl/htbin/ins1/publications?request=abstract&key=ScWaKeFlMaCa Bu:TR-CWI:01 [3] [DBS 99]: A. Kemper, A. Eichler. Datenbanksysteme. Oldenburgverlag München und Wien, 1999, 3. Auflage, ISBN 3-486-25053-1. [4] [DF 90]: Wissenschaftlicher Rat der Duden-Redaktion. Duden Fremdwörterbuch. DudenVerlag, 1990, 5. Auflage, ISBN 3-411-20915-1. [5] [FK99] D. Florescu and D. Kossmann. Storing and Querying XML Data using an RDMBS. IEEE Data Engineering Bulletin, 1999. [6] [Irlbeck 98]: Irlbeck, Thomas. Computer-Englisch. dtv-Verlag, 1998, 3. Auflage, ISBN 3423-50303-3. [7] [KM00] M. Klettke and H. Meyer. XML and Object-Relational Database Systems Enhancing Structural Mappings Based on Statistics. In International Workshop on the Web and Databases (in conjunction with ACM SIGMOD), pages 63–68, 2000. [8] [Oberon 94]: Martin Reiser, Niklaus Wirth. Programmieren in Oberon – Das neue Pascal. Addison Wesley (Deutschland) GmbH, 1994, 1. Nachdruck, ISBN 9319-675-9. [9] [SKWW00] A. Schmidt, M. Kersten, M. Windhouwer, and F. Waas. Efficient Relational Storageand Retrieval of XML Documents. In International Workshop on the Web and Databases (in conjunction with ACM SIGMOD), pages 47–52, Dallas, TX, USA, 2000. [10] [TPC-W 01] Transaction Processing Perfomrance Council. Online-Dokumentation zum TPC-W-Benchmark. Internet: http://www.tpc.org/tpcw/default [11] [STZ 99] J. Shanmugasundaram, K. Tufte, C. Zhang, G. He, D. J. DeWitt, and J. F. Naughton. Relational Databases for Querying XML Documents: Limitations and Opportunities. In Proceedings of 25th International Conference on Very Large Data Bases (VLDB), September 7-10, 1999, Edinburgh, Scotland, UK, pages 302–314, 1999. [12] [X-Mach 01]: T. Böhme, E. Rahm. X-Mach-1: A Benchmark for XML Data Management. Proceedings of the German Database Conference (BTW 2001), Oldenburg, Germany, March 2001. Internet: http://dbs.uni-leipzig.de/en/Projekte/XML/XmlBenchmarking.html oder http://dol.uni-leipzig.de/pub/2001-1 16 6.2 Abbildungsverzeichnis • Abbildung 1: Benchmark-Verfahren mit Datenmodell und Anwendungsszenario. • Abbildung 2: Struktur der 007-Datenbank. Aus: [DBS 99], S. 452. • Abbildung 3: Systemanordnung für XMach-1 Benchmark. Aus: [X-Mach 01], Kapitel 4. • Abbildung 4: Workflow Scenario. Aus: [BP 01], S. 3. • Abbildung 5: Element Beziehungen zwischen den meisten der benötigten Entities. Aus: [BP 01], S. 3. • Abbildung 6: Referenzen. Aus: [BP 01], S. 6. • Abbildung 7: Query 1. Aus: [BP 01], S. 8. • Abbildung 8: Query 2. Aus: [BP 01], S. 8. • Abbildung 9: Query 3. Aus: [BP 01], S. 8. • Abbildung 10: Query 4. Aus: [BP 01], S. 8. • Abbildung 11: Query 5. Aus: [BP 01], S. 8. • Abbildung 12: Messresultate. Aus: [BP 01], S. 13. 17
