【微云数聚整理】 【翻译自：https://neo4j.com/blog/other-graph-database-technologies/】 【由Neo4j APAC授权编译发布】

过去的日子里，普鲁士的哥尼斯堡一定是个相当无趣的地方。 因为在哥尼斯堡，人们的消遣活动就是绕着城市的七座桥散步，找到一条不重复经过每座桥，最后回到出发点的路（在 Netflix 出现之前）。 这个问题似乎不难解决，但是哥尼斯堡居民并不擅长数学。于是人们便求教他们的数学家“朋友” 萊昂哈德-欧拉。欧拉当时正忙于许多其他事情，包括数论和微积分，于是他发明了一个新的数学分支来解决哥尼斯堡居民提出的问题。 故事寓意是：迄今为止，我们本可以了解整个宇宙的基本性质（并在火星上写下这一篇文章），可事实恰恰相反，我们只能求教欧拉开创一种新的数学分支，就像一个恼人的孩子向他们的叔叔要动物气球一样。 这就是我们谈论的欧拉：即他的动物气球给了我们关于现实世界的复杂内在规律的洞察，这个独特的动物气球就是图论。 即使在280年后，图论仍然在推动全球最具创新性的技术：图数据库技术。 因为图数据库基于数学和计算机科学范式转移的领域，图技术发展迅速。无论你是图领域的新人，还是老手，现在都是时候研究一下该技术了。 在图数据库入门系列文章中，假设您对图数据库了解很少，我将带您了解图技术的基础知识。在过去的几周里，我们讨论了为什么图技术是未来、为什么连接数据很重要、数据建模的基础（和陷阱）、为什么数据库查询语言很重要、命令式和声明式查询语言之间的差异、基于图论的预测建、图搜索算法的基础，以及为什么我们需要NoSQL数据库。 本周，我们将关注图数据库技术及其在 NoSQL 数据库中的应用。

1. 快速回顾：NoSQL矩阵 NoSQL 数据库种类繁多，图数据库只是其中的一部分。上周，我们学习了下面矩阵的三个蓝色象限，它们统称为聚合存储，包括键值对、列（或列族）和文档存储。 本周，我们针对下面矩阵绿色象限的图技术领域，继续做深入探讨。 NoSQL数据库矩阵，蓝色象限统称为聚合存储区。

2. 图数据库技术 在之前文章中讨论了图数据库的定义，现在让我们快速回顾一下。 图数据库是一个在线、可操作的数据库管理系统，能够对图数据模型进行创建、读取、更新和删除（CRUD）操作。 图数据库技术有两个重要特性：

   • 图存储 有些图数据库使用原生图存储来存储和管理图，而另一些则使用关系数据库或面向对象的数据库，这类数据库通常性能较低（因为数据模型不匹配）。
   • 图处理引擎 原生图处理（即免索引邻接）是处理图数据的最有效方法，图中连接的节点在数据库存储时物理“指向”彼此，而非原生图处理引擎使用其他方式处理 CRUD 操作。 除了存储和处理方面的差异，图数据库还采用了不同的数据模型。最常用的图数据模型包括属性图（Property Graphs）、超图（Hypergraphs）和 RDF 三元组（RDF Triples）。 下面深入讨论每种模型。

2.1属性图 属性图是我们讨论最多的图数据库模型。事实上，我们对图数据库的最初定义更精确地描述了属性图（如下图所示）。 符合下列特征的数据模型就被称为属性图： * 属性图包含节点（数据实体）和关系（数据连接）。 * 节点可以有属性（键值对）。 * 节点可以有一个或多个标签。 * 关系有名称和方向。 * 关系总是有一个开始节点和一个结束节点。 * 与节点一样，关系也可以有属性。 Neo4j 是一个属性图数据库。

2.2超图 超图也是一种图数据模型，一个关系（称为超边）可以关联任意数量的节点。属性图中一个关系只允许有一个开始节点和一个结束节点，超图模型则允许关系的开始节点端或者结束节点端有任意数量的节点。 超图更适用表示多对多关系。 让我们看看下面的例子。 在这个简单的（指向的）超图中，我们看到 Alice 和 Bob 共同拥有三辆车，只需一条超边（OWNS）就能表示这种关系。在属性图中，则需要使用六条关系来表示。 理论上，超图应该能够生成准确的、信息丰富的数据模型。然而现实中，建模时很容易遗漏一些细节。来看下图，它是与上面所示超图相同的属性图。 超图中只需要一条超边（OWNS）就能表示出来，属性图模型则需要多条拥有（OWNS）关系来表示。相比较超图的一条关系，通过使用六条关系，有两个显著优势： * 首先，我们使用了更为清晰明确的数据建模技术（减少开发团队的混乱）。 * 其次，我们可以使用诸如“主要驾驶人”之类的属性对模型进行微调(例如在保险中)，而使用一条超边却无法精确描述。 超边是多维的，超图模型是一种更广义的图模型，比属性图更通用。两者是同构的，给定一个超图，我们可以将其表示为一个属性图（有更多的关系和节点），反之则不行。 属性图被广泛认为很好地兼顾了实用和建模效率，超图则在捕获元意图方面凸显其独特优势。例如，如果您需要确定一种关系（例如，我尊重您喜爱那辆车的事实），那么超图通常比属性图更简洁明了。 至于超图或者属性图谁更适合，取决于正在构建应用的建模和类型。

2.3三元组 三元组思想来源于语义网（the Semantic Web），并以我们熟知的三元组结构存储数据。三元组由包含主谓宾的数据结构组成。 使用三元组，我们可以分析诸如“Ginger dances with Fred.”和“Fred likes ice cream.”的语句。显然，单个三元组的语义比较有限，但总的来说，其提供了一个丰富的数据集，方便进行知识推理和数据关联。 三元组存储需要借助W3C制定的资源描述框架（RDF）建模，使用SPARQL（Sparkle）作为查询语言。 RDF三元组数据存储模型示例 三元组数据存储通常是逻辑关联，三元组存储也包含在图数据库分类中。三元组存储并不是原生图数据库，其不支持免索引邻接，存储引擎也没有对属性图存储做优化。 三元组存储时将三元组元素分别储存，允许水平扩展，但快速遍历关系性能不佳。执行图查询时，需要把单独存储的元素创建连接——增加了查询的时间消耗。 由于在伸缩性和延迟上的折衷，三元组最常见的场景是离线分析，并不适用于实时在线交易。 有关 RDF 三元组和属性图数据库之间区别的更多信息，请阅读本文（https://neo4j.com/blog/rdf-triple-store-vs-labeled-property-graph-difference/?ref=blog）。

1. 总结

   相信欧拉一定会非常自豪，我们能应用他的动物气球（图论）做更多事情（“那里，那里，小家伙，它很可爱。”）。还有很多不同的图技术等待我们去挖掘——例如图分析或图形可视化！ 就像我们上周讨论的聚合存储，每种的图数据库技术都有不同的应用场景。超图非常适合元意图和 RDF 三元组的离线分析。对于在线应用场景，属性图在实时遍历数据关联关系时体现出了无以伦比的优势。

更多技术咨询： 联系人：于松林  电话：13910069835 Email：yusonglin@we-yun.com 微信号：ysllong_0226 微云数聚网址：www.we-yun.com