Performance-Vergleich von PostgreSQL, SQLite, db4o und MongoDB

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 

www.hsr.ch/mse 

Supervisor: Prof. Stefan Keller 

Autoren: Philippe Morier & Martin Weber 

Rapperswil, Dezember 2011

Kapitel: 1 Abstract 

Inhalt 

1 

2 

3 

Abstract ......................................................................................................................................................... 4 

Aufgabenstellung ......................................................................................................................................... 5 

Stand der Technik ....................................................................................................................................... 6 

3.1 Bestehende Benchmarks .................................................................................................................... 6 

3.2 PostgreSQL .......................................................................................................................................... 6 

3.3 SQLite ...................................................................................................................................................7 

3.4 db4o .......................................................................................................................................................7 

3.5 MongoDB ............................................................................................................................................ 8 

4 

Für den Benchmark verwendete Daten ................................................................................................... 9 

4.1 Beschaffung & Herkunft.................................................................................................................... 9 

4.2 Aufbereitung ....................................................................................................................................... 9 

4.2.1 Extraktion ................................................................................................................................... 9 

5 

Benchmark ...................................................................................................................................................11 

5.1 Definition ............................................................................................................................................11 

5.2 Aufbau ..................................................................................................................................................11 

5.2.1 Datenbanken ............................................................................................................................. 13 

5.2.2 Durchführungsregeln ............................................................................................................... 14 

5.3 Benchmark-Tests und Benchmark-Ablauf .................................................................................... 15 

5.3.1 BMT-1 Insert - Einfügen der Test-Daten .............................................................................. 15 

5.3.2 BMT-2 SelectAll - Abfrage aller Daten ................................................................................. 16 

5.3.3 BMT-3 Equal - Abfrage auf Gleichheit ................................................................................. 17 

5.3.4 BMT-4 Small-/Large-Range - Kleine und grosse Bereichsabfrage ................................... 17 

5.3.5 BMT-5 Join - Abfrage mit Beziehungen ............................................................................... 18 

5.4 Test-Umgebung ................................................................................................................................. 19 

5.5 Effizienz-Kriterien ............................................................................................................................ 19 

5.6 Konfigurationen der DBMS ............................................................................................................ 19 

5.7 Ergebnisse und Diskussion .............................................................................................................. 19 

Herbst 2011 2/36


6 

Vergleichbarkeitsbasis & Optimierungspotentiale .............................................................................. 24 

6.1 Isolation-Level .................................................................................................................................. 24 

6.2 Datentyp-Sicherheit ......................................................................................................................... 24 

6.3 Einsatz von Index ............................................................................................................................. 24 

7 

8 

9 

10 

11 

12 

13 

Schlussfolgerung ........................................................................................................................................ 26 

Eigenständigkeitserklärung ...................................................................................................................... 27 

Glossar .......................................................................................................................................................... 28 

Abbildungsverzeichnis .............................................................................................................................. 29 

Tabellenverzeichnis .................................................................................................................................... 31 

Literaturverzeichnis ................................................................................................................................... 32 

Code der Datei „benchmark.py“ ............................................................................................................. 35 

Herbst 2011 3/36


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 2011 4/36

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 


• 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 2011 5/36

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 

250 - 1600 (abhängig von verwendeten Datentypen) 

Herbst 2011 6/36


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 

2 31 -1 Bytes = ca. 2 GB 

Max. Anzahl Zeilen pro Tabelle 2 64 

Max. Anzahl der Spalten pro Tabelle 32767 

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 2011 7/36


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 2011 8/36

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 

4.2.1 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 2011 9/36

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 2011 10/36

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 2011 11/36



• 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. 325‘000 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 2011 12/36


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. 

5.2.1 Datenbanken 

Die beiden RDBMS „PostgreSQL“ und „SQLite“ enthalten jeweils genau die Tabelle „raindrop“ mit 

folgendem Aufbau. 

frameId nextFrameId rainfall timestamp x y 

1 2 -3026176 1321389385 412 103 

2 3 -16749278 1321448502 431 133 

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 2011 13/36


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":-16746204, 

