网盘下载地址：https://u18103887.ctfile.com/fs/18103887-311624004
1.1 为什么要有Neo4j
为什么要使用图形数据库呢？或者更具体地说，Neo4j是你的数据库的
正确选择吗？正如前面所提到的，对于人们试图使用逻辑的方法，并用类似
于图形的结构和概念对他们特殊问题的领域进行建模和描述那是很自然的，
尽管他们最终可能并不是以图型数据库存储数据。选择正确的数据库（或者
是在存储领域中已有的多种语言版本的数据库中选择多种数据库）存储数据
可以使应用程序的运行速度大大加快，正像如果选错了数据库就会使程序完
全崩溃一样。
对于这个问题可以使用一个例子来做出很好说明。取一个非常适合于用
图形数据库解决的问题，看看怎样应用Neo4j解决，并与使用另一个不同数
据库的存储做出对比。为了便于比较，我们将使用传统的关系数据库作为比
较对象，因为这是在一般情况下大多数人涉及的存储对比的选择。更重要的
是，这也是大多数人在目前，也可能以后仍然会在解决问题时选择的关系数
据库模型。
我们要探讨的例子是一个社交网络，一组可能相互之间是朋友的用户。
图1-1显示了该社交网络，用箭头连接的用户之间是朋友关系。
注意
要使语义正确，朋友的关系应该是双向的。在Neo4j中，双向性是使用
两个关系建立的，以每一个关系建立一个方向（在Neo4j中，每个关系必须
要明确定义一个方向，但以后会定义多个方向）。因此，你应该会看到每对
朋友之间都有两个独立的朋友关系，在每个方向上有一个关系。为简单起
见，我们建立了单向直接的朋友关系。在第2章和第3章中你将会了解为什么
这种数据模型在Neo4j中实际上是非常高效的。
让我们来看看关系数据库如何存储用户及他们的朋友。
1.2 关系数据库中的图形数据
在关系数据库中，通常使用两个具有关系的表格存储社交网络的数据：
一个用于存储用户信息，而另一个用于存储用户之间的关系（参见图1-2）。
图1-1 以图形数据结构描述的用户与他们的朋友
图1-2 描述用户及其朋友数据的SQL图表
程序1-1显示了在MySQL数据库中用SQL脚本语言创建的表。
【程序1-1】 SQL脚本语言定义的社交网络数据表
表t_user包含着用户信息的列，而表t_user_friend只有两列，用外键关系
引用表t_user。主键和外键具有索引，以便进行快速查找操作。索引是关系
数据库中使用的典型查找技术。
使用MySQL查询图形数据
你会如何去查询一个关系数据库呢？获取一个特定用户的直接朋友数是
相当简单的。如下的基本select查询就可以实现这一目的：
注意
我们在所有的例子中计算所有的朋友数量，因此，不能通过加载实际的
数据而使CPU或内存超载。
如何找到一个用户的朋友的所有朋友？通常，在查询前，典型的做法是
将表t_user_friend与它自身联接起来。
流行的社交网络通常具有从你的具有一定分离度或深度的朋友圈推荐潜
在的朋友或联系人的功能。如果你想做某一些相似的事情以寻找某一个用户
的朋友的朋友的朋友，你仅仅需要另外的一个join操作。
同样，要做一个四层关系的循环，就需要四个join操作。要获得著名的
六度分离问题的所有连接，将需要6个join操作。
对于这种做法，没有什么不正常的，但是有一个潜在的问题：尽管你只
关心单一用户的朋友的朋友，但你必须对表t_user_friend中的所有数据做一
个join操作，然后丢弃你不再感兴趣的所有行。对于一个小的数据集，这将
不会是一个大的问题。但是，如果这个社交网络不断发展壮大，你可能开始
遇到一些严重的性能问题。正如你将看到的，这将会给关系型数据引擎带来
巨大的压力。
为了说明这种查询的性能，在一个具有1000个用户的小数据集上运行几
次朋友的朋友查询，并在每次调用和记录每次的查询结果的同时，增加搜索
的深度。在一个具有1000用户的小数据集中，平均每一个用户具有50个朋
友。表t_user包含了1000条记录，而表t_user_friend包含了1000×50=50000条
记录。
在每个深度上运行了10次查询，这仅仅是在任何情况下都能帮助提高性
能的一个开始，记录下在每一深度上的最快运行时间。除在程序1-1中用
SQL脚本语言对数据库的列定义索引外，不对数据库进行其他的性能调整。
表1-1给出了实验的结果。
表1-1 使用MySQL数据库引擎对一个有1000个用户的数据库使用多个join查
询的运行时间
注意
所有的实验均在Intel i7-CPU、8GB内存的商用笔记本电脑上完成，本书
的写作也是在这台笔记本电脑上完成的。
注意
在深度为3、4、5时均返回数值999，这是由于数据集太小，数据库中的
每一个用户都相互关联着。
正如你能够看到的，MySQL处理查询的深度为2和3时，其表现相当不
错。关系数据库的join操作并非不常见，而是很通常的操作。因此很多数据
库引擎都把这种操作作为默认的设计。使用数据库相关列上的索引也能帮助
关系数据库最大化其执行join查询操作的性能。
然而，在深度为4和5时，性能显著下降：涉及深度4的查询需要10秒以
上才能完成，而在深度5时，尽管计数结果没有改变，但执行的时间就更长
了，超过了一分半钟。这说明了当处理图形数据时MySQL所受到的限制：
深度图形需要多个join操作时，关系数据库通常表现得不太好。
SQL的join操作的低效率性
要在深度5查找一个用户的所有朋友，关系数据库引擎需要产生
t_user_friend表的笛卡儿积五次。对于一个拥有50000个记录的表，所得到的
数据集将有500005行（102.4×1021），这需要相当长的时间和计算能力来做
出这些计算。最后只返回了你感兴趣的不到1000条的记录，而放弃了超过
99%的计算结果！
正如你所看到的，关系数据库并不擅长多对多关系的数据模型，尤其是
在大型数据集时。而相反，Neo4j正好擅长多对多的关系，因此，让我们来
看看Neo4j是如何使用相同的数据集来实现的。不是使用表、列和外键，而
是通过将用户作为节点、朋友关系作为节点之间的关系来建立模型的。