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:
- Anweisungen in README-Datei folgen.
Installation von rdf3x:
- 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 dagegen Eneteties mussten umgewandelt werden. Dafür wurde ein kleiner Research gemacht, dessen Ergebnisse hier zusammengefasst wurden. Schlussendlich wurde entschieden aus den Enteties UriRefs zu machen. Dafür wurden die Enteties in die eckigen Klammer gesetzt und die unzulässige Zeichen durch die entsprechende Prozent-Kodierungen ersetzt. Die Ersetzungsregeln entsprechen denen von DBpedia 3.7. Als nächstes musste der konvertierter Datensatz in die beiden RDF-Stores geladen werden.
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%20Jackson' --> '<http://foo/Mikel%20Jackson>'
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%20Jackson' --> '<Mikel%20Jackson>'
Ladezeiten:
RDF-Store |
Ladezeit |
|
Virtuoso |
1170 min |
|
Rdf3x |
noch nicht gemessen, aber deutlich weniger als bei Virtuoso |
|
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
|
rdf3x |
virtuoso |
||
Query 1 |
6 (6/5/6) ms 6 Lines |
22 (46/10/10) ms 6 Lines |
||
Query 2 |
73088 (70397/73129/75740) ms 8923358 Lines |
119289 (117564/119475/120828) ms 8282272 Lines |
||
Query 3 |
16 (18/14/18) ms 4 Lines |
35 (49/48/10) ms 4 Lines |
||
Query 4 |
11 (13/10/10) ms 1000 Lines |
438 (690/341/285) ms 1000 Lines |
||
Query 5 |
163316 (163316/-/-) ms 39690913 Lines |
1276218 (1276218/-/-) ms 39919489 Lines |
||
Query 6 |
168517 (168517/-/-) ms 1 Lines |
1469 (1521/1456/1430) ms 1 Lines |
||
Query 7 |
too Long |
1487 (1565/1420/1477) ms 1 |
||
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.