Performance-Vergleich von PostgreSQL, SQLite, db4o und MongoDB

Transkript

1 Performance-Vergleich von PostgreSQL, SQLite, db4o und MongoDB - Benchmarking und Performance von (R)DBMS Seminar Datenbanksysteme Master of Science in Engineering Vertiefungsrichtung Software and Systems HSR Hochschule für Technik Rapperswil Supervisor: Prof. Stefan Keller Autoren: Philippe Morier & Martin Weber Rapperswil, Dezember 2011

2 Kapitel: 1 Abstract Inhalt Abstract... 4 Aufgabenstellung... 5 Stand der Technik Bestehende Benchmarks PostgreSQL SQLite db4o MongoDB Für den Benchmark verwendete Daten Beschaffung & Herkunft Aufbereitung Extraktion Benchmark Definition Aufbau Datenbanken Durchführungsregeln Benchmark-Tests und Benchmark-Ablauf BMT-1 Insert - Einfügen der Test-Daten BMT-2 SelectAll - Abfrage aller Daten BMT-3 Equal - Abfrage auf Gleichheit BMT-4 Small-/Large-Range - Kleine und grosse Bereichsabfrage BMT-5 Join - Abfrage mit Beziehungen Test-Umgebung Effizienz-Kriterien Konfigurationen der DBMS Ergebnisse und Diskussion Herbst /36

3 Kapitel: 1 Abstract 6 Vergleichbarkeitsbasis & Optimierungspotentiale Isolation-Level Datentyp-Sicherheit Einsatz von Index Schlussfolgerung Eigenständigkeitserklärung Glossar Abbildungsverzeichnis Tabellenverzeichnis Literaturverzeichnis Code der Datei benchmark.py Herbst /36

4 Kapitel: 1 Abstract 1 Abstract Das Datenbank-Seminar vom Herbstsemester 2011 steht u.a. unter dem Motto "Benchmarking und Performance von (R)DBMS". Wir entschieden uns für einen Benchmark der folgenden DBMS durchzuführen. PostgreSQL SQLite db4o MongoDB Dabei wurde das vorliegende Dokument wie folgt strukturiert. Zu Beginn wird eine Übersicht über den Stand der Technik der vier ausgewählten DBMS gegeben. Anschliessend wird die Beschaffung und Herkunft der im Benchmark verwendeten Daten kurz beschrieben. Der Begriff Benchmark wird im Kapitel 6 definiert. Zudem wird in diesem Kapitel unter anderem der Aufbau und Ablauf sowie die entstandenen Resultate der Durchführung des Benchmarks aufgezeigt. Der Schluss des Dokumentes befasst sich mit der Vergleichbarkeitsbasis und Optimierungspotenziale sowie eine allgemeine Schlussfolgerung. Die Abfragen für den Benchmark wurden mit der Skript-Sprache Python erstellt. Diese enthalten alle durchgeführten und gemessenen Abfragen. Bei den Daten handelt es sich um Wetterdaten, welche einen Bezug zur Zeit aufweisen. Der Benchmark wurde mit den Out-Of-The-Box Konfigurationen des jeweiligen DBMS durchgeführt. Das DBMS db4o wies mit Abstand die kleinste Performance auf. Keyword: Benchmark, db40, PostgreSQL, MongoDB, SQLite, Wetterdaten, Python, IronPython, PyMongo, DBMS, SQL Herbst /36

5 Kapitel: 2 Aufgabenstellung 2 Aufgabenstellung Ziel dieser Arbeit ist das Erstellen und Durchführen eines Benchmarks für die folgenden vier Datenbankmanagementsysteme (DBMS). PostgreSQL SQLite db4o MongoDB Dabei ist zu beachten, dass an den einzelnen DBMS keine Konfigurationsänderungen nach deren Installation durchgeführt werden. D.h. die DBMS werden Out-Of-The-Box verwendet. Des Weiteren soll eine möglichst faire Vergleichbarkeitsbasis geschaffen werden und eine klar spezifizierte Test-Umgebung definiert werden. Zusätzlich soll der Aufbau, Ablauf wie auch die Schwerpunkte des Benchmarks dargestellt werden. Der Benchmark sollte Best-Practice Aufgaben beinhalten und sich allgemein anhand Best-Practice Methoden orientieren. Um die Effizienz der DBMS bestimmen zu können, sollen Effizienzkriterien definiert werden. Die Benchmark-Ergebnisse sollen in einer verständlichen Art und Weise dargestellt werden und mögliche Optimierungspotentiale sollen aufgezeigt werden. Die für den Benchmark verwendeten Daten sollen aus der Meteorologie stammen. Die Benchmark- Daten benötigen einen geografischen und zeitlichen Bezug. D.h. es sollen zeitlich abhängige Wetter- Daten verwendet werden. Zusätzlich soll darauf geachtet werden, dass eine grosse Menge an Daten für den durchzuführenden Benchmark vorliegt. Zum Schluss der Arbeit sollen die Ergebnisse des Benchmarks ausgewertet werden und die daraus gezogenen Schlussfolgerungen aufgezeigt werden. Über das gesamte Dokument hinweg gilt für die inhaltliche Bearbeitung folgende Aufteilung: Martin Weber: SQLite & MongoDB Philippe Morier: PostgreSQL & db4o Herbst /36

