Der Verbreitungsgrad von Linked Open Data hat in den letzten Jahren massiv zugenommen. Stetig erscheinen neue Quellen, die RDF-Daten frei zur Verfugung stellen. Aktuell diskutiert die Bundesregierung uber ein neues Gesetz, welches zur O enlegung von Daten der o entlichen Hand verp ichtet. Durch diese Ma nahme, steigt u. a. die Menge an Linked Open Data sehr schnell an. Es werden neue Verfahren benotigt, die mit sehr vielen RDF-Daten gleichzeitig eine e ziente, skalierbare und mit Garantien versehene Abfrage von Daten mittels SPARQL gewahrleistet. In dieser Arbeit wird ein reines In-Memory Shared-Nothing-System vorgestellt, das die genannten Anforderungen in e zienter Weise erfullt. Hierfur werden verschiedenste Optimierungsma nahmen ergri en, die das Potenzial moderner Hardware umfassend ausnutzen.
Punkt 1 besitzt mehrere potenzielle Vorteile. Durch die Verteilung wird ein Single Point of Failure (SPOF) vermieden. Der Koordinator muss keine Daten speichern, da sie alle in den Quellen vorliegen. Er muss nur einen geringen Speicherplatz und nur eine geringe Rechenkapazitat zur Verfugung stellen. Ein wichtiger Punkt, der fur eine Verteilung der Quellen spricht, ist, dass die Daten nicht an andere Unternehmen herausgegeben werden mussen. Es konnen 'Firmengeheimnisse' bewahrt werden. Als Nachteile ergeben sich jedoch einige Punkte. Die Zerlegung von Anfragen in Subqueries und alle daraus folgenden Schritte sind ein hoch komplexes Problem (Parsing, Normalisierung, eingebettete Anfragen 'herausdrucken', Vereinfachung, Datenlokalisation, Optimierung). Zwei weiter nicht zu unterschatzende Nachteile sind die fehlenden Kontroll- und U berwachungsmechanismen der Quellen. Die Antwortzeit in einem solchen Szenario ist nach oben unbeschrankt. Es ergibt sich, dass keinerlei Garantien abgegeben werden konnen. Weiterhin ist durch die Verteilung das verwendete Schema dem Koordinator ganzlich unbekannt. Viele Quellen sind zudem nicht in der Lage, SPARQL-Anfragen zu verarbeiten. Sie liefern nur die Quellen uber einen Webserver aus. Waren SPARQL-Anfragen moglich, waren Analyseanfragen a la Data Warehouse-Anfragen auch nur bedingt moglich.
Die zentralen Nachteile des Punktes 2 sind die (i.) benotigte Zeit zum Einsammeln aller Daten, die (ii.) Durchfuhrung einer Vorberechnung und das Problem, dass niemals gewahrleistet werden kann, dass (iii.) alle Daten aktuell sind. Zudem wird (iv.) ein SPOF, sowie ein (v.) extrem hoher Speicherplatz an einer einzigen zentralen Instanz in Kauf genommen. Ein weiterer Nachteil beider Falle ist das (vi.) unbekannte Schema und die (vii.) geringe Datenqualitat. Im zentralisierten Fall kann jedoch auf die letzten beiden Probleme e zient reagiert werden, indem entsprechende Indizes angelegt und/oder verschiedenste Optimierungen durchgefuhrt werden. Eine entsprechende Datenvorverarbeitung kann zudem davor gestartet werden, um die Datenqualitat zu verbessern. Beides wird durch die einheitliche Form der Daten als reine Tripel unterstutzt. Der gro e Vorteil, der sich aus dem zentralisierten Ansatz ergibt, ist die Moglichkeit, Anfragezeiten zu einem bestimmten Prozentsatz zu gewahrleisten, da sich das gesamte System unter der Kontrolle einer Instanz be ndet. Weiterhin kann ein Scale-Out (Erhohung der Speicherkapazitat (v.), Verbesserung der Antwortzeiten) und eine Replikation (Beseitigung SPOF (iv.), Verbesserung der Antwortzeiten) angestrebt werden. Zur Verringerung der Speicherkapazitat (v.) konnen e ziente Kompressionstechniken verwendet werden, die zugleich lese- und schreiboptimiert sind, was zu einer weiteren Verringerung des benotigten Speicherplatzes fuhrt. Durch die Verwendung von push und Bulk Load-Techniken zur Datenintegration anstelle von reinen pull-Techniken kann garantiert werden, dass die abgefragten Daten aktuell (iii.) sind. Das Einsammeln von Daten ist nur zu Beginn einmal notig, wenn eine neue Datenquelle erschlossen wird (i. und ii.).
Der Mechanismus des Scale-Outs und der Replikation bedingen jedoch, dass eine Zerlegung der Anfrage durchgefuhrt werden muss. Wobei dieser eine Nachteil durch die oben genannten Vorteile aufgewogen wird. Insgesamt sprechen viele Faktoren fur die Verwendung eines zentralisierten Ansatzes.
Garantien bezuglich den soeben erwahnten Antwortzeiten sind au erst komplex in ihrer Umsetzung und benotigen im extremen Fall viele vorallokierte Kapazitaten, die wahrend normaler Nutzung brachliegen und hohe Kosten verursachen. Stattdessen werden sie nur wahrend Lastspitzen benotigt. Folglich werden aus diesem Grund hau g prozentuale Werte angegeben. Es sollen beispielswei e 99,99 % aller Anfragen in der maximal erlaubten Zeitspanne beantwortet werden. Erst ein solches Vorgehen erlaubt es, dass wahrend einer Lastspitze neue Kapazitaten hinzugenommen werden konnen (automatisierter Scale-Out). Das Ziel hierbei ist, zukunftige Anfragen wieder innerhalb der gesetzten Antwortzeit beantworten zu konnen. Am Ende der Lastspitze werden die zusatzlich allokierten Ressourcen wieder freigegeben. Letztendlich werden hierdurch Kosten fur den Betreiber des Services eingespart. Wichtig zu erwahnen ist, dass die Garantie bezuglich der Antwortzeit nicht fur jede beliebige SPARQL-Anfrage garantiert werden kann. Stattdessen soll dies nur fur "gewohnliche\ Anfragen gelten.
Das Ziel dieses Projektes ist es, ein hochverfugbares, skalierbares und -e zientes System aufzubauen, welches mehrere hundert Milliarden bzw. mehrere Billionen Tripel von RDF-Daten in einer materialisierten Form vorhalt. Es soll hierbei als Framework und nicht als reine Datenablage angesehen werden. Neben SPARQL-Anfragen soll es den Benutzer im gesamten Work ow unterstutzen. Unter Workow werden die Folgenden Operationen verstanden: Einfugen/Loschen/A ndern von Tripeln sowie die Abfrage/Analyse von Daten. Unter dem Stichpunkt Analyse fallen samtliche Data-Mining-Aufgaben, die in einem Data-WarehouseSzenario moglich sind. Ein weiteres Ziel ist die Unterstutzung von SLAs. Neben dem Garantieren von maximalen Antwortzeiten sollen auch Garantien bezuglich der Verfugbarkeit und der Aktualitat von Daten, sowie einige andere mehr beachtete werden. Letztendlich soll das System als ein Cloud-Service fur LOD-Daten propagiert werden. Das Ziel hierbei ist, Kosten fur den Endbenutzer einzusparen. Er mochte nur fur den von ihm selbst verursachten Aufwand bezahlen (Service on Demand). Im alternativen Fall musste eine eigene Infrastruktur aufgebaut werden, was hau g zu viel hoheren Kosten fuhrt.
Diese Arbeit beschaftigt sich mit einem Teil aus dem soeben beschriebenen Zieles. Es soll ein erster Ansatz fur einen Datenspeicher fur Linked Open Data aufgezeigt werden, der mit sehr gro en Datenmengen eine e ziente Anfrageverarbeitung ermoglicht. Hierfur ist ein zuverlassiges Scale-OutVerfahren notwendig, welches vorgestellt wird. Des Weiteren soll das gewahlte Verfahren auf eine wechselnde Anfragelast reagieren konnen.
Fur die Verarbeitung von LOD existieren bereits viele
verschiedene Systeme, die RDF-Daten entgegennehmen und
SPARQL-Queries ausfuhren. Einige bekanntere System sind
Virtuoso [
Werden alle vorgestellten Systeme genauer betrachtet, stellt man fest, dass diese einige Nachteile besitzen. Entweder sind diese auf bestimmte Operationen (lesen, andern) und/oder Domanen getrimmt und/oder sind nicht skalierbar im Sinne eines Scale-Outs und somit ungeeignet fur sehr gro e Datenmengen. Stattdessen setzten sie auf die Leistung einer einzigen Maschine, was zu einem erheblichen Performance, Speicherplatz- und Verfugbarkeitsproblem werden kann. Weiterhin unterstutzt keines der erwahnten Systeme Garantien bezuglich Antwortzeiten. Sie setzen zudem auf einen Permanentspeicher, welcher I/O-Zugri e erfordert. Dies er... Datenquellen Push
InnereA ufbau hoht wiederum sehr schnell die Antwortzeit. Eine Gewahrung von Garantien wird erschwert. Einige dieser Ansatze sind zudem bereits mit wenigen Milliarden Tripeln uberfordert (Jena). Andere verwenden alte Konzepte fur neuere Probleme (Virtuoso), was nicht immer zu einer optimalen Losung beitragt.
Bezuglich den Garantien von Antwortzeiten, beschreiben
die Autoren in [
Die Architektur des Gesamtsystems ist in Abbildung 1 aufgezeigt. Sie folgt dem typischen Scale-Out-Paradigma mit verschiedenen Shared-Nothing-Systemen (Kreise in der Mitte), die alle gleichberechtigt sind. Anfragen konnen von beliebigen Knoten entgegengenommen werden. Im nachsten Schritt wird ein Queryrewriting durchgefuhrt und an die entsprechenden Knoten weitergegeben. Die Empfanger nehmen die umgeschriebenen Anfragen entgegen, bearbeiten diese und senden letztendlich das Ergebnis zuruck. Nachdem alle Einzelergebnisse eingetro en sind werden diese mittels verschiedener Join-Operationen zu einem Ergebnis verknupft. Dieses wird letztlich an den ursprunglich anfragenden Client als Ergebnis zuruck gesandt. Auf der rechten Seite der Gra k ist ersichtlich, dass neue Daten mittels push- oder pull-Techniken eingespielt werden konnen und dies wahrend der Laufzeit, mit Einhaltung der Antwortzeitgarantien. 3.1
Die lokale Verarbeitungseinheit liegt auf einem Knoten und besteht aus einem Java-Programm, sowie vorwiegend aus einer C++ In-Memory-Datenhaltung und Datenabfragemoglichkeit, die LODCache genannt wird. Dies ist eine hochperformante, reine In-Memory Losung fur LOD, die den L2-, wenn vorhanden L3-Cache und die RAM-Struktur moderner Hardware e zient ausnutzt. Allokierte Datenfelder, sogenannte Chunks, entsprechen genau der Gro e des L2Caches. Dies ermoglicht es sehr e zient auf Daten zuzugreifen, diese zu Bearbeiten und Berechnungen auf diesen durchzufuhren. Des Weiteren konnen Anfragen an den LODCache gestellt, sowie A nderungen und Einfugeoperationen durchgefuhrt werden. Die Verwendung einer reinen In-Memory Losung basiert auf der Grundlage, zukunftig Antwortzeiten garantieren zu konnen.
Linked Open Data bestehen ausschlie lich aus Tripeln, die wiederum aus Strings bestehen. Werden die darin abgespeicherten Werte genauer untersucht, stellt man fest, dass dieselben Stringwerte mehrmals auftreten. Hier ist eine Kompression nutzlich, um Speicherplatz einzusparen. Dies fallt umso mehr ins Gewicht, da der Data-Warehouse Ansatz angestrebt wird. Die naheliegenste Technik, ist der Einsatz eines rein lokalen Worterbuches. In einem solchen wird jeder Stringwert auf eine eindeutige ID gemappt. Hierfur ist wiederum eine e ziente Anfrageverarbeitung von Noten, die im folgenden Abschnitt beschrieben wird.
Ein Chunk besteht intern aus einer Kombination von
Rowund Column-Store [
Moderne CPUs besitzen interne SIMD3-Register die eine Breite von 256-Bit besitzen. Diese wurde mit dem neuen AVX4-Befehlsatz von Intel eingefuhrt. In einem solchen Register werden mehrere logisch getrennte Einheiten zu einer physischen Einheit verbunden, die in einer Instruktion gleichzeitig bearbeitet werden konnen. Hierfur mussen die einzulesenden Daten auf eine volle 2-er Potenz erganzt und die Wortgrenze bekannt sein.
Werden die Fakten vereint, muss zuerst das 96 Bit Wort auf 128 Bit, erganzt werden. Mit Hilfe der verfugbaren 256Bit konnen nun zwei logische Datenzeilen mit jeweils 128Bit gleichzeitig uberpruft werden. Theoretisch ergibt sich eine bis zu sechsfache Performancesteigerung. Mittels der Vermeidung von Sprung- und sonstigen Befehlen, die Leerlauf produzieren, ist dieses Verfahren sehr Cache freundlich. Einmal verwendete Daten konnen stur linear abgearbeitet werden. Zugri e auf dem langsamen RAM werden damit vermieden. Insgesamt wird die Struktur moderner Hardware sehr gut ausgenutzt und eine Performancesteigerung ergibt sich.
Wie oben erwahnt, muss in diesem Fall eine Erganzung
von 96-Bit auf 128-Bit durchgefuhrt werden. Es verbleiben
32 ungenutzte Bit. Diese konnen fur eine weitere Spalte
verwendet werden. In dieser kann die Sprache bzw. der
Datentyp des (Literal)Objektes vermerkt werden [
Durch die Verwendung von Integerwerten, die eine feste Bitbreite besitzen, wird auf einen expliziten und unvorher
4Advanced Vector Extensions sehbar langen Stringvergleich verzichtet. Dies erhoht weiter die Performance und verbessert die Antwortzeit.
Wie zu erkennen ist, wird auf eine Erzeugung von zusatzlichen Indixes verzichtet. Dies ergibt sich aus der Speicherrestriktion und dem notigen Wartungsaufwand, der wahrend jeder A nderung anfallt. Hierdurch konnen Operationen unvorhersehbar lange blockiert werden. Es sind keine Garantien mehr moglich. Anstelle werden wie in einem gewohnlichen Column-Store alle Elemente stetig gepruft. Dies ist durch moderne Hardware und der standig steigenden Parallelisierung problemlos moglich. Sind c Cores gegeben, muss jeder Core nur maximal d ccC e Elemente uberprufen, wobei cC die Anzahl der Chunks angibt.
Der LODCache besitzt keinerlei Logik fur die Optimierung von Anfragen. Aus diesem Grund ist eine vorgelagerte Java-Applikation vorhanden. Diese nimmt SPARQL-Anfragen entgegen, zerlegt diese, optimiert sie (lokale Optimierung) und uberfuhrt sie in die Sprache des LODCaches. Dieser fuhrt die entsprechende Operation durch und ubergibt das Ergebnis dem Java-Programm mittels JNI5, dass die ermittelten Daten an den Aufrufer sendet.
Wird eine exakt Match Anfrage mit Subjekt1, Objekt1 und einem freien Pradikat ?p an den LODCache gesandt, werden zuerst die Integerwerte der fest de nierten Strings gesucht und in ein Wort mittels Shift und logischen OROperationen zu einer Maske (m) erganzt. Dies wird mittels vier CPU-Operationen durchgefuhrt werden (COPY, SHIFT, OR, SHIFT). Die Operationen zum Filtern der Daten aus einem Chunk beschranken sich daraufhin nur noch auf ein logisches AND und einen Vergleich (CMP), je Eintrag und Chunk. Die genaue Berechnung ist im Folgenden nochmals dargestellt. Wobei e das zu uberprufende Element ist, m die Maske und r das Ergebnis als boolescher Wert. r = (e AND m) CMP m
Werden Bereichsanfragen betrachtet, muss das Mapping
der Strings auf Integerwerte eindeutig und
ordnungserhaltend sein, da sonst immer das Worterbuch zu Rate
gezogen werden musste. Dies bedeutet, jeder Integerwert muss
mit der lexikogra schen Ordnung seines gegenuberliegenden
Strings ubereinstimmen. Nur so konnen die in [
Ein Problem tritt jedoch beim Einfugen von neuen Stringwerten auf. Diese werden meist lexikogra sch zwischen zwei bereits bestehenden Elementen eingeordnet. Somit mussten sich in einem naiven Ansatz alle IDs aller nachfolgenden Stringwerte andern. Das Worterbuch und alle bestehenden Chunks mussen daraufhin uberpruft und ggf. abgeandert werden.
Dies ist ein sehr gro es und au erst schwerwiegendes Problem, welches sich nicht vermeiden lasst. Es kann nur versucht werden, dass die Reorganisation moglichst selten und
1 B 2 gleichzeitig e zient durchgefuhrt werden kann. Dies konnte naiv erreicht werden, indem jeder nachfolgende Mappingwert einige Zahlen zu seinem Vorganger uberspringt. Treten nun neue Eintrage auf, konnen diese solange eingefugt werden, wie freie Platze existieren. Ein Problem dieses Ansatzes ist jedoch, dass nicht bekannt ist, in welcher Reihenfolge Strings auftreten und es ist ganzlich unbekannt an welcher freien Position ein Element eingefugt werden muss/soll (in der Mitte, an der ersten oder letzten freien Position?). Eine falsche Position bedingt eine schnellere Reorganisation. Aus diesem Grund muss ein besser geeignetes Verfahren verwendet werden.
Ein solches wird fur XML-Daten in [
Anstelle eines Strings, um den Pfad eindeutig zu identi zieren, werden nun beispielsweise 32 Bit Werte verwendet. Im Folgenden werden weiterhin jeweils 2 Bit pro Ebene verwendet. Wobei fur jede neue Ebene, die neu hinzukommenden Bits an den bereits bestehenden Bits dahinter gehangen werden (von der gro ten zur kleinsten Wertigkeit). Es ergeben sich insgesamt maximal 16 Ebenen. Von den moglichen vier (2b = 22) Werten pro Ebene konnen nur drei verwendet werden (00, 01, 10). Dies ergibt sich daraus, da der Wert 11 ungerade ist. In einem solchen musste nach der
oben genannten De nition ein Element ablegt werden. Jedoch existiert nach diesem kein weiteres gerades Element, womit nach einem falsch einsortierten Element kein weiteres lexikogra sch dahinter liegendes Element eingefugt werden kann. Dies wurde eine fruhere Reorganisation erzwingen, was zu vermeiden ist. In Abbildung 3 ist das bereits weiter oben gezeigte Beispiel nochmals auf diesen Sachverhalt abgebildet.
Ein gro es Problem dieses Ansatzes ist jedoch die geringe Auslastung. So werden hochstens 50 % der moglichen Werte verwendet und auch nur genau dann, wenn keine zusatzlichen Ebenen vorhanden sind. Somit treten wiederum sehr schnelle Reorganisationen auf. Auf der anderen Seite kann eine Reorganisation sehr schnell durchgefuhrt werden. Sie ist auf wenige logische Operationen pro Worterbuch- und Chunk-Eintrag beschrankt (SHIFT- und OR-Operationen). Gleichzeitig kann durch eine Reorganisation die Ebenenanzahl verringert und somit die Anzahl an Bits pro Ebene vergro ert werden. Die theoretisch mogliche Auslastungsgrenze steigt automatisch an. 3.2
Die globale Architektur besteht aus der Zusammenfassung
aller lokalen Verarbeitungseinheiten zu einer globalen
Einheit. Diese sind mittels der Technik eines Chord-Ringes [
Fur die Umsetzung eines Scale-Outs wird eine Fragmentierungs- und Allokationsfunktion benotigt. Erstere de niert wie welche Daten aufgeteilt werden, letztere auf welchen Knoten welches Element abgelegt wird. Beide sollten moglichst einfach zu berechnen sein, da sie fur jede Anfrage benotigt werden (Datenlokalisation). Der Chord-Ring de niert hier bereits eine Hashfunktion h(x). Diese erzeugt durch die Eingabe von Daten einen Hashwert, der genau einem Knoten im Chord-Ring zugeordnet ist. Eine einfache Datenlokalisationsfunktion ist hierdurch gegeben. Der Vorteil, der hieraus entsteht ist ein globaler und uchtiger Index, der keinerlei Wartung benotigt und auf allen n Elementen gleicherma en zur Verfugung steht.
Fur die Indizierung von RDF-Tripeln werden alle einstelligen Kombinationen aus Subjekt, Pradikat und Objekt erzeugt (s!op, p!so, o!sp). Diese werden nun mittels h(x) auf den Ring verteilt, indem das zu indizierende Element in h(x) gegeben wird und der entsprechende Knoten bestimmt wird. Fur dasselbe Literal ergibt sich immer derselbe Hash und somit ist immer derselbe Knoten zustandig.
Im ersten Schritt wird eine beliebige SPARQL-Anfrage einem Client an einem beliebigen Knotenelement gesandt. Der Empfanger wird zum Koordinator dieser Anfrage. Nun zerlegt er die SPARQL-Anfrage und uberpruft, ob er alle Daten lokal besitzt. Ist dies der Fall, liest er die Daten aus und fuhrt die gesamte Berechnung durch. Ansonsten leitet er die umgeschriebenen Subanfragen an die zustandigen Knoten weiter. Hierfur wird die Hashfunktion h(x) benotigt, in dem der nicht variable Teil einer jeden WHERE-Bedingung eingetragen wird. Wahrend des Rewriting-Vorganges werden FILTER-Statements beachtet und in die Subqueries einbezogen, falls dies moglich ist (globale Optimierung). Durch diese Technik arbeiten mehrere Knoten parallel an derselben Ausgangsquery. Als Nebene ekt wird die Datenmenge verkleinert. Nach dem Erhalt der Subqueries arbeiten die Knoten diese ab (lokale Anfrageverarbeitung; siehe Kapitel 3.1) und senden das Ergebnis an den Koordinator zuruck. Dieser fuhrt die benotigten Joins und die restlichen FILTER-, GROUP BY-, HAVING-, ORDER BY-, LIMIT-, OFFSET, Projektions-, usw. Operationen durch. Zum Schluss wird das Ergebnis an den Client gesandt.
Ein Problem dieses Ansatzes ist die mehrfache redundante
Datenhaltung derselben Daten in maximal drei
verschiedenen Knoten und die dafur zweimal hohere
Speicherkapazitat. Dies ist jedoch nur bedingt ein Nachteil. Durch den
automatisierten Scale-Out-Mechanismus kann ein lokales
Element entlastet werden, indem ein neuer Knoten einen
Teilbereich der Hashwerte und die darin abgebildeten Daten fur
sich beansprucht. Ein weiterer Vorteil ist die Moglichkeit
auf sehr gro e Anfragelasten dynamisch reagieren zu
konnen. Es konnen automatisch neue Knoten hinzugefugt
werden, die einen Teil der Anfragelast ubernehmen. Die
Aufteilung des Speicherplatzes und Anfragelast, wird jeweils durch
die konsistente Hash-Funktion h(x) garantiert [
In dieser Arbeit wurde ein Ansatz vorgestellt, der mehrere Hundert Milliarden bzw. mehrere Billionen RDF-Tripel Linked Open Data e zient verwalten kann. Es wurde eine Unterscheidung in lokaler und globaler Verarbeitung durchgefuhrt. Die lokale Verarbeitungseinheit besteht aus einem hochoptimierten In-Memory C++-Programm zur Datenhaltung und -abfrage, das die Strukturen moderner Hardware e zient ausnutzt. Im selben Abschnitt wurde eine Moglichkeit aufgezeigt, Bereichsanfragen e zient zu verarbeiten, indem ein ordnungserhaltendes Mapping von Strings auf Integerwerten dargestellt wurde. Dies wird durch einen ordnungserhaltenden und updatefreundlichen Baum garantiert.
Die globale Verarbeitungseinheit besteht aus dem Zusammenschluss mehrerer lokaler Komponenten und verwendet hierzu die Technik des Chord-Ringes. Jedes Element ist gleichberechtigt, es existiert somit kein zentraler Koordinator. Fur die Verbindung untereinander existieren Finger, die eine maximale Anzahl an Weiterleitungen garantieren. Zur Verarbeitung von beliebigen SPARQL-Anfragen werden diese von einem Knoten entgegengenommen, optimiert und an den betre enden Knoten gesandt. Zur Datenlokalisation wird eine einfache Hashfunktion und kein global zu p egender Index benotig. Des Weiteren ist dieses Verfahren unabhangig gegenuber der Anzahl an Tripeln und dem benotigten Speicherplatz, da ein automatischer Scale-Out-Mechanismus existiert.
In der weiteren Forschung mussen einige Punkte naher betrachtet werden, die als Motivation zu diesem Ansatz dienen. Hierunter fallt die Einhaltung der garantierten Antwortzeit aller Anfragen bis zu einem vorher de nierten Prozentsatz. Zur Unterstutzung dieser Forderung ist eine Replikation der Daten denkbar.
Dies fuhrt zum nachsten Problem, der e zienten
Replikation. Bis zu diesem Zeitpunkt werden alle Daten nur auf
einem Knoten vorgehalten. Sturzt dieser ab, sind all seine
Daten verloren und nachfolgende Anfragen konnen nicht mehr
beantwortet werden. Als Ausweg bestunde die Moglichkeit,
ein ahnliches Vorgehen umzusetzen, wie es in Amazons
Dynamo [
Zur weiteren Performancesteigerung ist es notwendig den LODCache weiter zu optimieren. Es existiert zum Beispiel die Moglichkeit auf einer SandyBridge-CPU eine Schleife direkt im CPU eigenen Loop-Cache abzulegen. Eine Performancesteigerung von uber 100 % soll moglich sein. Jedoch ist die Bedingung hierfur, dass alle Instruktionen hochstens 28 -Operationen lang sind.
Der oben beschriebene Ansatz zum Mapping von Strings auf ordnungserhaltende Integerwerte muss weiter erforscht werden. Es ist u. a. notwendig, die Operationen zur Reorganisation e zienter anzuordnen. Eine Moglichkeit zur Erhohung der Auslastung wird au erdem angestrebt. In diesem Zusammenhang soll gleichzeitig ein Verfahren entwickelt werden, um Updates auf bestehende Daten moglichst e zient durchzufuhren.
Fur die weitere Entwicklung und Evaluierung des Systems
wird zukunftig ein Benchmark eingesetzt. Es wurde der
Berlin SPARQL Benchmark [
Die Performanz des Systems wird durch verschiedenartige SPARQL-Anfragen ermittelt, die sich in A quivalenzklassen einteilen lassen. Den einfachen SPARQL-Anfragen, den Anfragen, die eine Datenmanipulation erfordern sowie den analytischen SPARQL-Anfragen.