Triple Stores

We tested the performance of two triple stores: Virtuoso and RDF-3X. We compare them to our own triple score on a couple of benchmarks.

Software Installation

Installation von Virtuoso Open-Source Edition:

1. Runterladen

2. Anweisungen in README-Datei folgen.

Installation von rdf3x:

1. Runterladen

2. Kompilieren

Data Import

Um den Datensatz in die beide Stores laden zu können, musste dieser Satz in einen für RDF-Speicherung gängigen Format umgewandelt werden. Ausgewählt wurde "*.nt"-Format. Der ursprünglicher Satz enthielt Values und Enteties. Values waren schon nt-conform, die Enteties mussten umgewandelt werden. Dafür wurden die Enteties in die eckigen Klammer gesetzt und die unzulässige Zeichen durch die entsprechende Prozent-Kodierungen oder auch von uns defenierten Ersatzzeichen ersetzt.

Ersetzungstabelle:

Z.B.: Mikel Jackson --> <Mikel_Jackson>

Data Import Virtuoso:

Datenladen in den Virtuoso wurde mit Bulk loading process gemacht. Bei diesem Prozess muss der Name des RDF-Graphen als graph_iri eingegeben werden. Unter dieser Namen ist der RDF-Satz bei Virtuoso erreichbar und man benutzt graph_iri als prefix bei jeder Entety, wenn man eine Spqrql-Anfrage an den Store erstellt.

Z.B.: Mikel Jackson --> '<http://foo/Mikel_Jackson>'

Data Import Rdf3x:

Das Datenladen in den Rdf3x-Store erfolgt durch einen Skript <Installationsordner von Rdf3x>/bin/rdf3xload <DB-Name> <RDF-Satz-Pfad>. Das wars! Bei der Nfragestellung muss man keinen zusätzlichen Prefix eingeben.

Z.B.: Mikel Jackson --> '<Mikel_Jackson>'

Ladezeiten:

Queries

Testvorgang

Als test-Framework wurde ein Python-Skript verwendet. Dabei wurde folgendes Abschnitt immer 3-Fach für jede Kombination Query<>RDF-Store ausgeführt.

start = int(round(time.time()*1000))

process = subprocess.Popen(command, stdout=subprocess.PIPE, shell=True)

out, err = process.communicate()

end = int(round(time.time()*1000))

wo

command = virtuosoISQL_path + "isql 127.0.0.1:1113 dba dba " + queryFile für Virtuoso

command = rdf3x_path + "rdf3xquery" + dataBase + " " + queryFile für rdf3x

Anfragen

Für jede Anfrage wurden zwei Datein erstellt die diese Anfrage enthalten: Eine für rdf3x und eine für Virtuoso.

Beispiel Anfrage für rdf3x:

SELECT * WHERE {

<The%20Format%20(Musical%20Recording)%20%231> ?b ?c

}

Beispiel Anfrage für Virtuoso:

SPARQL SELECT * WHERE {

<http://foo.org/The%20Format%20(Musical%20Recording)%20%231> ?b ?c

};

Getestete Anfragen:

Query 1

SELECT * WHERE {

<The%20Format%20(Musical%20Recording)%20%231> ?b ?c

}

Query 2

SELECT * WHERE {

?a <Length> ?c . FILTER (?c>100)

}

Query 3

SELECT * WHERE {

?x <Release> <Technodrome,%20Volume%202%20(Consumer%20product)> .

?x <is-a> <Canonical%20Version> .

?x <is-a> <Musical%20Recording> .

} LIMIT 1000

Query 4

SELECT * WHERE {

?a <is-a> ?c .

?c <is-a> ?e .

} LIMIT 1000

Query 5

SELECT * WHERE {

?a <is-a> ?c .

?c <is-a> ?e .

}

Query 6

SELECT COUNT(*) WHERE {

?a <is-a> ?c .

?c <is-a> ?e .

}

Query 7

SELECT COUNT(*) WHERE {

?a ?b ?c .

}

Ergebnisse

Zeilenformat: <average time> (<1. loop time>/<2. loop time>/<3. loop time>) ms <number of lines in result> Lines

Evaluation

Bei den meisten Testfällen ist rdf3x dem virtuoso überlegen. Jedoch scheint Virtuoso die Aggregierung-Anfragen effizienter zu bearbeiten, wie man das am Beispiel der Queries 6,7 sieht. An den Anfragen 5,6 kann man vermuten, dass rdf3x erstmal die Anfrage 5 ausführt. Danach zählt er die Ergebniszeilen, um die Anfrage 6 zu berechnen. Virtuoso geht offensichtlich anders vor.

Desweiteren kann man an der Anfrage 5 erkennen, dass die Ergebnislisten ungleich sind. Grund dafür sind wahrscheinlich die Lesefehler beim RDF-Satz-Laden Leider konnte die Anfrage 7 nur bei Virtuoso ausgeführt werden. Egebnis ist 243035237. Der ursprüngliche Datensatz enthält aber 243036034 Tripel. Es fehlen also 797 Tripel.

Weitere Beobachtung ist, dass die Anzahl der Ergebnisse mal bei Virtuoso und mal bei rdf3x größer ist. Sieh Query 2 und 5. Nach dem weiteren Betrachten hat sich ergeben, dass die Values bei rdf3x nicht erkannt wurden, bzw. als einfache Textliterale erkannt. Das führt zu Ergebnisunterschieden bei der Anfrage 2.