"timestamp":1321485558, "x":201, "y":13}, 

{"frameId":1, "nextFrameId":2, "rainfall":-16746204, 

"timestamp":1321485559, "x":241, "y":54}, 


"timestamp":1321485560, "x":295, "y":90}, 


"timestamp":1321485561, "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]. 

5.2.2 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 2011 14/36


• 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 


Abfrage auf Gleichheit 


Kleine und grosse Bereichsabfrage 


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 

5.3.1 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 2011 15/36


cur = db.cursor() 

cur.execute(""" 

INSERT INTO raindrop (frameId, nextFrameId, rainfall, timestamp, x, y) 

VALUES ('2', '3', '-16749278', '1321448502', '431', '133'); 


VALUES ('2', '3', '-16742359', '1321448503', '431', '134'); 


VALUES ('2', '3', '-15912437', '1321448504', '431', '135'); 

""") 

cur.close() 

Abbildung 5-9: Einfügen der Test-Daten in "PostgreSQL" 

c = db.cursor() 

raindrop = 

[ 

(0, 1, -855552, 1321285563, 2, 269), 

(0, 1, -16713984, 1321285564, 3, 270), 

(0, 1, -855552, 1321285565, 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, -855552, 1321285563, 2, 269)) 





Abbildung 5-11: Einfügen der Test-Daten in "db4o" 

raindrops = db.raindrop 

raindrop = 

[ 


"timestamp":1321485558, "x":201, "y":13}, 


"timestamp":1321485559, "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]. 

5.3.2 BMT-2 SelectAll - Abfrage aller Daten 

Im Folgenden wird pro DBMS einen Code-Ausschnitt, welcher alle Daten abfragt, aufgezeigt. 

Herbst 2011 16/36


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" 

5.3.3 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.Descend("_x").Constrain(200) 


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" 

5.3.4 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 2011 17/36


Abbildung 5-20: Betroffene Regionen 

cursor.execute("""SELECT count(*) FROM raindrop 

WHERE timestamp BETWEEN 1321448503 AND 1321481090""") 

Abbildung 5-21: Abfragen der Test-Daten auf einen Bereich in "PostgreSQL" 