6 Kapitel: 3 Stand der Technik 3 Stand der Technik Im folgendem Kapitel wird eine Liste von bestehenden Benchmarks aufgelistet. Zusätzlich werden die Eigenschaften und Spezialitäten der vier Datenbank PostgreSQL, SQLite, db4o und MongoDB beschrieben. 3.1 Bestehende Benchmarks Das Durchführen von Benchmarks hat in der heutigen Informatik eine grosse Bedeutung. Folgend sind Dokumente bzw. Web-Links zum Thema Database Performance Benchmarking aufgelistet. HSR Texas Geo Database Benchmark [TexasBench] Fame Database Performance Benchmark for Time Series Data [FAME] A Practitioner's Introduction to Database Performance Benchmarks and Measurements [OxfordJournals] Transaction Processing Performance Council [TPC] The Engineering Database Benchmark [Cattell] PolePosition Open Source Database Benchmark [PolePosition] Key/Value Pair Versus hstore - Benchmarking Entity-Attribute-Value Structures in PostgreSQL [MOtt] 3.2 PostgreSQL PostgreSQL ist ein objektrelationales Datenbanksystem (ORDBMS), welches im Jahr 1986 als Projekt an der University of California at Berkeley vom Hauptverantwortliche Michael Stonebraker gestartet wurde. Die Anfragesprache SQL von PostgreSQL implementiert weitgehend die Standards ANSI-SQL 92 und bereits einen sehr grossen Teil der verpflichtenden Merkmale des aktuellen SQL:2008 Standard. Somit werden alle gängigen SQL-Funktionalitäten unterstützt und verhalten sich wie erwartet [Postgres]. PostgreSQL wird durch die folgenden Limits eingeschränkt. Max. Datenbankgrösse Max. Tabellengrösse Max. Grösse eines Datensatzes Max. Zellengrösse Max. Anzahl Zeilen pro Tabelle Max. Anzahl der Spalten pro Tabelle Unbeschränkt 32 TB 1.6 TB 1 GB Unbeschränkt (abhängig von verwendeten Datentypen) Herbst /36

7 Kapitel: 3 Stand der Technik Max. Indexes per Table Unbeschränkt Tabelle 3-1: Limits von PostgreSQL [Postgres] Für den Performance-Gewinn bei grossen Datenmengen unterstützt PostgreSQL unique-, partielle und funktionale Indexe. Seit der Version 8.1 können mehrere Indexe im Speicher zu Bitmaps verknüpft und von einem einzigen Index-Scan genutzt werden [PostgresDE]. Die Indexe werden in Form von R-Tree, B-Tree, Hash oder GiST aufgebaut [Postgres]. 3.3 SQLite SQLite ist eine Programmbibliothek, die ein relationales Datenbanksystem enthält und einen Grossteil der im SQL-92-Standard festgelegten SQL-Sprachbefehle unterstützt. Es wurde im Jahr 2000 von Richard Hipp entwickelt und ist in C programmiert [WikiSQLite]. SQLite repräsentiert eine serverlose, konfigurationsfreie und transaktionale Datenbankengin. Ein Hauptmerkmal ist die sehr kleine Speicherplatzgrösse, welche SQLite für das Speichern der ganzen Datenbank benötigt. Je nach Systemplattform und Compiler-Optimierungseinstellung liegt der benötigte Speicherplatz bei ca. 350KB. Dies ist unter anderem ein Grund, warum SQLite häufig in Embedded Systems zum Einsatz kommt [SQLite]. SQLite wird durch die folgenden Limits eingeschränkt. Max. Datenbankgrösse 14 TB Max. involvierte Tabellen in einem Join 64 Max. Grösse eines Datensatzes Bytes = ca. 2 GB Max. Anzahl Zeilen pro Tabelle 2 64 Max. Anzahl der Spalten pro Tabelle Max. Länge eines SQL-Statements 1 GB Tabelle 3-2: Limits von SQLite [SQLimits] 3.4 db4o Das db4o Projekt begann im Jahr 2000 unter Führung von Carl Rosenberger. Db4o ist eine open source Objektdatenbank, welche Java und.net Entwickler ermöglicht, in ihrer Applikation Objekte mit Hilfe von wenigen Codezeilen zu speichern und abzufragen. Das Definieren und Unterhalten eines Datenbankmodells ist nicht notwendig. Db4o gehört zu den NoSQL-Datenbanken. Der Footprint der Datenbank-Bibliothek beträgt ca. 1 MB und der minimale RAM Footprint benötigt normalerweise weniger als 3 MB. Pro Datenbank-Datei ist eine maximale Grösse von 254GB möglich [db4o]. Herbst /36

