Rdf 是否存在线程化SPARQL实现？

我们正在为每次迭代使用一组SPARQL查询构建一个迭代算法。这个算法非常有效，但我们遇到了CPU利用率问题。像Fuseki这样的SPARQL引擎不是真正的多线程引擎；它们允许在多个线程中同时执行多个查询，但每个查询都是单线程的。通过查看一些Fuseki注释，我得到的印象是Fuseki不是线程安全的，所以这不是一个小问题

由于我们的算法在SPARQL查询方面本质上是串行的，并且我们对一次运行一次感兴趣，因此是否有一些SPARQL引擎可以利用（比如）32个内核？

是的，这是一个开源/商业示例

我自己的项目也大量使用多线程，在我的例子中，我使用了.Net PLINQ功能来并行化联接、产品、

过滤器和
绑定操作，尽管它们并不总是这样

关于Fuseki（免责声明我也参与了ApacheJena项目），AndyS指出Fuseki本身是线程安全的。问题在于，查询引擎（ARQ）不是为并行化操作而设计的，关于这一点的一些想法在过去已经讨论过，但在我看来，这将涉及相当重要的重写。
由YarcData开发和销售的Urika引擎是高度多线程的（多达数千个并发线程）并且运行在非常大的内存中。但可能不适合业余爱好者预算。：）
 Fuseki在设计上是线程安全的。如果有任何问题，请提交错误报告。@AndyS，从我收集的信息来看，它是多线程的，因为我可以有多个线程，每个线程都有自己的事务。但是，不能在多个线程之间拆分同一事务。这意味着对同一事务的多线程访问仅限于只读（或一个线程执行写操作），因此我的评论是它不是线程安全的（至少对于我想要的）。我还注意到，引擎并没有利用多个核心进行单个查询，这正是我所寻找的，因此我提出了问题。我将查看BigData。我们的机器是一个无头Linux机器，如果可以避免的话，我宁愿不去想如何在上面安装Windows，所以我会先看看其他的选择。但是dotNetRDF似乎可以满足我的需要。这取决于您的规模，而dotNetRDF有一个线程引擎，它在当前的版本中只能扩展到几百万个三倍，并且是一个非持久性存储（即，您每次都必须加载数据）。BigData可能是更好的选择，特别是在生产场景中。实际上，这个问题是在我们刚刚开始进行YarcData挑战时提出的，当时我们确实使用了uRiKa。但是我们想要的是A）调试之类的东西，B）将uRiKa与经典机器进行比较。哦，uRiKa是一个完整的设备，而不仅仅是一个软件。这台机器使用ThreadStorm处理器（如果您有兴趣的话，它是旧XMT的后代），其线程处理方式与x86芯片的运行方式有根本不同。所以即使你有现金，你也不能在标准机器上使用他们的引擎。