我正在研究原生图数据库和三重商店（RDF商店）供我们使用。我们目前专注于Marklogic三重存储，Neo4j，也许OrientDB用于本机图db。
下面这个Q的A部分正在阐述上下文 - 我正在调查这两种类型的DB之间的主要区别。我正在寻找第一部分的验证 - 我是否遗漏了这张照片中的任何内容。
第二部分 - B部分，我正在寻找答案，说明每个数据库中有多少我在A部分中列出了多少。
A部分：
到目前为止，AFAIK的一个主要区别是 - 基于关系本身的三重商店关系，或者说边缘。所以，它是一个＆＃34; bag＆＃34;边缘，每个边缘都有一个特定的，设计良好的属性，以反映该关系的语义。另一方面，本机图形dbs存储图形结构 - 它们上的节点和链接，以及您希望在这些节点和链接上定义的属性。
我认为，对于这两者的公平看法，以下两个将设置两个极端。以下两个极端 - 我非常确定那里的dbs比这两个极端中的任何一个都做得更多。
1。）包边（三重存储）：在整体上，每个主题 - 谓词 - 对象三元组，比如(sourceNode, edge, destNode)存储为单个记录，形成三重存储条目。三重商店在这3列中的每一列都被编入索引，所以当我需要一个有朋友住在澳大利亚的人员列表时，我（或者更确切地说，三重商店引擎）很快得到“朋友”关系，其中，搜索具有源节点或目标节点的节点是人，并具有“居住在澳大利亚”的属性。
2.。原生图：带有标签和属性的节点，以及介于两者之间的链接。为了找到居住在澳大利亚的朋友＆＃34;我首先找到标记为＆＃34; person＆＃34;的节点，然后我搜索关系列表（这是一个链表（ ？））该节点，然后从那里开始。这是2个搜索，一个在节点上，第二个在该节点的关系上，而不是一次搜索三元组的关系（三元组）。
我一直在博客上看到的三重商店与原生图表dbs的优缺点是，三重商店因为索引而对查询进行评分：可以快速访问关系。在本机图数据库中，通过它们发生的节点访问关系。 （我知道，基于同样的原因，本机图dbs具有保留图结构的优势，因此图算法和解决方案可以更容易实现并且运行得更快。）
然而，如果允许基于其属性和/或其标签对节点和/或关系进行索引，则缺少索引不一定具有本机图db的缺点。
如果它允许标记这些标签上的节点和索引，我作为开发人员可以采用整个图的子图并从那里开始。在受限域上的这种查询会快得多。
如果它允许标记关系，那些查询＆＃34;围绕“关系，如”在澳大利亚有朋友的人的列表“可以更快地执行。因为查询不会遍历节点的链接并查找节点的属性，而是直接查找并访问链接。
我想知道其中有多少是Marklogic，Neo4j和OrientDB在做什么？
我通过Neo4j上的this书的第6章略读，并且没有看到关于边缘索引（关系）的直接搜索的任何内容。我错过了什么吗？
如果我确实错过了它并且Neo4j在边缘上有这样的索引，为什么三重存储具有快速查询优于本机图dbs的主要优势？
TIA。
// ----------------------
编辑：
注意：我在其他一些有用的讨论中看到Graph DBs vs. Document DBs vs. Triplestores。
答案 0 :(得分：5)
对于A部分：三重存储和图形存储之间的差异 - 存储内容的差异不大，但更多的是要查询它们。
图形商店旨在回答图形查询。包含有关图表结构的问题的事情。这包括两点之间的最小距离（例如路线规划），也许是条件评估（例如避开高速公路/高速公路，或者我驾驶大篷车在50英里每小时的限制），也许还包括返回计算值（例如距离/时间）采取，最佳路线步骤）。这还可以包括查找类似的子图和各种其他图形类型的查询。
三重商店旨在返回有关匹配主题的信息。例如。 “找到所有认识其他人的人，他们是Drug Gang类型组织的成员，并返回他们的个人资料信息”。在此查询中，您查询的网络边界是已知的（人 - >人 - >组织 - >组织类型），并且您将返回一组信息（所有“人”断言）。这是一个三重查询。
由于上述两种查询类型的性质，您会看到非常不同的物理体系结构。 Neo4j和大多数图形存储将采用“每个节点上的所有信息”方法，其中多个节点用于扩展查询负载。其他节点包含100％的数据副本。
另一方面，三重商店（纯游戏，或MarkLogic和OrientDB等混合NoSQL数据库）的架构是将数据分成多个服务器上的分区/分片。这允许商用硬件上的线性可扩展性，而不是需要大量锡的大量数据。当然，缺点是如果某些数据位于多个服务器上，您将获得本地网络命中以完成复杂的“图形样式”查询。
这并不是说图形商店不能存储三元组（他们这样做）或三元商店不能执行图形查询（他们可以，你只需要自己构建它） - 但它们主要是为不同的查询类型构建的。
我有一个查询控制台示例，用于跨MarkLogic三重存储中的大型数据集进行图形查询，例如，在几秒钟内运行，而不是“普通”三重存储查询的通常毫秒数。
万维网联盟（W3C）领导的三重商店有开放标准。这些标准包括RDF和SPARQL以及相关标准。当然，使用开放标准可以避免供应商锁定到一个产品。 MarkLogic Server和Allegrograph在这方面都符合开放标准。
W3C标准的缺点是，RDF没有关于“关系断言”的概念 - 即它不允许在关系本身上存储属性。像Neo4j这样的一些图形商店确实允许这样做。你可以通过在三重商店中将关系作为一种“事物”进行建模，但这不是一个很好的心理模型。
如果您同时拥有文档和三元组，那么本机支持索引和查询两者的混合NoSQL数据库非常有用。 MarkLogic Server和OrientDB都提供此功能。 MarkLogic Server允许您执行结构（具有/不具有元素），字段（完全匹配），范围（小于，大于），地理空间（区域内的点，例如任意多边形），双时间（需要）更多的空间来解释...）和语义查询在同一记录中的一次命中。如果你需要一些东西来覆盖它们，你可能想看看那里。
冒着堵塞自己的工作的风险，我已经出版了两本关于这个主题的书 - NoSQL for Dummies（零售版，400页版）和NoSQL 2016状态（仅限kindle版），它将为您提供所有背景信息需要。我还在https://adamfowler.org/blog/上写了关于相关主题的博客。希望这会有所帮助。
答案 1 :(得分：0)
在OrientDB中，您可以同时执行以下操作：
SELECT FROM People WHERE 'Australia' IN out('Friend').country SELECT expand( in ) FROM Friend WHERE out.country = 'Australia' 现在，两个查询都很慢，因为没有使用索引。在这种情况下，最好的是在People.country上创建一个索引并从“澳大利亚”开始查询并与传入的朋友交叉。示例：SELECT expand( in('Friend') ) FROM People WHERE country = 'Australia'。