8 Kapitel: 3 Stand der Technik 3.5 MongoDB MongoDB (von "hu-mongo-us") ist eine skalierbare, hoch-performante, dokumentenorientierte open-source Datenbank, welche in C++ geschrieben ist. Das Projekt startete im Jahr 2007 und hatte 2009 den ersten öffentlichen Release. Bei der Entwicklung von MongoDB wurde besonders auf folgende vier Kriterien geachtet [MongoDB]. Flexibilität Power Geschwindigkeit Einfache Verwendung Tabelle 3-3: Philosophie von MongoDB Eine markante schlecht dokumentiere Begrenzung liegt in der maximalen Dateigrösse von 2.5 GB auf einem 32Bit-System [MongoDB]. Herbst /36

9 Kapitel: 4 Für den Benchmark verwendete Daten 4 Für den Benchmark verwendete Daten 4.1 Beschaffung & Herkunft Die für den Benchmark verwendeten Daten stammen vom Niederschlagsradar von NZZ Online [NZZ]. Der Niederschlagsradar ist in Form einer animierten Bildserie verfügbar. Die Bildserie verwendet das Graphics Interchange Format (GIF) für die Darstellung. Um einen geografischen und zeitlichen Bezug herstellen zu können, müssen zuerst die meteorologischen Daten aus der Bildserie extrahiert werden. Dieser Prozess wird von einer separaten Software-Lösung durchgeführt und für die jeweiligen DBMS in das passende Format gebracht. 4.2 Aufbereitung Abbildung 4-1: Niederschlagsradar von NZZ Online Extraktion Die für uns interessanten Daten sind die eingefärbten Niederschlag-Pixel. Diese müssen also aus der Bilderserie extrahiert werden. Abbildung 4-2: Extraktion der Niederschlag-Pixel Herbst /36

10 Kapitel: 4 Für den Benchmark verwendete Daten Jeder einzelne Niederschlags-Pixel wird in die Datenbank abgespeichert. Dabei werden als Koordinaten die Pixelpositionen vom Bild verwendet. Somit hat beispielsweise ein Niederschlags- Pixel über Rapperswil die X/Y-Koordinaten (351/108). Abbildung 4-3: Einzelner Niederschlags-Pixel Herbst /36

11 Kapitel: 5 Benchmark 5 Benchmark 5.1 Definition Ein Benchmark ist ein klar definiertes Bewertungsverfahren von EDV-Systemen. Dabei werden unterschiedliche Systeme anhand festgelegten Effizienz-Kriterien auf deren Leistung miteinander verglichen. Es existieren Benchmarks für Soft- wie auch für Hardware. In dieser Arbeit werden verschiedene DBMS miteinander verglichen. Das in dieser Arbeit beschriebenen resp. durchgeführten Bewertungsverfahren stellt somit einen Software-Benchmark dar. Das Bewertungsverfahren benötigt eine faire Vergleichbarkeitsbasis um die verschiedenen EDV- Systeme miteinander zu vergleichen. Eine faire Vergleichsbarkeitsbasis beruht auf Definitionen einer Test-Umgebung, Effizienzkriterien und Konfigurationsgrad. Der Ablauf und die Durchführung des Benchmarks auf dem jeweiligen System sollte stets identisch erfolgen. Des Weiteren sollten die im Benchmark durchgeführten Aufgaben Best-Practice Anwendungsfällen entsprechen. 5.2 Aufbau Im folgendem Kapitel wird der Aufbau des Benchmarks erläutert. Dabei wird der Zusammenhang der unterschiedlichen Scripts und Dateien dargestellt. Abbildung 5-1: Aufbau des Benchmarks Der Platzhalter DBName steht jeweils für das konkrete Datenbankmanagementsystem und kann folgende Werte annehmen: postgres sqlite Herbst /36

