sparql - 为什么 TripleStore 不像 Property-Graph Store 那样实现为 Native Graph Store？

Question

众所周知，基于 Sparql 的存储或换句话说 TripleStore 的效率低于属性图存储，而且无法在保持属性图性能的同时进行分发。

我知道这里有很多事关紧要，例如推理等等。将分布和推理放在一边，我们可以将自己限制在可以通过 SPARQL 完全捕获的 RDFS，我想知道为什么会这样？

更具体地说，为什么存储是问题所在。是什么限制了基于 Sparql 的存储像 Property graph store 那样存储数据，并执行遍历而不是大量的连接查询。例如，sparql 不能简单地转换为 Gremlin 步骤吗？那里有什么限制？不能避免连接吗？

我的假设是，如果 sparql 可以在有效的步遍历中转换，并且数据存储为属性图，例如 janusGraph 做的 https://docs.janusgraph.org/latest/data-model.html ，那么性能问题将被桥接，同时保持一些推理，如 RDFS。

话虽这么说，Sparql 当然不是图灵完备的，但至少就它所做的而言，它可以快速完成，而且还可能是大规模的。在我看来，目标不是竞争，而是为了 SPARQL 的易用性和使用像 gremlin 这样的遍历语言来处理真正需要它的东西，例如联机处理程序。

是否有朝这个方向发展的项目，Apache jena 考虑过这些吗？

出于我上面解释的原因，我看到 Grakn 的 Graql 似乎正在使用这条路，因此是什么阻止了 TripleStore 社区？

Answer 1

@Michael，我很高兴你介入，因为你在这方面肯定比我更了解:)。在这一点上，我正在进行学习之旅。应您的要求，这里是启发我理解的论文之一:

arxiv.org/abs/1801.02911 (SPARQL querying of Property Graphs using Gremlin Traversals)

我引用他们

"We present a comprehensive empirical evaluation of Gremlinator and demonstrate its validity and applicability by executing SPARQL queries on top of the leading graph stores Neo4J, Sparksee and Apache TinkerGraph and compare the performance with the RDF stores Virtuoso, 4Store and JenaTDB. Our evaluation demonstrates the substantial performance gain obtained by the Gremlin counterparts of the SPARQL queries, especially for star-shaped and complex queries."

不过，他们解释说事情在某种程度上取决于查询的类型。

或者作为另一个答案把它放在堆栈溢出中 Comparison of Relational Databases and Graph Databases也有助于理解 Set 和 path 之间的问题。我的理解是 TripleStore 也适用于 Set。这就是说我绝对不知道最近在 TripleStore 中实现的所有优化技术，并且我看到了几篇解释技术以显着修剪集合连接操作的论文。

在分配上更多的是一种胆量感受。例如，以分布式方式进行连接操作对我来说听起来非常昂贵。我没有论文，我对这些问题的研究并不详尽。但是从我有红色的东西来看，我将不得不挖掘我的 Evernote :) 来支持它，这是分发的根本问题。此处的自动智能分片似乎无助于缓解该问题。

@Michael 这是一个非常复杂的主题。我肯定在旅途中，这就是为什么我正在帮助自己使用 stackoverflow 来指导我的研究。你可能知道为什么。因此，确实可以随意提供指针。

话虽这么说，但我并不是说 RDF 有问题，而 Property-Graph 更好。我是说，不知何故，当涉及到图形遍历时，有一些方法可以实现后端来加快速度。数据模型不是这里的问题，用于支持遍历的数据结构才是问题。我要说的第二件事是，查询语言的选择似乎会影响“遍历”的执行方式，从而影响用于支持数据模型的数据结构。

到目前为止，这是我的理解，是的，我确实知道还有很多其他因素在起作用，并且可以随意列举其中的一些来指导我的旅程。

简而言之，我的问题归结为，是否有可能让 RDF 存储由所谓的 native 图形存储支持，然后根据遍历步骤而不是根据其代数连接集合来实现 Sparql？这不会让事情变得更快一点吗？这似乎是 https://github.com/graknlabs/grakn 采取的方法。它主要由 janusGraph 支持，用于类似存储的图形。虽然它不是 RDF，但 Graql 与拥有 RDFS++ + Sparql 是相同的 Idea。他们声称只是做得更好，对此我有所保留，但这不是该线程的基本问题。最重要的是，他们通过信息检索(路径遍历)和 Property-Graph 倡导的伴随存储方法来支持知识表示。让我澄清一下，我并不是说图 native 存储是属性图的属性。在我看来，这是一种优化存储图结构的存储方法，其中信息检索涉及(路径)遍历:https://docs.janusgraph.org/latest/data-model.html .