Performance-Vergleich von PostgreSQL, SQLite, db4o und MongoDB

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.
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