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

Question

基于 Sparql 的存储，或者换一种说法，TripleStore，已知比属性图存储效率低，除了不能在保持属性图性能的同时进行分发。

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

更具体地说，为什么是存储问题。是什么限制了基于 Sparql 的存储像属性图存储一样存储数据，并执行遍历而不是大量连接查询。例如，sparql 不能简单地翻译成 Gremlin 步骤吗？那里有什么限制？不能避免join吗？

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

话虽这么说，Sparql 当然不是图灵完备的，但至少就它的功能而言，它可以快速完成并且可能还可以大规模完成。在我看来，目标不是竞争，而是受益于 SPARQL 的易用性和使用像 gremlin 这样的遍历语言来处理真正需要它的事情，例如OLAP。

在这个方向上是否有任何项目，Apache jena 是否考虑过这些？

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

Answer 1

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

arxiv.org/abs/1801.02911（使用 SPARQL 查询属性图 Gremlin 遍历）

我引用他们

“我们对 Gremlinator 和 通过执行 SPARQL 查询证明其有效性和适用性 在领先的图表之上存储 Neo4J、Sparksee 和 Apache TinkerGraph 并与 RDF 存储 Virtuoso 比较性能， 4Store 和 JenaTDB。我们的评估表明 SPARQL 的 Gremlin 对应物获得的性能增益 查询，尤其是星形查询和复杂查询。”

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

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

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

@Michael 这是一个非常但非常复杂的主题。我明确地踏上了旅程，这就是为什么我用stackoverflow帮助自己来指导我的研究。你可能知道为什么。因此，请随意提供指针。

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

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

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

Answer 2

首先，我希望看到支持您声称基于 RDF 的系统本质上不如属性图系统的参考文献，因为坦率地说，这是一个荒谬的主张。此外，已经分发了，我假设您的意思是横向扩展的 RDF 存储，因此声称它们无法分发是完全不正确的。

Property Graph 模型和 Gremlin 可以轻松地在基于 RDF 的系统之上实现。据我所知，这已经完成了两次，并且在其中一个实现中，Gremlin/Property Graph 层支持推理。因此，您无需成为基于属性图的系统即可支持该模型。系统、RDF 和 Property Graph 做出具体实施选择的原因有很多，从存储到执行等等，这些选择是由“本机”模型、选择实施的技术指导的，也许最重要的是，系统的用例及其要解决的问题。

此外，您还不清楚您建议基于 RDF 的系统的作者实际做什么；您是否建议横向扩展是有益的？你是不是说你对 Propety Graph 模型的偏好应该被视为福音，这样基于 RDF 的系统就会放弃并切换数据模型？您是否希望 Property Graph 系统改造 RDFS？

最后，对于您提出的最初问题，我认为您完全倒退了； Property Graph 模型是混合了图和键值模型元素的混合图模型，而RDF 模型是纯的，即原生的图模型。 Gremlin will be adopting the RDF model，尽管在 RDF 世界中被称为物化的语法糖，但对其他人来说，边缘属性。因此，在您的 Property Graph 模型示例正在放弃所述模型的世界中，除了您应该做更多的背景研究之外，我不确定还能告诉您什么。