Gibt es SPARQL-Implementierungen mit Threads?

Wir erstellen einen iterativen Algorithmus mit einer Reihe von SPARQL-Abfragen für jede Iteration. Dieser Algorithmus funktioniert gut, aber wir stoßen auf ein CPU-Auslastungsproblem. SPARQL-Engines wie Fuseki sind nicht wirklich Multithread; Sie ermöglichen die Ausführung mehrerer simultaner Abfragen in mehreren Threads, aber jede einzelne Abfrage ist single threaded. Beim Betrachten einiger Fuseki-Notizen habe ich den Eindruck, dass Fuseki nicht threadsicher ist, also ist das kein triviales Problem.Gibt es SPARQL-Implementierungen mit Threads?

Da unser Algorithmus in Bezug auf die SPARQL-Abfragen inhärent seriell ist und wir uns für einen Lauf nach dem anderen interessieren, gibt es eine SPARQL-Engine, die beispielsweise 32 Kerne nutzen kann?

Quelle

2013-02-07 Adam

Fuseki ist durch das Gewinde sicher. Wenn es Probleme gibt, reichen Sie bitte einen Fehlerbericht ein. – AndyS

@AndyS, von dem, was ich erfahre es ist Multithread in dem Sinne, dass ich mehrere Threads jeweils mit ihrer eigenen Transaktion haben kann. Sie können jedoch dieselbe Transaktion nicht auf mehrere Threads verteilen. Diese http://jena.apache.org/documentation/tdb/tdb_transactions.html besagt, dass der Multithread-Zugriff auf dieselbe Transaktion auf schreibgeschützt beschränkt ist (oder ein Thread, der Schreibvorgänge ausführt), daher mein Kommentar, dass es nicht Thread-sicher ist (zumindest für was ich will). Ich merke auch, dass die Engine nicht mehrere Kerne für eine einzelne Abfrage nutzt, was ich suche, daher meine Frage. – Adam

Ja, es gibt BigData ist ein Open Source/kommerzielles Beispiel dafür.

Mein eigenes Projekt dotNetRDF auch stark Multi-Thread verwendet, in meinem Fall levarage ich die .Net PLINQ Funktion parallelisieren verbindet, Produkte, FILTER und BIND Operationen obwohl sie dies nicht immer zugänglich sind.

Auf den Hinweis von Fuseki (Haftungsausschluss Ich bin auch in der Apache Jena-Projekt beteiligt) wie AndyS darauf hinweist Fuseki selbst ist thread sicher. Das Problem besteht darin, dass die Abfrage-Engine (ARQ) nicht dafür ausgelegt ist, Operationen zu parallelisieren, einige Ideen dazu wurden in der Vergangenheit diskutiert, aber IMO würde es eine ziemlich signifikante Neuschreibung beinhalten.

Quelle

2013-02-07 18:07:34 RobV

Ich überprüfe BigData. Unsere Maschine ist eine kopflose Linux-Box, und ich würde es lieber vermeiden, herauszufinden, wie ich Windows darauf bekomme, wenn ich es vermeiden kann, also werde ich zuerst nach Alternativen suchen. Aber es scheint, dass dotNetRDF tun würde, was ich brauche. – Adam

Hängt von Ihrer Skalierung ab, während dotNetRDF eine Threaded-Engine hat, die in ihrer aktuellen Inkarnation nur auf einige Millionen Tripel skaliert und ein nicht persistenter Speicher ist (d. H. Sie müssen die Daten jedes Mal laden). BigData ist wahrscheinlich die bessere Option, besonders für Produktionsszenarien. – RobV

Die Urikan-Engine, die von YarcData entwickelt und vermarktet wird, ist hoch multithreaded (bis zu mehreren tausend gleichzeitige Threads) und läuft in sehr großem Speicher. Wahrscheinlich nicht für ein Hobbybudget geeignet. :)

Quelle

2014-04-07 21:23:14 spreinhardt

Eigentlich kam diese Frage von der Arbeit an einem Eintrag zu der YarcData Challenge, die sie vor einiger Zeit gemacht haben, wo wir uRiKa verwenden konnten. Aber wir wollten etwas mit A) zum Debuggen und so spielen und B) um uRiKa mit einer klassischen Maschine zu vergleichen. – Adam

Oh, und uRiKa ist eine ganze Appliance, nicht nur ein Stück Software. Die Maschine verwendet ThreadStorm-Prozessoren (die von den alten XMTs abstammen, wenn Sie daran interessiert sind), die ihre Threading auf eine grundlegend andere Weise als die x86-Chips betreiben. Selbst wenn Sie das Geld hatten, konnten Sie ihren Motor nicht wirklich auf einer Standardmaschine verwenden. – Adam

Gibt es SPARQL-Implementierungen mit Threads?

Antwort

Verwandte Themen