目录
3.NOSQL象限（The NOSQL Quadrants）
5.Key-Value 存储（Key-Value Stores）
近年来，一系列称为NOSQL的数据存储技术的流行迅速增长（NOSQL的厚脸皮首字母缩写，或者更具争议性的No表示SQL）。 但是NOSQL定义了不是这些数据存储区（不是以SQL为中心的关系数据库）而不是它们，这是一组有趣且有用的存储技术，其操作，功能和体系结构特征很多，而且多变。
为什么创建这些新数据库？ 他们解决什么问题？ 在这里，我们将讨论过去十年中出现的一些新数据挑战。 然后，我们将研究四个NOSQL数据库家族，包括图形数据库。
1.NOSQL的兴起
从历史上看，大多数企业级Web应用程序都运行在关系数据库之上。 但是在过去的十年中，与传统的RDBMS部署相比，我们面临的数据量更大，变化更快，结构上的变化也更大。 面对这些挑战，出现了NOSQL运动。
毫不奇怪的是，随着存储量的急剧增加，数量已成为组织采用NOSQL存储量的主要推动力。 卷可以简单定义为存储数据的大小。
众所周知，大型数据集存储在关系数据库中后变得笨拙，尤其是查询执行时间随着表的大小和联接数量的增加而增加（所谓的联接痛苦）。 这不是数据库本身的问题。 而是它是基础数据模型的一个方面，该模型在过滤以获取正确的解决方案之前为查询构建一组所有可能的答案。
为了避免连接和连接痛苦，从而更好地处理超大型数据集，NOSQL世界采用了关系模型的几种替代方法。 尽管这些替代模型更擅长处理非常大的数据集，但它们的表达性往往不如关系模型（图模型除外，后者实际上更具表达性）。
但是数量并不是现代面对Web的系统必须解决的唯一问题。除了庞大之外，当今的数据通常变化非常迅速。 速度是数据随时间变化的速率。
速度很少是静态指标。 系统的内部和外部更改以及使用该系统的环境可能会对速度产生很大影响。 加上高容量，可变速度要求数据存储不仅要处理持续的高写入负载水平，还要处理峰值。
速度还有另一个方面，即数据结构变化的速率。 换句话说，除了更改特定属性的值之外，承载这些属性的元素的整体结构也可以更改。 发生这种情况通常有两个原因。 首先是快速发展的业务动态。 随着业务的变化，其数据需求也随之变化。 其次，数据采集通常是实验性的事情。 某些属性是“以防万一”的，而其他属性则根据变化的需求在以后引入。 被证明对企业有价值的产品仍然存在，而其他产品则被淘汰。 这两种形式的速度在关系世界中都是有问题的，在关系世界中，高写入负载转化为高处理成本，而高模式波动性则具有高运营成本。
尽管评论员后来在最初的规模追求中增加了其他有用的要求，但最后一个关键方面是认识到数据远比我们在关系世界中处理的数据变化得多。 为了存在证明，请考虑我们表中的所有这些null和代码中的null检查。 这驱使最终达成共识的方面多样化，我们将其定义为数据规则或不规则结构，密集或稀疏，连接或断开的程度。
2.ACID 与 BASE
当我们第一次遇到NOSQL时，通常是在我们许多人已经熟悉的背景下进行：关系数据库。 尽管我们知道数据和查询模型会有所不同（毕竟，没有SQL），但NOSQL存储使用的一致性模型也可能与关系数据库使用的一致性模型完全不同。 许多NOSQL数据库使用不同的一致性模型来支持先前讨论的数据量，速度和数据种类的差异。
让我们探讨一下哪些可用的一致性功能可帮助确保数据安全，以及在使用（大多数）NOSQL存储时需要进行哪些取舍。
在关系数据库世界中，我们都熟悉ACID交易，这种交易已经有一段时间了。 ACID保证为我们提供了一个安全的环境，可在其中操作数据：
- 原子性（Atomic）
- 事务中的所有操作都会成功，或者每个操作都会回滚。
- 一致性（Consistent）
- 事务完成后，数据库在结构上是健全的。
- 独立性（Isolated）
- 事务不相互竞争。 数据库控制对状态的有争议访问，以便事务似乎按顺序运行。
- 持久性（Durable）
- 即使存在故障，应用事务的结果也是永久的。
这些属性意味着，一旦事务完成，其数据便是一致的（所谓的写一致性），并且在磁盘（或多个磁盘，或者实际上在多个不同的内存位置）中是稳定的。 对于应用程序开发人员来说，这是一个奇妙的抽象，但是需要复杂的锁定，这可能导致逻辑上的不可用性，并且在大多数情况下，通常被认为是重量级的模式。
对于许多域，ACID事务比域实际需要的更为悲观。 在NOSQL世界中，ACID事务已经过时，因为存储松动了对即时一致性，数据新鲜度和准确性的要求，以便获得其他好处，例如规模和弹性。 代替使用ACID，术语BASE已成为一种描述更乐观的存储策略属性的流行方式：
- 基本可用性（Basic availability）
- 该存储似乎大部分时间都在工作。
- 软态（Soft-state）
- 存储不必保持写一致，不同的副本也不必始终保持一致。
- 最终一致性（nt all the time.）
- 存储在以后的某个时刻表现出一致性（例如，在读取时懒惰）。
BASE属性比ACID保证要宽松得多，并且它们之间没有直接映射。 BASE存储重视可用性（因为这是规模扩展的核心组成部分），但不能在写入时提供副本的保证一致性。 BASE存储提供了不太严格的保证：将来数据可能保持一致，例如在读取时（例如Riak），或者始终保持一致，但仅适用于某些经过处理的过去快照（例如Datomic）。
鉴于对一致性的宽松支持，我们（开发人员）在考虑数据一致性时需要更加了解和严格。 我们必须熟悉所选存储的BASE行为，并在这些约束内工作。 在应用程序级别，我们必须根据具体情况选择是否接受可能不一致的数据，或者是否指示数据库在读取时提供一致的数据，同时导致隐含的延迟损失。 （为了保证一致的读取，数据库将需要比较数据元素的所有副本，并且在不一致的结果中甚至需要对该数据执行补救性修复工作。）从开发角度来看，这与依赖的简单性相去甚远。 代表我们管理一致状态的事务，尽管这不一定是一件坏事，但这确实需要付出努力。
3.NOSQL象限（The NOSQL Quadrants）
在讨论了可增强NOSQL存储一致性的BASE模型之后，我们准备开始研究众多的用户级数据模型。 为了消除这些模型的歧义，我们设计了一种简单的分类法，如图A-1所示。 这种分类法将当代的NOSQL空间划分为四个象限。 每个象限中的存储都针对不同类型的功能用例，尽管非功能性需求也会极大地影响我们对数据库的选择。
在以下各节中，我们将处理这些象限中的每个象限，重点介绍数据模型的特征，操作方面以及采用的驱动因素。
4.文件存储（Document Stores）
文档数据库为习惯于使用层次结构文档的开发人员提供了最直接熟悉的范例。 文档数据库存储和检索文档，就像电子文件柜一样。 文档往往由地图和列表组成，允许自然的层次结构-就像我们习惯使用JSON和XML这样的格式一样。
在最简单的级别上，可以通过ID存储和检索文档。 只要应用程序能够记住其感兴趣的ID（例如用户名），文档存储就可以像键值存储一样工作（我们将在以后进行介绍）。 但是在一般情况下，文档存储依赖索引来根据其属性来方便地访问文档。 例如，在电子商务场景中，我们可能使用索引来表示不同的产品类型，以便可以将其提供给潜在的卖方，如图A-2所示。 通常，索引用于从存储中检索相关文档集，以供应用程序使用。
与关系数据库中的索引非常相似，文档存储中的索引使我们能够以写入性能为代价来获得更高的读取性能。 写操作成本更高，因为它们还维护索引，但是读操作需要扫描较少的记录才能找到相关数据。 对于繁重的记录，需要牢记的是索引实际上可能会降低整体性能。
在没有索引数据的地方，查询通常要慢得多，因为必须对数据集进行完全搜索。 显然，这是一项昂贵的任务，应尽可能避免。而且，正如我们将看到的那样，而不是在内部处理这些查询，对于文档数据库用户来说，在并行计算框架中外部化这种处理是正常的。
因为文档存储的数据模型是断开连接的实体之一，所以文档存储往往具有有趣且有用的操作特征。 由于在写时相互独立的记录之间没有竞争状态，并且不需要在副本之间进行事务处理，因此它们应该水平缩放。
分片（Sharding）
大多数文档数据库要求用户计划跨实例的数据分片以支持水平扩展。 因此，向外扩展成为开发和运营的明确方面。 相比之下，键值和列族数据库往往不需要这种计划，因为它们将数据分配给副本作为其内部实现的正常部分。 有时令人费解地认为这是选择文档存储区的积极原因，最有可能是因为它引起（错位）兴奋，即通过分片进行缩放是一种应被接受和称赞的东西，而不是被熟练而勤奋地掌握的东西。
对于写操作，历史上，文档数据库提供的事务性仅限於单个记录的级别。 也就是说，文档数据库将确保对单个文档的写入是原子的-假设管理员在设置数据库时选择了安全的持久性级别。 在此类别中逐渐出现了对跨文档集进行操作的支持，但还不成熟。 在没有多键事务的情况下，应由应用程序开发人员在应用程序代码中编写补偿逻辑。
由于未连接存储的文档（通过索引除外），因此有许多乐观的并发控制机制可用于帮助协调单个文档的并发竞争写入，而不必求助于严格的锁定。 实际上，某些文档存储区（例如CouchDB）已将其作为其价值主张的关键点：文档可以保存在多主数据库中，该数据库在多个实例之间自动复制并发访问的竞争状态，而不会受到用户的过度干扰。
在其他存储中，数据库管理系统也可能能够区分和协调对文档不同部分的写入，甚至可以使用时间戳将多个竞争写入协调为一个逻辑上一致的结果。 这是一个合理的乐观权衡，因为它通过使用可替代的机制来减少对事务的需求，这些机制可乐观地控制存储，同时力争提供更低的延迟和更高的吞吐量。
5.Key-Value 存储（Key-Value Stores）
键值存储是文档存储家族的表亲，但它们的血统来自亚马逊的Dynamo数据库。 它们的作用就像大型的分布式哈希图数据结构，可通过键存储和检索不透明值。
如图A-3所示，哈希图的密钥空间分布在网络上的多个存储桶中。 出于容错原因，每个存储桶都复制到多台计算机上。 R = 2F +1给出了所需副本数的公式，其中F是我们可以容忍的故障数。 复制算法旨在确保计算机不是彼此完全相同的副本。 这允许系统在机器及其存储桶恢复时进行负载平衡。 它还有助于避免热点，因为热点可能导致疏忽的自我拒绝服务。
从客户的角度来看，键值存储易于使用。 客户端通过散列特定于域的标识符（键）来存储数据元素。 哈希函数经过精心设计，可以在可用存储区之间提供均匀的分布，从而确保没有一台计算机成为热点。 给定哈希键，客户端可以使用该地址将值存储在相应的存储桶中。 客户使用类似的过程来检索存储的值。
一致的散列（Consistent Hashing）
所有计算机系统都会发生故障。 在可靠的系统中，这些故障通过为故障组件接通冗余替代件来掩盖。 在键值存储中（与任何分布式数据库一样），在正常运行期间，随着网络中断或硬件出现故障，个别计算机可能变得不可用。 只要从此类故障中恢复过来的副作用不会引起进一步的问题，就可以认为此类事件是正常的。 例如，如果支持特定哈希范围的计算机发生故障，则在进行内部重组时，不应阻止该范围内的新值被存储或导致不可用。
这就是一致性哈希起作用的地方。 使用此技术，可以将对失败的哈希范围的写入廉价地重新映射到下一台可用的计算机，而不会干扰整个存储的数据集。 实际上，在许多情况下，仅需要重新映射失败范围内的一部分键，而不是整个键。 当故障机器恢复或更换后，一致的哈希再次确保仅重新映射总密钥空间的一小部分。
给定这种模型，希望将数据存储在键值存储中或从中获取数据的应用程序仅需要知道（或计算）相应的键。 尽管密钥集中有很多可能的密钥，但实际上，密钥往往会很自然地从应用程序领域掉出来。 用户名和电子邮件地址，兴趣点的笛卡尔座标，社会保险号和邮政编码都是各个域的自然键。 使用合理设计的系统，由于缺少密钥而导致存储中的数据丢失的可能性很小。
键值数据模型类似于文档数据模型。 它们与众不同之处在于它们对数据的洞察力。
从理论上讲，键值存储会忽略其值中包含的信息。 纯粹的键值存储只是关心代表应用程序有效地存储和检索不透明数据，而不受其性质和应用程序使用的限制。
不透明度和对结构化数据内部子元素的访问
不透明度有一个缺点。 从存储的值中提取数据元素时，客户端通常必须检索整个值，然后过滤掉不需要的父级或同级数据元素。 与在服务器上执行此类操作的文档存储相比，这可能效率较低。
实际上，这种区分并不总是那么清晰。 一些流行的键值存储（例如Riak）还提供对某些类型的结构化存储数据（如XML和JSON）的可见性。 它还支持某些核心数据类型（称为CRDT），即使在存在并发写入的情况下也可以放心地合并它们。 在产品级别上，文档和键值存储之间存在一些重叠。
尽管键值模型很简单，但与文档模型一样，它对应用程序开发人员的数据洞察也很少。 为了从各个记录中检索有用的信息集，我们通常使用外部处理基础结构，例如MapReduce。 与在数据存储区中执行查询相比，这是高度潜在的。
键值存储提供某些运营和规模优势。 它们来自Amazon的Dynamo数据库（一个专为不间断购物车服务设计的平台），因此往往针对高可用性和可扩展性进行了优化。 或者，就像亚马逊团队所说的那样，即使“如果磁盘出现故障，网络路由震荡或数据中心被龙卷风破坏，它们也应该工作”。
6.列族（Column Family）
列族存储以Google的BigTable为模型。 数据模型基于人口稀少的表，该表的行可以包含任意列，为其提供自然索引的键。
在我们的讨论中，我们将使用Apache Cassandra的术语。Cassandra不一定是BigTable的忠实解释，但它已经得到广泛部署，并且其术语已广为人知。
在图A-4中，我们看到了列族数据库中使用的四个常见构建基块。 最简单的存储单元是列本身，由名称/值对组成。 可以将任意数量的列组合为一个超级列，该超级列为一组排序的列命名。 列存储在行中，当行仅包含列时，称为列族。 当一行包含超级列时，它被称为超级列族。
当数据模型表面上是列状时，专注于行可能看起来很奇怪，但是单个行很重要，因为它们提供了嵌套的哈希映射结构，我们可以将数据进行非规范化。 在图A-5中，我们展示了如何将唱片艺术家和他的专辑映射到一个超级列族结构中-从逻辑上讲，这实际上只是地图。
在列族数据库中，表中的每一行代表一个特定的总体实体（例如，关于艺术家的所有内容）。 这些栏目族是包含相关数据（例如艺术家的姓名和唱片目录）的容器。 在列族中，我们可以找到实际的键值数据，例如专辑发行日期和艺术家的出生日期。
有用的是，可以将此面向行的视图旋转90度，以达到面向列的视图。 每行给出一个实体的完整视图时，列视图自然会在整个数据集中索引特定方面。 例如，如图A-6所示，通过“排队”键，我们可以找到艺术家为英语的所有行。 从那里很容易从每一行中提取完整的艺术家数据。 它不是我们在图中发现的关联数据，但至少可以提供对一组相关实体的深入了解。
列族数据库与文档和键值存储区的区别不仅在于其更具表现力的数据模型，还在于其操作特性。 例如，Apache Cassandra基于类似于Dynamo的基础架构，其设计旨在进行分发，扩展和故障转移。 在幕后，它使用了多个存储引擎来处理较高的写入负载，这是由流行的交互式电视节目产生的峰值写入负载。
总体而言，列族数据库具有合理的表达能力，并且在操作上非常称职。 但是，它们仍然像文档和键值数据库一样是聚合存储，因此仍然缺少联接。 查询它们以深入了解数据需要一些外部应用程序基础结构进行处理。
7.汇总存储中的查询与处理
在前面的部分中，我们重点介绍了文档，键值和列族数据模型之间的异同。 总而言之，相似之处大于差异之处。 实际上，相似性是如此之大，有时将这三种类型统称为集合存储。 聚合存储持久保存独立的复杂记录，这些记录反映了聚合的域驱动设计概念。
尽管每个聚合存储都有不同的存储策略，但是在查询数据时，它们都有很多共同点。 对于简单的即席查询，每个查询都倾向于提供诸如索引，简单的文档链接或查询语言之类的功能。 对于更复杂的查询，应用程序通常先从商店中识别并提取数据的子集，然后再通过一些外部处理基础结构（如MapReduce框架）将其进行管道传输。 当无法简单地通过检查单个集合来生成必要的深入洞察力时，执行此操作。
像BigTable一样，MapReduce是Google提供的另一项技术。 MapReduce上最流行的开源实现是Apache Hadoop及其附带的生态系统。
MapReduce是一个并行编程模型，可对数据进行拆分并对其进行并行操作，然后再将其收集回并汇总以提供重点信息。 例如，如果我们想用它来计算唱片艺术家数据库中有多少美国艺术家，那么我们将提取所有艺术家记录并在地图阶段丢弃非美国艺术家，然后计算剩余记录 在还原阶段。
即使有很多机器和快速的网络基础结构，MapReduce也会具有很大的潜能。 通常，我们会使用数据存储区的功能来提供更集中的数据集（也许使用索引或其他临时查询），然后MapReduce较小的数据集来得出答案。
聚合存储库不是为处理高度关联的数据而构建的。 我们可以尝试将它们用于此目的，但是我们必须添加代码来填充基础数据模型遗留的地方，从而导致开发经验远非无缝的，并且操作特性通常不是很快，特别是随着跳数（或查询的“度”）增加。 聚合存储可能擅长存储大数据，但不适用于处理需要了解事物之间如何连接的问题。
8.图数据库
图形数据库是具有创建，读取，更新和删除（CRUD）方法的在线可操作数据库管理系统，可公开图形数据模型。 图形数据库通常是为与事务（OLTP）系统一起使用而构建的。 因此，它们通常针对事务性能进行优化，并且在设计时要考虑事务的完整性和操作可用性。
在研究图形数据库技术时，图形数据库的两个属性对于理解很有帮助：
- 基础存储
- 一些图形数据库使用本机图形存储，该存储是针对存储和管理图形进行优化和设计的。 但是，并非所有的图形数据库技术都使用本机图形存储。 一些将图形数据序列化为关系数据库，面向对象的数据库或其他类型的NOSQL存储。
- 处理引擎
- 图形数据库的某些定义要求它们能够无索引邻接，这意味着连接的节点在数据库中在物理上彼此“指向”。 在这里，我们有一个更广泛的看法。 从用户的角度来看，任何行为类似于图形数据库（即通过CRUD操作公开图形数据模型）的数据库都属于图形数据库。 但是，我们确实认识到无索引邻接在性能方面的显着优势，因此在引用利用无索引邻接的图数据库时使用术语本机图处理。
图形数据库（尤其是本机数据库）在很大程度上不依赖索引，因为图形本身提供了自然的邻接索引。 在本机图形数据库中，附加到节点的关系自然会提供与其他相关感兴趣节点的直接连接。 图查询使用该局部性通过追逐指针来遍历图。 与通过全局索引连接数据相比，这种操作效率极高，每秒可遍历数百万个节点，而全局索引的速度要慢许多个数量级。
除了采用特定的存储和处理方法之外，图形数据库还将采用特定的数据模型。 常见用法有几种不同的图数据模型，包括属性图，超图和三元组。 我们在下面讨论每种模型。
8.1.属性图（Property Graphs）
属性图具有以下特征：
- 它包含节点和关系。
- 节点包含属性（键值对）。
- 节点可以用一个或多个标签标记。
- 关系是命名和定向的，并且始终具有起点和终点。
- 关系也可以包含属性。
8.2.超图（Hypergraphs）
超图是一种通用图模型，其中关系（称为超边）可以连接任意数量的节点。 属性图模型允许一个关系只有一个开始节点和一个结束节点，而超图模型则允许在关系的任一端有任意数量的节点。 当域主要由多对多关系组成时，超图很有用。 例如，在图A-7中，我们看到爱丽丝和鲍勃是三辆车的所有者。 我们使用单个超边来表达，而在属性图中我们将使用六个关系。
正如我们在第3章中讨论的那样，图形使我们能够以易于可视化和理解的方式对问题域进行建模，并以高保真度捕获现实世界中遇到的数据的许多细微差别。 尽管从理论上说，超图可以生成准确的，信息丰富的模型，但实际上，在建模时我们很容易错过一些细节。 为了说明这一点，让我们考虑图A-8中所示的图，它是与图A-7中所示的超图等效的属性图。
此处显示的属性图需要几个OWNS关系来表达仅用一个就捕获的超图。 但是，在使用多种关系时，我们不仅可以使用一种熟悉且非常明确的建模技术，而且还可以对模型进行微调。 例如，我们通过在相关关系中添加属性来确定每种车辆的“主要驾驶员”（出于保险目的），而这是单条超边缘无法实现的。
因为超边缘是多维的，所以超图比属性图包含更通用的模型。 也就是说，这两个模型是同构的。 始终可以将超图中的信息表示为属性图（尽管使用更多的关系和中间节点）。 超级图或属性图最适合您将取决于您的建模思想和所构建的应用程序类型。 有趣的是，在大多数情况下，属性图被广泛认为具有实用性和建模效率的最佳平衡，因此它们在图数据库领域非常受欢迎。 但是，在需要捕获元意图，有效地限定一种关系与另一种关系的情况下（例如，我喜欢您喜欢那辆车的事实），与属性图相比，超图通常需要更少的图元。
8.3.三元组（Triples）
三重存储来自语义Web运动，研究人员通过将语义标记添加到连接Web资源的链接中，对大规模知识推理感兴趣。 迄今为止，很少有Web以有用的方式进行标记，因此在语义层上运行查询并不常见。 取而代之的是，语义Web上的大部分工作似乎都花在了从Web（或其他更平凡的数据源，例如应用程序）中收集有用的数据和关系信息，并将其存储在三重存储中以进行查询。
三元组是主语-谓语-宾语数据结构。 使用三元组，我们可以捕获事实，例如“姜与弗雷德共舞”和“弗雷德喜欢冰淇淋”。单独地，三元组在语义上相当差，但是在大量处理中，它们提供了丰富的数据集，可以从中收集知识并推断出联系。 。 三重存储通常提供SPARQL功能来推理和存储RDF数据。
RDF（三元商店的通用语言和语义网）可以几种方式进行序列化。 下面的代码片段显示了如何使用RDF / XML格式将三元组组合在一起以形成链接数据：
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://www.example.org/terms/">
<rdf:Description rdf:about="http://www.example.org/ginger">
<name>Ginger Rogers</name>
<occupation>dancer</occupation>
<partner rdf:resource="http://www.example.org/fred"/>
</rdf:Description>
<rdf:Description rdf:about="http://www.example.org/fred">
<name>Fred Astaire</name>
<occupation>dancer</occupation>
<likes rdf:resource="http://www.example.org/ice-cream"/>
</rdf:Description>
</rdf:RDF>
W3C Support
三重存储的实现方式有所不同。 商店不必具有类似于三元组的内部实现即可生成三元组的逻辑表示。 但是，大多数三重存储由于对语义Web技术（如RDF和SPARQL）的支持而统一。
尽管RDF没有什么特别的作为序列化链接数据的方法，但是它已得到W3C的认可，因此可以从被广泛理解和充分记录中受益。 查询语言SPARQL受益于类似的W3C支持。
在图数据库空间中，围绕图序列化格式（例如GEOFF）和推理查询语言（例如我们在本书中使用的Cypher查询语言）也有大量类似的创新。 关键区别在于，尽管这些创新确实得益于用户和供应商社区的大力参与，但它们在这一点上并没有得到像W3C这样受人尊敬的机构的支持。
三重存储属于图数据库的一般类别，因为它们处理的数据（一旦处理）往往被逻辑链接。 但是，它们不是“本机”图数据库，因为它们不支持无索引的邻接关系，并且它们的存储引擎也未针对存储属性图进行优化。 三元组存储将三元组存储为独立的工件，这使它们可以水平扩展以进行存储，但可以阻止它们快速遍历关系。 要执行图查询，三元组存储必须根据独立事实创建连接的结构，这会增加每个查询的延迟。 由于这些原因，三重存储的最佳选择是分析，其中延迟是次要考虑因素，而不是OLTP（响应性在线事务处理系统）。
尽管图数据库主要是为遍历性能和执行图算法而设计的，但可以将它们用作RDF / SPARQL端点后面的后备存储。 例如，Blueprints SAIL API提供了到包括Neo4j在内的几个图形数据库的RDF接口。 在实践中，这意味着图形数据库和三元组存储之间的功能同构水平。 但是，每种商店类型都适用于不同类型的工作负载，其中图数据库针对图工作负载和快速遍历进行了优化。