Sparql 为什么rdflib这么慢？

我有一个很大的rdf文件：

• 大小：470MB
• 线路数量：近600万条
• 独特的三个主题：约650000
• 三倍金额：约4200000

我通过以下方式将rdf定义加载到rdflib的berkeley db后端：

graph = rdflib.Graph("Sleepycat")
graph.open("store", create=True)
graph.parse("authorities-geografikum_lds.rdf")

在我的笔记本上花了好几个小时才完成。这台计算机的功能不是很强大（英特尔B980 CPU，4GB内存，没有SSD），而且它的定义也很大——但这项任务的时间似乎相当长。可能部分原因是索引/优化数据结构

真正令人恼火的是完成以下查询所需的时间：

SELECT (COUNT(DISTINCT ?s) as ?c)
WHERE {
    ?s ?p ?o
}

（结果：667445）

花了20多分钟

SELECT (COUNT(?s) as ?c)
WHERE {
    ?s ?p ?o
}

（结果：4197399）

花了超过25分钟

根据我的经验，一个充满可比较数据的关系型数据库管理系统在给定适当索引的情况下，可以在很短的时间内完成相应的查询

因此，我的问题是：

为什么rdflib这么慢（特别是对于查询）

我可以像使用RDBMS中的索引那样优化数据库吗

---

就性能而言，另一个（免费且“紧凑”）的三重存储是否更适合这种大小的数据？

问题是，为什么要在关系数据库之上使用

rdflib

，而不是“适当”的三重存储？有一些开源软件，如ApacheJena Fuseki、Virtuoso等。关于你的问题，我怀疑当查询需要20分钟才能完成时，是否会使用任何索引。但是开发人员可以更好地回答这一问题。我研究了实现，我认为您的查询非常糟糕。我的意思是，它不是一个进行SPARQL到SQL重写的存储，而是实现一个迭代器模型+数据库中的一些索引。所以它必须得到所有的三元组，然后在内存中进行计数。当然，它看起来还是有点慢。这里有一些相关的问题：在RDF的早期，还没有本地RDF存储。第一批RDF存储是在现有存储引擎（如SQL数据库和BDB）的基础上构建的。rdflib实现可以追溯到早期。这现在是一种过时的方法，因为本机存储提供了更好的性能和完整的SPARQL遵从性。（Virtuoso在这里是一个有趣的异常值；AIUI的RDF存储今天仍然是一个经过高度调优的关系引擎，并且实际上具有很好的性能。）