12 Kapitel: 5 Benchmark db4o mongodb Dies Bedeutet, dass von einer Datei, welche in der oben gezeigten Abbildung den Platzhalter enthält, jeweils vier unterschiedliche Exemplare existieren. _start_[dbname].bat Die Aufgabe der Batch-Dateien liegt darin, das entsprechende Log-File zu löschen und anschliessend die Datei benchmark.py mit der richtigen Konfiguration auszuführen. D.h. es muss der entsprechende Interpreter und die passenden Parameter angegeben werden. Folgende Tabelle zeigt den Inhalt der Batch-Datei für das DBMS db4o. DEL db4o_log.csv ipy benchmark.py -d db4o -n 2 PAUSE Abbildung 5-2: Inhalt der Datei _start_db4o.bat _init_[dbname].py Das init-modul wird für das Erstellen einer sauberen Ausgangslage zur Durchführung des Benchmarks verwendet. Dabei werden alte Datenbanken gelöscht und allfällig durch einen früher durchgeführten Benchmark erstellte Dateien entfernt. In einem weiteren Schritt wird eine leere Datenbank angelegt. Zum Schluss wird die für die weitere Arbeit benötigte Verbindung zur Datenbank erstellt. _insert_[dbname].py Die für den Benchmark benötigten Daten werden durch das insert-modul in die jeweilige Datenbank eingefügt. Insgesamt werden ca Datensätze gespeichert. _queries_[dbname].py Das query-modul enthält folgende für den Benchmark relevanten Datenbankabfragen. Abfrage aller Daten Abfrage auf Gleichheit Kleine und grosse Bereichsabfrage Join-Abfrage benchmarks.py Die Datei benchmark.py stellt einen Rahmen für den Ablauf dar. D.h. sie ruft die datenbankspezifischen Methoden der importierten Module in einer fixen Reihenfolge auf. Für die Ausführung des Benchmarks werden zwei Parameter erwartet. Konkret sind dies der Name des Herbst /36

13 Kapitel: 5 Benchmark DBMS und die Anzahl Durchführungen. Folgendes Beispiel führt den Benchmark für das DBMS db4o zwei Mal durch. benchmark.py -d db4o -n 2 Abbildung 5-3: Ausführung des Benchmarks mit entsprechenden Parameter Das benchmark-modul übernimmt zusätzlich die Zeitmessung und das Logging. Die Zeitmessung wurde vom HSR Texas Geo Database Benchmark [TexasBench] übernommen Datenbanken Die beiden RDBMS PostgreSQL und SQLite enthalten jeweils genau die Tabelle raindrop mit folgendem Aufbau. frameid nextframeid rainfall timestamp x y Tabelle 5-1: Aufbau der Tabelle "raindrop" mit Beispiel Datensätze CREATE TABLE raindrop ( frameid int NOT NULL, nextframeid int NOT NULL, rainfall int NOT NULL, timestamp int NOT NULL, x int NOT NULL, y int NOT NULL ) Abbildung 5-4: Struktur der Tabelle "raindrop" Das objektorientierte DBMS db4o und das dokumentorientierte DBMS MongoDB haben konzeptbedingt keine Tabellen. Da das DBMS db4o in erster Linie nur für Java bzw..net Entwickler zur Verfügung steht, musste mit einer speziellen Python-Implementation namens IronPython gearbeitet werden. Diese ermöglicht das Verwalten von.net-objekte mit db4o aus einem Python-Skript. Das Abspeichern von Python-Objekte führte zum folgendem Fehler. Unexpected char '$' Abbildung 5-5: Fehler beim Abspeichern [IrPyObj] Aus diesem Grund wurde eine.net-library mit dem benötigten Klasse erstellt. Nun werden Instanzen von der.net-klasse mit IronPython in eine db4o -Datenbank abgespeichert [IrPyObj]. Die Struktur der Objekte, welche für das DBMS db4o verwendet werden, sieht wie folgt aus. Herbst /36

14 Kapitel: 5 Benchmark Abbildung 5-6: Klasse "raindrop" Bei dem DBMS MongoDB werden sogenannte Dokumente in Form von BSON (Binary JSON) abgespeichert. Diese Dokumente bzw. Objekte haben folgende Struktur. [{"frameid":1, "nextframeid":2, "rainfall": , "timestamp": , "x":201, "y":13}, {"frameid":1, "nextframeid":2, "rainfall": , "timestamp": , "x":241, "y":54}, {"frameid":2, "nextframeid":3, "rainfall": , "timestamp": , "x":295, "y":90}, {"frameid":3, "nextframeid":4, "rainfall": , "timestamp": , "x":318, "y":120}] Abbildung 5-7: "raindrop"-dokument Damit Objekte über Python in eine MongoDB abgespeichert werden können, muss Python mit der Distribution PyMongo erweitert werden [PyMongo] [Niall] Durchführungsregeln Für die Durchführung des Benchmarks werden die folgenden Regeln befolgt. Jeder Test wird genau sechs Mal hintereinander durchgeführt. Jeder Test wird auf demselben System durchgeführt. Während der Durchführung eines Tests sind die nicht in den Test involvierten DBMS beendet. Die verwendeten Daten aus der Meteorologie stammen aus einem realen Szenario. Jedes DBMS hat dieselben Daten für die Tests gespeichert. Herbst /36

