Projektgruppe: Master

Sprache Englisch

In Smart-KG (SKG)~[1] schlägt der Autor eine Client-Server-Architektur für die Verarbeitung von SPARQL-Anfragen vor. Angesichts des RDF-Datensatzes erstellt der Server zunächst Partitionen des gegebenen Datensatzes, die während der Ausführung der SPARQL-Anfrage an den Client gesendet werden können. Diese Partitionen sind komprimiert und werden von den Clients während der Ausführung der Anfrage dekomprimiert. Die Partitionen werden auf der Grundlage des Konzepts der Characteristic Sets~[2,3] erstellt, das die Struktur von RDF-Graphen ausnutzt, um Entitäten zu gruppieren, die mit denselben Prädikatsmengen beschrieben werden. Darüber hinaus kann der Client auch unkomprimierte Ergebnisse vom Server erhalten, indem er die Triple-Pattern-Fragmente (TPF)~[4] verwendet. Sobald alle benötigten Ergebnisse vom Server geliefert wurden, führt der Client einen lokalen Join durch, um das endgültige Ergebnis der gegebenen SPARQL-Anfrage zu generieren. Die Kombination von Server und Client zur Verteilung der Arbeitslast hat die Effizienz der Abfrageverarbeitung erhöht. Wise-KG (WKG)~[5] (eine verbesserte Version von SKG) hingegen nutzt die Eigenschaften sternförmiger Unterabfragen und die Informationen über die aktuellen Client- und Server-Ressourcen, um die Kosten für die Verarbeitung jeder sternförmigen Unterabfrage auf dem Client (unter Verwendung von SKG) oder auf dem Server (unter Verwendung von Star Pattern Fragments (SPF)~[6]) abzuschätzen und so dynamisch die effizienteste Ausführungsstrategie zu wählen. Das bedeutet, dass Server im Gegensatz zu SKG auch Joins der Star Triple Patterns durchführen können. Diese Verbesserung bezieht sich jedoch nur auf sternförmige Joins. Es gibt auch andere Arten von Joins, z. B. Pfad-Joins, Sink-Joins oder hybride Joins (Einzelheiten zu diesen Joins finden Sie in [7]). In diesem Projekt wollen wir einen Schritt weiter gehen: In WKG werden die Pfad-Joins immer auf der Client-Seite ausgeführt, und wir wollen ein Kostenmodell vorschlagen, das entscheidet, ob der gegebene Pfad-Join auf dem Client oder auf dem Server ausgeführt werden sollte. Das Kostenmodell berechnet grundsätzlich die Zeit, die benötigt wird, um den gegebenen Path Join sowohl auf dem Server als auch auf dem Client auszuführen. Die Option mit den geringsten Kosten wird dann ausgewählt. Dieser Ansatz würde das Kostenmodell weiter verfeinern, da nicht nur die Sternabfragen (s-s join), sondern auch die Pfadabfragen (s-o join) in den Entscheidungsprozess einbezogen werden. Alle in WKG durchgeführten Experimente werden wiederholt, um die Laufzeitleistung des vorgeschlagenen Modells mit der von WKG zu vergleichen.