使用图数据库的一般注意事项

1.4 使用图数据库的一般注意事项

看到这里，相信大家应该对图数据库是什么以及与其他数据库管理系统和模型的关系有了很好的了解。本系列后续大部分内容将详细介绍 Neo4j ，它是图数据库管理系统的一一个实现。 在此之前，有必要与软件专业人员（开发人员、架构师、项目产品经理以及 IT 主管等）探讨一下为什么要使用图数据库。

事实上，在一些场景下，关系数据库与图数据库均适用，但还有许多其他类数据问题，关系数据库并不是专门为此设计的。接下来探讨哪些数据特性和查询模式适合图数据库。

1.4.1 为什么使用图数据库

当试图解决下列问题时，可以考虑使用 Neo4j 这样的图数据库。

1.复杂查询

复杂查询本质上包含大量的复杂连接操作（joinoperations）。数据库管理员都知道，这些连接操作在关系数据库中是非常耗时的，需要做笛卡儿乘积运算，两三个表之间的一两个连接操作还能正常运行，随表的数量呈指数增长，即便是小数据集也可能构成一个无法解决的问题，这就是为什么复杂查询成为问题的原因。

举一个复杂查询的例子，在一个伦敦社区里找出周日开放、为孩子们服务、提供印度餐的所有餐馆。从关系数据库的角度，这意味着要关联餐馆表（restaurant table）、食物类型表（food type table）、开放时间表（opening hours table）、服务对象类型表（caters table）和伦敦社区邮政编码表（zip-code table） 后，才能给出查询结果。毫无疑问，还有很多其他的例子需要做类似的复杂查询，这只是一个假设。

在图数据库，连接操作将不复存在：需要做的是在图数据库中通过索引查找到一个起始节点（例如，London, 伦敦），然后使用免索引邻接特性，从一个节点（ London , 伦敦）跳到下一个关联的节点（ Restaurant ，餐厅），其操作为：Restaurant -[LOCATED_ IN]→London。事实上，查询路径的每一跳都相当于一个连接操作。因此，图数据库中节点之间的关系也可以看作是关系数据库中连接操作的显式存储方式。

通常将这类查询称为模式匹配查询。指定一个模式（如下图所示：蓝色与橙色连接，橙色与绿色连接，蓝色与绿色连接），并将该模式锁定在一个或多个起点上，就可以查找出与该模式相匹配的节点。如你所见，图数据库将是一个很好的工具，可以围绕锁定的节点快速确定是否有匹配的模式。不匹配的模式将被忽略，不与开始节点关联的也不予考虑。

这实际上是图数据库性能提升的关键特性：一旦设定了一个起始节点，数据库将只在该起始节点关联的附近进行搜索，不相连的将完全忽略。这点表明：查询的性能与数据集大小无关，因为在大多数图中，并不是全关联的。同样，稍后将看到的，性能更多地依赖于结果集的大小，这也是在构建持久化体系结构时要牢记的关键点。

2.实时数据的点击流查询

众所周知，如前面的示例，可以在不同的数据库管理系统中实现不同的数据查询。然而，大多数查询在实时数据系统中的性能很糟糕，很可能影响整个应用系统的响应能力。因此，关系数据库采用特定的数据结构，并进行数据的预处理和预格式化。

这意味着在业务智能系统中经常需要数据去重、数据非规范化，以及使用ETL等技术（提取、转换和加载），以便对手头的数据创建特定查询的表示（有时也称为数据仓库中的立方体， cubes ）。显然，商业智能行业价值不止 10 亿美元，这些技术都很有价值，但最适合于处理静态、很少更新的数据。图数据库能快速处理更多种类的复杂查询，数据可以是重复的或近实时的更新。

3.路径查询

另一种非常适合于图数据库的查询类型是，查找不同数据元素之间是如何相互关联的。换句话说，就是在图中不同节点之间查找路径。在其他数据库管理系统中，这类查询问题需要清楚地了解可能路径的结构，也就是说，必须告诉数据库如何从一个表跳到另一个表。而在图数据库中，通常不需要这样做，虽然还可以采用上述方法，只需告诉数据库采用何种图算法、起始节点和终止节点，系统就将自动完成查询。图数据库自行判定数据是否连接以及如何连接，并采用路径表达式返回结果。事实上，将这些事情交给图数据库去处理是非常有用的，而且常常会带来意想不到、有价值的结果。

显然，上面提到的仅是查询类别，必须结合前面讨论的研究领域才能真正获得益处。在后续章节将作详细介绍。

1.4.2 什么时候不用图数据库以及用什么代替

正如之前所讨论的， NoSQL 数据库分类的核心都是以任务为导向。不同的任务选用与之相适应的工具。因此，这也意味着有些场景，图数据库并不完全适合。这难以得到图数据库粉丝的认可，但如果声称图数据库是万能的，这是愚蠢、不诚实的做法，自然不可信。有必要介绍哪几类操作不适合 Neo4j 之类的图数据库。

下列操作不推荐使用，或至少不是单独使用 Neo4j 这样的图数据库。

1.大集合查询

如果回想一下之前讨论过的问题，并考虑图数据库是如何在复杂查询中获得性能优势的，就能立即发现，在许多情况下图数据库虽然可以正常运行，但效率不高。如果只是有效获取大量数据，不需要大量的连接操作或聚合运算（求和、计数、取平均值等），那么在性能上与其他数据库管理系统相比图数据库并没有优势。显然，图数据库也能执行上述操作，但性能优势很小，甚至可能是负面的。例如，面向集合的数据库，关系数据库在性能上则更高。

2.图的全局操作

如前所述，图论从宏观上对图的分析和理解做了很多有意义的工作。查找节点集群、发现节点间未知的关系模式、确定特定图的中心等都是非常有趣的问题，但是与图数据库所擅长的还是差异较大。上述问题是从全局上去研究图，称其为图的全局操作。虽然图数据库在回答局部问题时非常强大，但另一类图工具(通常称为图处理引擎或图计算引擎)更适合求解图的全局问题。

为完成这类全局性任务，这些工具通常是专用的，甚至使用特定的软硬件设备（常采用大内存、高性能 CPU ），这也是另一种不同的 IT 架构。图处理通常是在后台分批进行，时间可能是几个小时、几天甚至几周，一般不用于基于 Web 的应用。这是一种完全不同的图操作类型。

3.简单聚合查询

我们提到，图及图数据库管理系统非常适合复杂查询，而关系数据库不擅长。因此，在简单查询中，读写聚合数据通常用图处理非常低效，更适合采用面向聚合操作的键值存储或文档存储。如果复杂性较低，则使用图数据库系统的优势也会较低。

希望以上这些能让你更好地了解图数据库的优缺点。