15 Kapitel: 5 Benchmark Die Konfigurationen der installierten DBMS wurden nach deren Installation unverändert belassen. D.h. Jedes DBMS läuft mit den Standard-Einstellungen resp. Konfigurationen und ist somit nicht optimiert (Out-Of-The-Box). 5.3 Benchmark-Tests und Benchmark-Ablauf In diesem Kapitel soll die Reihenfolge und die Art der Abfragen aufgezeigt und erklärt werden. Folgende Auflistung zeigt die Anzahl, Reihenfolge und Art der Interaktionen mit dem entsprechendem DBMS. Zu beachten ist, dass bei jedem Benchmark-Test (BMT) eine allgemein identische Ausgangslage erstellt wird. D.h. allfällige Dateien oder Datenbanken werden gelöscht bzw. neu erstellt. Führe benchmark.py n-mal für Datenbank d aus Stelle Initial-Zustand her Einfügen der Test-Daten Führe m-mal aus Abfrage aller Daten Führe m-mal aus Abfrage auf Gleichheit Führe m-mal aus Kleine und grosse Bereichsabfrage Führe m-mal aus Join-Abfrage Abbildung 5-8: Struktogramm des Ablaufs Das Python-Script benchmark.py nimmt die drei Parameter n, m und d entgegen. Die Parameter haben folgende Bedeutung: n: Bestimmt die gesamte Durchführungsanzahl des Benchmarks m: Bestimmt die Anzahl der einzelnen Interaktionen d: Bestimmt das DBMS für welches der Benchmark ausgeführt wird BMT-1 Insert - Einfügen der Test-Daten Für die Durchführung des Benchmarks wird ein Datenvolumen von ca. 325 ooo Datensätze verwendet. Diese werden zu Beginn des Benchmarks in die jeweilige Datenbank eingefügt. Im Folgenden wird pro DBMS eine verkürzte Variante des Codes, welcher die Daten einfügt, aufgezeigt. Herbst /36

16 Kapitel: 5 Benchmark cur = db.cursor() cur.execute(""" INSERT INTO raindrop (frameid, nextframeid, rainfall, timestamp, x, y) VALUES ('2', '3', ' ', ' ', '431', '133'); INSERT INTO raindrop (frameid, nextframeid, rainfall, timestamp, x, y) VALUES ('2', '3', ' ', ' ', '431', '134'); INSERT INTO raindrop (frameid, nextframeid, rainfall, timestamp, x, y) VALUES ('2', '3', ' ', ' ', '431', '135'); """) cur.close() Abbildung 5-9: Einfügen der Test-Daten in "PostgreSQL" c = db.cursor() raindrop = [ (0, 1, , , 2, 269), (0, 1, , , 3, 270), (0, 1, , , 3, 271) ] c.executemany("insert INTO raindrop(frameid, nextframeid, rainfall, timestamp, x, y) values (?,?,?,?,?,?)", raindrop) c.close() Abbildung 5-10: Einfügen der Test-Daten in "SQLite" db.store(raindrop(0, 1, , , 2, 269)) db.store(raindrop(0, 1, , , 3, 270)) db.store(raindrop(0, 1, , , 3, 271)) db.store(raindrop(0, 1, , , 4, 272)) db.store(raindrop(0, 1, , , 5, 9)) Abbildung 5-11: Einfügen der Test-Daten in "db4o" raindrops = db.raindrop raindrop = [ {"frameid":1, "nextframeid":2, "rainfall": , "timestamp": , "x":201, "y":13}, {"frameid":1, "nextframeid":2, "rainfall": , "timestamp": , "x":241, "y":54} ] raindrops.insert(raindrop) Abbildung 5-12: Einfügen der Test-Daten in "MongoDB" Die Test-Daten für die MongoDB wurden in zwei separate Dateien aufgeteilt. Dies wurde nötig, da ansonsten das Einfügen der Daten durch eine Memory-Exception abgebrochen wurde [MemoryError] BMT-2 SelectAll - Abfrage aller Daten Im Folgenden wird pro DBMS einen Code-Ausschnitt, welcher alle Daten abfragt, aufgezeigt. Herbst /36

