我正在研究 native 图形数据库和三元存储(RDF存储)供我们使用。目前，我们主要关注用于三重存储的Marklogic和Neo4j，以及 native 图数据库的OrientDB。
下面这个问题的A部分列出了背景信息-我正在研究这两种类型的数据库之间的主要区别。我想在第一部分中进行验证-我是否在这张照片中遗漏了任何东西。
第二部分-B部分，我正在寻找有关每个DB有多少的答案，这些是我在A部分中概述的。
A部分:
到目前为止，AFAIK的主要区别是-基于关系本身，三元存储存储关系，或更确切地说是边缘。因此，这是一个“包”，每个边缘上都有特定的，经过精心设计的属性，以反射(reflect)该关系的语义。另一方面， native 图数据库存储图结构-节点上的节点和链接，以及要在这些节点和链接上定义的属性。
我认为，为了公平地看待这两个，以下两个将设置两个极端。以下两个是极端情况-我很确定那里的数据库所完成的工作远不止这些极端情况之一。
1.)包的边缘(三元组存储):在总体上，每个主语-谓语-宾语三元组，比如(sourceNode, edge, destNode)作为单个记录存储，形成三元组存储条目。在这3列的每列上都为三元商店建立索引，因此当我需要一个拥有居住在澳大利亚的 friend 的人的列表时，我(或者说三元商店引擎)会迅速获得“ friend ”关系，并在其中进行搜索具有源或目标节点的节点，其中该节点是一个人，并且具有“居住在澳大利亚”的属性。
2.) native 图:带有标签和属性以及它们之间的链接的节点。为了找到“有在澳大利亚居住的 friend ”的人，我首先找到标记为“人”的节点，然后搜索该节点的关系列表(这是链接列表(？))，然后从那里。这是2次搜索，一次是在节点上，第二次是在该节点的关系上，而不是一次搜索三元组的关系(三元组)。
关于三元存储与本 map 形数据库的优缺点，我一直在博客上看到的一件事是，三元存储因其索引而在查询中得分:可以快速访问这些关系。在 native 图数据库中，关系是通过关系所涉及的节点来访问的。 (我知道，通过同样的道理， native 图数据库具有保留图结构的优势，因此图算法和解决方案可以更轻松地实现并运行得更快。)
但是，如果缺少索引，则 native 图db不一定具有缺点，前提是它允许根据节点和/或关系的属性和/或标签来对节点和/或关系进行索引。
我想知道
Marklogic，Neo4j和OrientDB到底有多少？我浏览了this上有关
Neo4j的书籍的第6章，没有看到关于直接搜索边缘索引(关系)的任何信息。我错过了什么吗？如果我确实错过了它，并且
Neo4j在边缘具有这样的索引，那么三元存储为何比本 map 形数据库具有快速查询的主要优势？TIA。
//----------------------
编辑:
注意:除了其他有用的讨论之外，我还看到了Graph DBs vs. Document DBs vs. Triplestores。
最佳答案
对于A部分:三元存储和图存储之间的差异-差异不在于存储的内容，而在于如何查询它们。
图存储旨在回答图查询。包含有关图形结构问题的事物。这包括两点之间的最小距离(例如，路线规划)，可能需要进行条件评估(例如，避开高速公路/高速公路，或者我以50mph的极限驾驶大篷车)，还可能包括返回计算出的值(例如，距离/时间)采取最佳路线步骤)。这也可能包括查找相似的子图以及各种其他图类型查询。
三元商店旨在返回有关一个或多个匹配主题的信息。例如。 “找到所有认识其他属于毒品帮派组织成员的人，并返回他们的个人资料信息”。在此查询中，您要查询的网络范围是已知的(人->人->组织->组织类型)，并且您正在返回一组信息(所有“人”断言)。这是一个三重查询。
由于上述两种查询类型的性质，您会看到非常不同的物理体系结构。 Neo4j和大多数图存储将采用“每个节点上的所有信息”的方法，其中多个节点用于扩大查询负载。其他节点包含数据的100％副本。
另一方面，三元组存储(纯播放或混合NoSQL数据库，如MarkLogic和OrientDB)被设计为将数据拆分为多个服务器上的分区/分片。这允许在商品硬件上实现线性可伸缩性，而不是需要大量锡的大量数据。当然，不利的一面是，如果某些数据位于多个服务器之间，则会受到本地网络的冲击，从而完成复杂的“图形样式”查询。
这并不是说图存储不能存储三元组(它们确实可以)或者三元存储不能执行图查询(它们可以，您只需要自己构造它)就可以了，但是它们主要是为不同的查询类型构建的。
我有一个查询控制台示例，该示例涉及在MarkLogic的三重存储中的大型数据集中进行图形查询的情况，该查询在几秒钟内运行，而不是“普通”三重存储查询的通常毫秒。
由万维网联盟(W3C)领导的三重商店周围有开放标准。这些标准包括RDF和SPARQL，以及相关标准。当然，使用开放标准可以避免供应商锁定一种产品。在这方面，MarkLogic Server和Allegrograph均符合开放标准。
W3C标准的缺点是，RDF没有“关于关系的断言”的概念-即，它不允许在关系本身上存储属性。一些图形存储(例如Neo4j)确实允许这样做。您可以通过在三重存储中将关系作为一种“事物”来进行建模，但这并不是一个很好的心理模型。
如果您同时拥有文档和三元组，则 native 支持两者的索引和查询的混合NoSQL数据库将很有用。 MarkLogic Server和OrientDB均提供此功能。 MarkLogic Server允许您执行结构(有/没有元素)，字段(完全匹配)，范围(小于，大于)，地理空间(区域内的点，例如任意多边形)，双时态(需要)对同一条记录的一击中有更多的解释空间...)和语义查询。如果您需要一些东西来覆盖这两者，则可能需要看看那里。
冒着插入我自己的工作的风险，我出版了两本有关该主题的书-NoSQL for Dummies(零售版，共400页)和The State of NoSQL 2016(仅适用于kindle)，它们将为您提供所需的所有背景知识。我还在https://adamfowler.org/blog/上写了有关相关主题的博客。希望这可以帮助。