@Michael，我很高兴您介入，因为您在这方面肯定比我了解更多:)。在这一点上，我正在进行学习之旅。应您的要求，这是启发我理解的一篇论文：
arxiv.org/abs/1801.02911（使用 Gremlin Traversals 对属性图进行 SPARQL 查询）
我引用他们
“我们对 Gremlinator 进行了全面的实证评估，并通过在领先的图形存储 Neo4J、Sparksee 和 Apache TinkerGraph 上执行 SPARQL 查询来证明其有效性和适用性，并将性能与 RDF 存储 Virtuoso、4Store 和 JenaTDB 进行比较。我们的评估证明了Gremlin 对应的 SPARQL 查询获得了显着的性能提升，尤其是对于星形和复杂查询。”
然而，他们解释说，事情在某种程度上取决于查询的类型。
或者正如另一个答案所说，在堆栈溢出中，关系数据库和图形数据库的比较也有助于理解 Set 和 path 之间的问题。我的理解是 TripleStore 也可以与 Set 一起使用。话虽如此，我绝对不知道最近在 TripleStore 中实现的所有优化技术，并且我看到了几篇解释显着修剪集合连接操作的技术的论文。
在分配上它更多的是一种胆量。例如，以分布式方式进行连接操作对我来说听起来非常但非常昂贵。我没有论文，我的研究也不是详尽无遗的。但是从我有红色的东西来看，我将不得不在我的 Evernote 中挖掘 :) 来支持它，这是分发的根本问题。这里的自动智能分片似乎无助于缓解这个问题。
@Michael 这是一个非常但非常复杂的主题。我明确地踏上了旅程，这就是为什么我用stackoverflow帮助自己来指导我的研究。你可能知道为什么。因此，请随意提供指针。
话虽这么说，我并不是说 RDF 存在问题并且 Property-Graph 更好。我是说，在某种程度上，当涉及到图形遍历时，有一些方法可以实现一个快速的后端。数据模型不是这里的问题，用于支持遍历的数据结构是问题。我要说的第二件事是，查询语言的选择似乎会影响“遍历”的执行方式，从而影响用于支持数据模型的数据结构。
到目前为止，这是我的理解，是的，我确实理解还有很多其他因素在起作用，并且可以随意列举其中一些来指导我的旅程。
简而言之，我的问题归结为，是否可以让 RDF 存储由所谓的 Native Graph Storage 支持，然后根据遍历步骤实现 Sparql，而不是根据其代数加入集合？这不是让事情变得更快吗。这似乎是https://github.com/graknlabs/grakn采取的方法它主要由 janusGraph 支持，用于存储图形。虽然不是 RDF，但 Graql 和拥有 RDFS++ + Sparql 是一样的 Idea。他们声称只是做得更好，对此我有所保留，但这不是这个线程的基本问题。底线是他们通过信息检索（路径遍历）和 Property-Graph 支持的伴随存储方法来支持知识表示。让我明确一点，我并不是说图原生存储是属性图的属性。在我看来，这只是一种优化存储图结构的存储方法，其中信息检索涉及（路径）遍历：https ://docs.janusgraph.org/latest/data-model.html 。