私たちは、反復ごとに1組のSPARQLクエリを使用して反復アルゴリズムを構築しています。このアルゴリズムはうまくいきますが、CPU使用率の問題が発生しています。 FusekiのようなSPARQLエンジンは本当にマルチスレッド化されていません。複数のスレッドで複数の同時クエリを実行できますが、個々のクエリはシングルスレッド化されています。 Fusekiのノートを見ると、Fusekiはスレッドセーフではないという印象を受けるので、これは簡単な問題ではありません。スレッド化されたSPARQL実装がありますか？
私たちのアルゴリズムはSPARQLクエリに関して本質的にシリアルであり、同時に実行することに興味があるので、32コアを利用できるSPARQLエンジンがいくつかありますか？
はい、あります。BigDataはこれのオープンソース/商用の例です。また、彼らは常にこれに従わないのに私の場合、私は、並列化するネットPLINQ機能が加わり製品、FILTERとBIND操作をlevarage、多額のマルチスレッド使用dotNetRDF
私自身のプロジェクト。
Fuseki（免責事項私はApache Jenaプロジェクトにも参加しています）AndyS氏はFuseki自身がスレッドセーフであると指摘しています。問題は、クエリエンジン（ARQ）が操作を並列化するようには設計されていないことです。これに関するいくつかのアイデアは過去に議論されましたが、IMOではかなりの書き換えが必要です。
私はBigDataをチェックアウトします。私たちのマシンはヘッドレスのLinuxボックスです。私はそれを避けることができれば、Windowsをどうやって入手するのか把握しなくてもいいので、最初に代替案をチェックします。しかし、それは私が必要なことを行うだろうdotNetRDFのようだ。 – Adam
あなたの規模にもよりますが、dotNetRDFにはスレッドエンジンがありますが、現在のインカネーションでは数百万のトリプルにしかスケールされておらず、非永続ストアです（毎回データを読み込む必要があります）。 BigDataは、特に生産シナリオのためのより良いオプションです。 – RobV
YarcDataが開発し販売しているUrikaエンジンは、非常にマルチスレッド化されており（最大数千の同時スレッド）、非常に大きなメモリで動作します。おそらく愛好家の予算には適していません。 :)
ふせきは設計上スレッドセーフです。問題がある場合は、バグレポートを提出してください。 – AndyS
@AndyS、私が収集したものから、自分のトランザクションで複数のスレッドを持つことができるという意味で、マルチスレッド化されています。ただし、複数のスレッド間で同じトランザクションを分割することはできません。このhttp://jena.apache.org/documentation/tdb/tdb_transactions.htmlによると、同じトランザクションへのマルチスレッドアクセスは読み取り専用（または書き込みを行っている1つのスレッド）に限られているため、スレッドセーフではないという私のコメント（少なくとも私が望むものは）。私はまた、エンジンは、単一のクエリのために複数のコアを利用しないことに注意します。これは私が探しているものです。したがって、私の質問です。 – Adam