17 Kapitel: 5 Benchmark cursor.execute("""select count(*) FROM raindrop""") Abbildung 5-13: Abfragen aller Test-Daten in "PostgreSQL" und SQLite query.constrain(clr.getclrtype(raindrop)) result = query.execute() Abbildung 5-14: Abfragen aller Test-Daten in "db4o" db.raindrop.find().count() Abbildung 5-15: Abfragen aller Test-Daten in "MongoDB" BMT-3 Equal - Abfrage auf Gleichheit Im Folgenden wird pro DBMS einen Code-Ausschnitt, welcher die Daten mit der x-koordinate 200 abfragt, aufgezeigt. cursor.execute("""select count(*) FROM raindrop WHERE x = 200""") Abbildung 5-16: Abfragen der Test-Daten auf x-koordinate 200 in "PostgreSQL" cursor.execute('select count(*) FROM raindrop WHERE x=200') Abbildung 5-17: Abfragen der Test-Daten auf x-koordinate 200 in "SQLite" query.constrain(clr.getclrtype(raindrop)) query.descend("_x").constrain(200) result = query.execute() Abbildung 5-18: Abfragen der Test-Daten auf x-koordinate 200 in "db4o" db.raindrop.find({"x": 200}).count() Abbildung 5-19: Abfragen der Test-Daten auf x-koordinate 200 in "MongoDB" BMT-4 Small-/Large-Range - Kleine und grosse Bereichsabfrage Im Folgenden wird pro DBMS einen Code-Ausschnitt, welcher die Daten mit der x-koordinate 200 abfragt, aufgezeigt. Folgende Code-Ausschnitte zeigen eine Abfrage über einen Bereich der Test-Daten. Dabei werden zwei unterschiedlich grosse Bereiche abgefragt. Bei der kleineren Abfrage wird nur einen Zehntel und bei der grösseren Abfrage die mittlere Hälfte der Daten ausgelesen. Folgende Abbildung zeigt die betroffenen Regionen der beiden Abfragen. Herbst /36

18 Kapitel: 5 Benchmark Abbildung 5-20: Betroffene Regionen cursor.execute("""select count(*) FROM raindrop WHERE timestamp BETWEEN AND """) Abbildung 5-21: Abfragen der Test-Daten auf einen Bereich in "PostgreSQL" cursor.execute('select count(*) FROM raindrop WHERE timestamp BETWEEN AND ') Abbildung 5-22: Abfragen der Test-Daten auf einen Bereich in "SQLite" query.constrain(clr.getclrtype(raindrop)) query.descend("_timestamp").constrain( ).greater().and(query.descend("_timestamp").constrain( ).smaller()) result = query.execute() Abbildung 5-23: Abfragen der Test-Daten auf einen Bereich in "db4o" db.raindrop.find({"timestamp":{'$gt': , '$lt': }}).count() Abbildung 5-24: Abfragen der Test-Daten auf einen Bereich in "MongoDB" BMT-5 Join - Abfrage mit Beziehungen In der Join-Abfrage werden alle Datensätze eines Frames ausgelesen, welches das nachfolgende Frame eines einzelnen Datensatzes ist. Zu beachten ist, dass das objekt- und dokumentorientierte DBMS konzeptbedingt keine Join-Abfrage direkt unterstützen. Deshalb wurden für das DBMS db4o und MongoDB die Join-Abfrage manuell implementiert. cursor.execute("""select count(*) FROM raindrop AS a INNER JOIN raindrop AS b ON b.frameid = a.nextframeid WHERE a.timestamp = """) Abbildung 5-25: Join-Abfragen in "PostgreSQL" cursor.execute('select count(*) FROM raindrop AS a INNER JOIN raindrop AS b ON b.frameid = a.nextframeid WHERE a.timestamp = ') Abbildung 5-26: Join-Abfragen in "SQLite" Herbst /36

