快速回顾：NoSQL矩阵
NoSQL数据库的宏观世界是多种多样的，其中图形数据库只是其中的一部分。上周，我们浏览了下面矩阵的三个蓝色象限，这些象限统称为聚合商店，包括键值，宽列（或列族）和文档库。
本周，我们将双击同样多样化的图形技术世界，它占据了下面矩阵中的绿色象限。
NoSQL数据库的矩阵。蓝色象限统称为聚合商店。
图数据库技术的谱
我们已在第一篇文章中逐步介绍了图形数据库的正式定义，但让我们快速回顾一下。
图形数据库是一种在线操作数据库管理系统，能够在图形数据模型上运行创建，读取，更新和删除（CRUD）过程。
图数据库技术有两个重要属性：
图存储
- 本机 图形存储专门用于存储和管理图形，而其他图形存储使用通常较慢的关系或面向对象的数据库（由于数据模型不匹配）。
图形处理引擎
原生图处理（即无索引邻接）是在图中处理数据的最有效方法，因为连接的节点在数据库中物理地“指向”彼此。非本机图处理引擎使用其他方法来处理CRUD操作。
除了存储和处理的细节外，图形数据库还采用了不同的数据模型。最常见的图形数据模型包括属性图，超图和RDF三元组。
让我们深入了解下面的每一个。
属性图
属性图是我们已经讨论过的图数据库的类型。实际上，我们对图数据库的原始定义更准确地说是属性图（如下图所示）。
以下是对数据模型属性图的简要概述：
属性图包含节点（数据实体）和关系（数据连接）。
节点可以包含属性（即键值对）。
节点可以用一个或多个标签标记。
关系有名称和方向。
关系始终具有起始节点和结束节点。
与节点一样，关系也可以包含属性。
Neo4j是一个属性图数据库。
超图
超图是一种图形数据模型，其中关系（称为超边缘）可以连接任意数量的给定节点。虽然属性图允许关系只有一个起始节点和一个结束节点，但超图模型允许在关系的任何一端有任意数量的节点。
当您的数据包含大量多对多关系时，超图可能很有用。
我们来看下面的例子。
在这个简单的（定向）超图中，我们看到Alice和Bob是三辆车的拥有者，但是我们可以使用一个超级表达来表达这种关系。在属性图中，我们必须使用六种关系来表达概念。
理论上，超图应该产生准确的，信息丰富的数据模型。然而，在实践中，我们很容易在建模时遗漏一些细节。例如，让我们看一下下图，它是上面显示的超图的等价的属性图。
此属性图模型需要多个OWNS关系来表示超图仅使用一个超边点捕获的内容。然而，通过使用六种关系而不是一种关系，我们有两个明显的优势：
首先，我们使用更熟悉和明确的数据建模技术（减少了开发团队的混淆）。
其次，我们还可以使用诸如“主要驱动程序”（用于保险目的）等属性对模型进行微调，这是我们无法对单个超边缘进行的操作。
因为超边界是多维的，超图模型比属性图更加通用。然而，这两者是同构的，所以你总是可以将超图表示为属性图（虽然有更多的关系和节点） - 而你却不能反过来。
虽然属性图被广泛认为具有实用性和建模效率的最佳平衡，但超图显示了它们在捕获元意图方面的特殊优势。例如，如果你需要与另一个关系限定一个关系（例如，我喜欢你喜欢那辆车的事实。哇，那么元。），那么超图通常比属性图需要更少的基元。
超图或属性图是否最适合您取决于您的建模思维方式以及您正在构建的应用程序类型。
三重商店
三重存储来自语义Web运动，并以称为三元组的格式存储数据。三元组由主题 - 谓词 - 对象数据结构组成。
使用三元组，我们可以捕捉诸如“与弗雷德的姜舞”和“弗雷德喜欢冰淇淋”等事实。单独地，单个三元组在语义上不是非常有用，但是它们是集体的，它们提供了丰富的数据集，从中可以收集知识并推断出连接。
三重存储是围绕W3C规定的资源描述框架（RDF）规范建模的，使用SPARQL（发音为“sparkle”）作为它们的查询语言。
RDF三元组数据模型的示例
由三元组商店处理的数据往往是逻辑链接的，因此三元组商店包含在图形数据库的类别中。但是，三重存储不是本机图形数据库，因为它们不支持无索引邻接，它们的存储引擎也不是为存储属性图而优化的。
三重存储将三元组存储为独立元素，这允许它们水平缩放但阻止它们快速遍历关系。为了执行图形查询，三元组存储必须从单独的独立事实创建连接 - 为每个查询添加延迟。
由于在规模和延迟方面的这些权衡，三重存储的最常见用例是离线分析而不是在线交易。
阅读本文，了解有关RDF三重存储和标记属性图数据库之间差异的更多信息。
结论
Euler会很自豪地看到我们用他的图论气球动物做了什么（“那里，那里，小家伙，非常可爱。”）。那是因为有很多不同的图形技术 - 我们甚至没有进行图形分析或图形可视化！
就像我们上周看到的聚合商店一样，每种类型的图数据库技术都最适合不同的功能。超图非常适合捕获元意图，而RDF三重存储非常适合离线分析。但对于在线，事务处理没有什么比快速遍历数据连接的属性图更好。