cursor.execute('SELECT count(*) FROM raindrop 

WHERE timestamp BETWEEN 1321448503 AND 1321481090') 

Abbildung 5-22: Abfragen der Test-Daten auf einen Bereich in "SQLite" 


query.Descend("_timestamp").Constrain(1321448502).Greater() 

.And(query.Descend("_timestamp").Constrain(1321481091).Smaller()) 


Abbildung 5-23: Abfragen der Test-Daten auf einen Bereich in "db4o" 

db.raindrop.find({"timestamp":{'$gt':1321448502, '$lt':1321481091}}).count() 

Abbildung 5-24: Abfragen der Test-Daten auf einen Bereich in "MongoDB" 

5.3.5 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 = 1321448502""") 

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 = 1321448502') 

Abbildung 5-26: Join-Abfragen in "SQLite" 

Herbst 2011 18/36



query.Descend("_timestamp").Constrain(1321448502) 


query = db.Query() 


query.Descend("_frameId").Constrain(result[0].NextFrameId) 


Abbildung 5-27: Join-Abfragen in "db4o" 

rd = db.raindrop.find_one({"timestamp": 1321448502}) 

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 T9300 @ 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 2011 19/36


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 2011 20/36


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 2011 21/36


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 2011 22/36


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 2011 23/36

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 1000000000 and 9999999999) 

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 2011 24/36

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 2011 25/36

Kapitel: 7 Schlussfolgerung 

7 

Schlussfolgerung 

Das Schaffen einer fairen Vergleichbarkeitsbasis stellte sich als anspruchsvoller heraus als erwartet. 

Durch die Verwendung der zum Teil sehr unterschiedlichen DBMS war das Finden eines 

gemeinsamen Nenners sehr schwierig. Darum entschieden wir uns für die Durchführung des 

Benchmarks mit den Default-Einstellungen der jeweiligen DBMS. Erst in einem zweiten Schritt 

wurden bestimmte Ansätze aufgezeigt, wie eine faire Vergleichbarkeitsbasis aufgebaut werden 

könnte (siehe Kapitel [6 Vergleichbarkeitsbasis & Optimierungspotentiale]). 

Bei der Wahl eines DBMS ist nebst der Performance auch das darunterliegende Konzept eines 

DBMS zu beachten. Je nach Daten bzw. Verwendungszwecken eignet sich ein anderes Konzept 

besser. D.h. nebst dem stark verbreiteten Konzept der relationalen DBMS soll auch die neue Art der 

nicht-relationalen bzw. NoSQL-DBMS in die Evaluation miteinbezogen werden. Jedoch erfordert 

der Entscheid für ein NoSQL-DBMS eine andere Denkweise. 

Durch das Datenbankseminar konnte Einblick in verschiedene DBMS gewonnen werden. Zusätzlich 

konnten Erfahrungen in der Skriptsprach „Python“ gesammelt werden. 

Herbst 2011 26/36

Kapitel: 8 Eigenständigkeitserklärung 

8 

Eigenständigkeitserklärung 

Wir, Philippe Morier und Martin Weber erklären hiermit, 

- dass wir die vorliegende Arbeit selber und ohne fremde Hilfe durchgeführt haben, ausser 

derjenigen, welche explizit in der Aufgabenstellung erwähnt ist oder mit dem Betreuer schriftlich 

vereinbart wurde, 

- dass wir sämtliche verwendeten Quellen erwähnt und gemäss gängigen wissenschaftlichen 

Zitierregeln korrekt angegeben haben. 

Rapperswil, 23. Dezember 2011 

Philippe Morier 

Martin Weber 

Herbst 2011 27/36

Kapitel: 9 Glossar 

9 

Glossar 

ACID 

ANSI 

BMT 

BSON 

CLR 

CPU 

DBMS 

EDV 

GIF 

GiST 

JSON 

NoSQL 

NZZ 

ORDBMS 

RAM 

RDBMS 

SQL 

Atomicity, Consistency, Isolation und Durability 

American National Standards Institute 

Benchmark Test 

Binary JSON 

Common Language Runtime 

Central Processing Unit 

Datenbankmanagementsystem 

Elektronische Datenverarbeitung 

Graphics Interchange Format 

Generalized Search Tree 

JavaScript Object Notation 

Not only SQL 

Neue Zürcher Zeitung 

Objektrelationales DBMS 

Random-Access-Memory 

Relationales DBMS 

Structured Query Language 

Herbst 2011 28/36

Kapitel: 10 Abbildungsverzeichnis 

10 Abbildungsverzeichnis 

Abbildung 4-1: Niederschlagsradar von NZZ Online .................................................................................. 9 

Abbildung 4-2: Extraktion der Niederschlag-Pixel ....................................................................................... 9 

Abbildung 4-3: Einzelner Niederschlags-Pixel .............................................................................................. 10 

Abbildung 5-1: Aufbau des Benchmarks ..........................................................................................................11 

Abbildung 5-2: Inhalt der Datei „_start_db4o.bat“...................................................................................... 12 

Abbildung 5-3: Ausführung des Benchmarks mit entsprechenden Parameter ......................................... 13 

Abbildung 5-4: Struktur der Tabelle "raindrop"............................................................................................ 13 

Abbildung 5-5: Fehler beim Abspeichern [IrPyObj]..................................................................................... 13 

Abbildung 5-6: Klasse "raindrop"..................................................................................................................... 14 

Abbildung 5-7: "raindrop"-Dokument............................................................................................................. 14 

Abbildung 5-8: Struktogramm des Ablaufs .................................................................................................... 15 

Abbildung 5-9: Einfügen der Test-Daten in "PostgreSQL".......................................................................... 16 

Abbildung 5-10: Einfügen der Test-Daten in "SQLite" ................................................................................. 16 

Abbildung 5-11: Einfügen der Test-Daten in "db4o" ..................................................................................... 16 

Abbildung 5-12: Einfügen der Test-Daten in "MongoDB" ........................................................................... 16 

Abbildung 5-13: Abfragen aller Test-Daten in "PostgreSQL" und „SQLite“............................................. 17 

Abbildung 5-14: Abfragen aller Test-Daten in "db4o".................................................................................. 17 

Abbildung 5-15: Abfragen aller Test-Daten in "MongoDB"......................................................................... 17 

Abbildung 5-16: Abfragen der Test-Daten auf x-Koordinate 200 in "PostgreSQL"................................. 17 

Abbildung 5-17: Abfragen der Test-Daten auf x-Koordinate 200 in "SQLite".......................................... 17 

Abbildung 5-18: Abfragen der Test-Daten auf x-Koordinate 200 in "db4o" ............................................. 17 

Abbildung 5-19: Abfragen der Test-Daten auf x-Koordinate 200 in "MongoDB" ................................... 17 

Abbildung 5-20: Betroffene Regionen ............................................................................................................. 18 

Abbildung 5-21: Abfragen der Test-Daten auf einen Bereich in "PostgreSQL"......................................... 18 

Abbildung 5-22: Abfragen der Test-Daten auf einen Bereich in "SQLite" ................................................. 18 

Abbildung 5-23: Abfragen der Test-Daten auf einen Bereich in "db4o"..................................................... 18 

Abbildung 5-24: Abfragen der Test-Daten auf einen Bereich in "MongoDB" .......................................... 18 

Abbildung 5-25: Join-Abfragen in "PostgreSQL" ........................................................................................... 18 

Abbildung 5-26: Join-Abfragen in "SQLite" ................................................................................................... 18 

Abbildung 5-27: Join-Abfragen in "db4o" ....................................................................................................... 19 

Abbildung 5-28: Join-Abfragen "MongoDB" .................................................................................................. 19 

Abbildung 5-29: Ergebnisse des Benchmarks ................................................................................................ 20 

Abbildung 5-30: .Net-Basisprinzip [Wiki.Net].............................................................................................. 21 

Abbildung 5-31: Ergebnisse ohne "db4o" ......................................................................................................... 22 

Herbst 2011 29/36

Kapitel: 10 Abbildungsverzeichnis 

Abbildung 6-1: Erstellen von Check-Constraints ......................................................................................... 24 

Abbildung 6-2: Erstellen eines Indexes für PostgreSQL und SQLite ........................................................ 24 

Abbildung 6-3: Erstellen eines Indexes für MongoDB ................................................................................. 25 

Abbildung 6-4: Erstellen eines Indexes für db4o .......................................................................................... 25 

Abbildung 6-5: Ergebnisse mit Index-Strukturen ......................................................................................... 25 

Herbst 2011 30/36

Kapitel: 11 Tabellenverzeichnis 

11 

Tabellenverzeichnis 

Tabelle 3-1: Limits von PostgreSQL [Postgres] ................................................................................................7 

Tabelle 3-2: Limits von SQLite [SQLimits] ......................................................................................................7 

Tabelle 3-3: Philosophie von MongoDB .......................................................................................................... 8 

Tabelle 5-1: Aufbau der Tabelle "raindrop" mit Beispiel Datensätze .......................................................... 13 

Tabelle 5-2: Systemeigenschaften ..................................................................................................................... 19 

Herbst 2011 31/36

Kapitel: 12 Literaturverzeichnis 

12 

Literaturverzeichnis 

[Cattell] 

The Engineering Database Benchmark, 

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.89.1518&rep=rep1&typ 

e=pdf, 

aufgerufen am 19.12.2011 

[db4o] 

db4o :: Java & .NET Object Database :: Product Information, 

http://www.db4o.com/about/productinformation/, 

http://www.db4o.com/about/productinformation/datasheet/, 


[FAME] 

Fame Database Performance Benchmark for Time Series Data, 

http://www.scribd.com/doc/53366489/Fame-WhitePaper-FameBenchmarking, 


[IrPyObj] 

How to store objects created in IronPython to object databases - Stack 

[IsoLevelDb4o] 

Isolation Level For Db4o, 

Overflow, 

http://stackoverflow.com/questions/2352718/how-to-store-objects-created-inironpython-to-object-databases, 


http://dz.prosyst.com/user-manuals/mBS_Extensions_6.1.5/database/db4o-6.3- 

doc/reference/html/reference/basic_concepts/acid_model/isolation_level_for_ 

db4o.html, 


[IsoLevelMongo] 

database - Why doesn't MongoDB use fsync()? - Stack Overflow, 

http://stackoverflow.com/questions/3736533/why-doesnt-mongodb-use-fsync, 

two-phase commit – MongoDB, 

http://www.mongodb.org/display/DOCS/two-phase+commit, 


[IsoLevelPostgres] 

PostgreSQL: Documentation: Manuals: Transaction Isolation, 

http://www.postgresql.org/docs/8.1/static/transaction-iso.html, 


[IsoLevelSQLite] 

SQLite Shared-Cache Mode, 

http://www.sqlite.org/sharedcache.html, 


[MemoryError] 

6. Built-in Exceptions - Python v2.7.2 documentation, 

Herbst 2011 32/36


http://docs.python.org/library/exceptions.html#exceptions.MemoryError, 


[MongoDB] 

Philosophy – MongoDB, 

http://www.mongodb.org/display/DOCS/Philosophy, 

http://blog.mongodb.org/post/137788967/32-bit-limitations, 


[MOtt] Key/Value Pair Versus hstore - Benchmarking Entity-Attribute-Value 

Structures in PostgreSQL, 

http://wiki.hsr.ch/Datenbanken/files/Benchmark_of_KVP_vs._hstore_- 

_doc.pdf, 

http://wiki.hsr.ch/Datenbanken/files/db-benchmark_mott.zip, 


[Niall] MongoDB and Python, Niall O’Higgins, O’Reilly, 2011, 

ISBN: 978-1-449-31037-0 

[NZZ] 

Animierte Bildserie (Wetter, NZZ Online), 

http://www.nzz.ch/nachrichten/wetter/radarbild_animierte_serie_1.134.html, 


[OxfordJournals] 

A Practitioner's Introduction to Database Performance Benchmarks and 

Measurements, 

http://comjnl.oxfordjournals.org/content/35/4/322.full.pdf, 


[PolePosition] 

PolePosition Open Source Database Benchmark, 

http://www.polepos.org/, 


[Postgres] 

PostgreSQL: About, 

http://www.postgresql.org/about/, 


[PostgresDE] 

PostgreSQL im Schnelldurchgang, 

http://www.postgres.de/postgresql_outline.html, 


[PyMongo] 

PyMongo 2.0.1 Documentation - PyMongo v2.0.1 documentation, 

http://api.mongodb.org/python/current/, 


[SQLimits] 

Implementation Limits For SQLite, 

http://www.sqlite.org/limits.html, 


Herbst 2011 33/36


[SQLite] 

About SQLite, 

http://www.sqlite.org/about.html, 


[SQLiteType] 

Typsicherheit von SQLite, 

http://www.sqlite.org/datatype3.html, 

http://commitsuicide.wordpress.com/2008/09/11/sqlite-ein-ziemlich-nettesembedded-dms/, 


[TexasBench] 

HSR Texas Geo Database Benchmark – GISpunkt HSR, 

http://www.gis.hsr.ch/wiki/HSR_Texas_Geo_Database_Benchmark 


[TPC] 

TPC - Benchmarks, 

http://www.tpc.org/information/benchmarks.asp, 


[Wiki.Net] 

Datei:Net Basisprinzip ext.svg – Wikipedia, 

http://de.wikipedia.org/w/index.php?title=Datei:Net_Basisprinzip_ext.svg&file 

timestamp=20080115070326, 


[WikiSQLite] 

SQLite – Wikipedia, 

http://de.wikipedia.org/wiki/Sqlite, 


Herbst 2011 34/36

Kapitel: 13 Code der Datei „benchmark.py“ 

13 

Code der Datei „benchmark.py“ 

Herbst 2011 35/36

Kapitel: 13 Code der Datei „benchmark.py“ 

Herbst 2011 36/36

Performance-Vergleich von PostgreSQL, SQLite, db4o und MongoDB

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?