19 Kapitel: 5 Benchmark query.constrain(clr.getclrtype(raindrop)) query.descend("_timestamp").constrain( ) result = query.execute() query = db.query() query.constrain(clr.getclrtype(raindrop)) query.descend("_frameid").constrain(result[0].nextframeid) result = query.execute() Abbildung 5-27: Join-Abfragen in "db4o" rd = db.raindrop.find_one({"timestamp": }) db.raindrop.find({"frameid": rd['nextframeid']}).count() Abbildung 5-28: Join-Abfragen "MongoDB" 5.4 Test-Umgebung Für den Benchmark wurde folgendes System verwendet. System Type Model Prozessor RAM Hard Drive 64-Bit Operating System HP Compaq 8710p Intel Core 2 Duo CPU 2.50GHz 4.00 GB Fujitsu MHZ2250BH G2 ATA Device (250GB, 5400 RPM) Operating System Windows Professional 7 Tabelle 5-2: Systemeigenschaften 5.5 Effizienz-Kriterien Im Durchgeführten Benchmark wird als Effizienz-Kriterium einzig die Zeit betrachtet. Weitere Kriterien wie RAM-Auslastung, CPU-Auslastung und Speicherplatz der Datenbank wären denkbar. 5.6 Konfigurationen der DBMS Wie bereits in der Aufgabenstellung erwähnt, werden die jeweiligen DBMS Out-Of-The-Box verwendet. D.h. es werden keine eigenen Änderungen an den Konfigurationen vorgenommen. Somit werden die Standardkonfigurationen der DBMS bei belassen. 5.7 Ergebnisse und Diskussion In diesem Kapitel werden die Ergebnisse der BMTs 1 bis 6 aufgezeigt. Diese sind im Kapitel [5.3 Benchmark-Tests und Benchmark-Ablauf] genauer erläutert. Dabei zeigt jedes Diagramm sechs Durchführungen der jeweiligen Interaktion (z.b. Insert, Join, etc.). Herbst /36

20 Kapitel: 5 Benchmark Auf Grund der Übersicht sind die Achsen der jeweiligen Plots nicht beschrieben. In jedem Plot sind auf der X-Achse die sechs nacheinander durchgeführten Benchmarks. Die Y-Achse zeigt die jeweilige Dauer in Sekunden. Die Farben der Balken in den Diagrammen repräsentieren je ein DBMS. Folgende Legende gilt für die untenstehenden Diagramme. SQLite PostgreSQL db4o MongoDB Abbildung 5-29: Ergebnisse des Benchmarks Herbst /36

21 Kapitel: 5 Benchmark Bestimmte DBMS benötigen für das erstmalige Einfügen der Daten deutlich länger als bei erneuten Einfüge-Aktionen. So dauert das erste Einfügen bei db4o ca. 40 Sekunden. Anschliessende Einfüge-Aktionen benötigen nur noch zwischen 10 und 15 Sekunden. Dies stellt eine ca. dreifache Verbesserung dar. Der SelectAll-Plot weisst ein ähnliches Verhalten wie der Insert-Plot auf. Die MongoDB zeigt ein enorme Verbesserungen bei erneuten Abfrage aller Daten. Wobei der Fokus auf der ersten Abfrage liegt. Diese dauert ca. 40 mal länger als bei anderen Datenbanken! Dafür benötigt sie für die weiteren SelectAll-Abfragen praktisch keine Zeit mehr. In den restlichen vier Plots zeigt sich, dass db4o deutlich langsamer die gestellten Interaktionen verarbeitet. Unserer Meinung nach liegt der Grund dieses Ergebnis in dem zusätzlich eingefügten Layer. Da db4o in erster Linie für Java und.net Entwicklern bereitgestellt wird, musste wie im Kapitel [5.2.1 Datenbanken] beschrieben, eine in.net implementierte Klasse eingebunden werden. Durch die Verwendung einer.net-klasse muss der Overhead der virtuellen Maschine von.net in Kauf genommen werden. Abbildung 5-30:.Net-Basisprinzip [Wiki.Net] Um eine bessere Analyse zu erlauben werden die vier Plots nachfolgend ohne das DBMS db4o erneut dargestellt. Herbst /36

22 Kapitel: 5 Benchmark Abbildung 5-31: Ergebnisse ohne "db4o" Die in der Abbildung [Abbildung 5-30: Ergebnisse ohne "db4o"] dargestellten Plots zeigen die Ergebnisse ohne das DBMS db4o. In diesen Plots kristallisiert sich nun die MongoDB heraus. Sie benötigt für die gestellten Anfragen erheblich länger als die SQL-Datenbanken. Die beiden DBMS PostgreSQL und SQLite weisen in den Plots ähnliche Zeiten auf. Herbst /36

23 Kapitel: 5 Benchmark Zu beachten ist, dass PostgreSQL und SQLite relational DBMS sind im Gegensatz zur objektorientierten db4o und dokument-orientierter MongoDB. Deshalb ist es denkbar, dass gewisse DBMS je nach Art der Datenstruktur Vorteile in bestimmten Anwendungsgebiete besitzen. Durch den durchgeführten Benchmark können folgende Aussagen getroffen werden. Das DMBS db4o weisst im Vergleich zu den anderen drei DBMS die schlechteste Performanz auf. Wie bereits erwähnt, könnte der zusätzlich eingefügte Layer durch die.net CLR für den starken Performanz-Verlust verantwortlich sein. Interessant wäre nun wie sich die DBMS aus Java oder.net verhalten würden. Denkbar wäre, dass db4o dadurch einen Vorteil erhalten würde. Dies darum, weil nun db4o in der für sie vorgesehenen Umgebung eingesetzt werden würde. Beim Vergleich der DBMS ohne db4o zeigt sich, dass die MongoDB bei den meisten Test schlecht abschneidet. Interessant sind jedoch die ähnliche Ergebnisse beim BMT-5 Join. Obwohl die MongoDB nicht für Join-Abfragen ausgerichtet ist, performt sie nicht wesentlich schlechter. Es ist erstaunlich wie gut die noch sehr junge MongoDB mit dem ca. 30 Jährigen PostgreSQL mithalten kann. Nun stellt sich die Frage, ob der neue, dokumentorientierte Ansatz in Zukunft ähnliche oder sogar bessere Leistungen erbringen wird und sich dadurch zum neuen Datenbankstandard durchsetzen kann. Die relationalen Datenbanken SQLite und PostgreSQL weissen in den meisten Plots sehr ähnlich Werte auf. Dies lässt sich vermutlich auf die gemeinsame verwendete Technologie SQL zurückführen. Herbst /36

24 Kapitel: 6 Vergleichbarkeitsbasis & Optimierungspotentiale 6 Vergleichbarkeitsbasis & Optimierungspotentiale Dieses Kapitel zeigt die Möglichkeiten auf, welche fairere Vergleichsbarkeitsbasis erlauben. Des Weitern werden auch Optimierungspotentiale aufgelistet. Zu beachten ist, dass die nachfolgend gezeigten Optimierungen lediglich eine kleine Menge der Möglichkeiten darstellen. 6.1 Isolation-Level Durch die Verwendung der Out-Of-The-Box -Konfiguration der DBMS weisen diese zum Teil unterschiedliche Isolation-Level auf. Folgende Default-Einstellungen gelten für die DBMS. PostgreSQL: Read-Commited [IsoLevelPostgres] SQLite: Serialized [IsoLevelSQLite] Db4o: Read-Commited [IsoLevelDb4o] MongoDB: Kein Isolation-Level und ACID grössten Teils nicht umgesetzt [IsoLevelMongo] Um eine faire Vergleichbarkeitsbasis zu schaffen, müssen die Isolation-Level entsprechend angepasst werden. 6.2 Datentyp-Sicherheit Nicht jedes der vier getesteten DBMS gewährleistet Typsicherheit. So ist SQLite von sich aus nicht typsicher. Der Datentyp wird aus dem zu speicherndem Wert abgeleitet und nicht dessen Container. Ein mögliche Variante um eine faire Vergleichsbasis zu schaffen, liegt in dem manuellen Definieren von Check-Constraints wie im folgendem Beispiel gezeigt ist. [SQLiteType] ALTER TABLE raindrob ADD CONSTRAINT is_timestamp_int CHECK (timestamp BETWEEN and ) Abbildung 6-1: Erstellen von Check-Constraints 6.3 Einsatz von Index Durch das Erstellen von Indexen kann eine bessere Performance bei den DBMS erzielt werden. Die Indexierung wird bei den vier betrachten Datenbanken unterstützt. Der nachfolgende Python-Code zeigt das Erstellen eines Index für die einzelnen DBMS. cursor.execute("create INDEX time_idx ON raindrop(x, timestamp);") Abbildung 6-2: Erstellen eines Indexes für PostgreSQL und SQLite Herbst /36

25 Kapitel: 6 Vergleichbarkeitsbasis & Optimierungspotentiale db.raindrop.ensure_index('timestamp') db.raindrop.ensure_index('x') Abbildung 6-3: Erstellen eines Indexes für MongoDB Db4oFactory.Configure().ObjectClass(clr.GetClrType(Raindrop)).ObjectField("_x").Indexed("true") Db4oFactory.Configure().ObjectClass(clr.GetClrType(Raindrop)).ObjectField("_timestamp").Indexed("true") Abbildung 6-4: Erstellen eines Indexes für db4o Wie die untenstehenden Plots aufzeigen, konnte durch das Verwenden von Index-Strukturen über die Spalten x und timestamp teilweise signifikante Verbesserungen erreicht werden. In jedem Plot sind auf der X-Achse die sechs nacheinander durchgeführten Benchmarks. Die Y- Achse zeigt die jeweilige Dauer in Sekunden. Folgende Legende gilt für die untenstehenden Diagramme. SQLite PostgreSQL db4o MongoDB Abbildung 6-5: Ergebnisse mit Index-Strukturen Herbst /36