图数据库创造之初的目的非常单纯,就是通过(深度)挖掘不同来源的数据,以网络化分析(network analytics)的方式来攫取数据关联中所蕴藏的巨大价值。关系型数据库的数据存储是以表来聚类(同类)数据,并将这些实体聚合在同一张表中,不同表中存放不同类型的实体。当需要进行实体关联的时候就需要多张表之间进行连接。而关系型数据库的设计理念和数据结构的限制导致当进行表连接(table join)操作的时候,尤其当表的内容很多的时候,操作的耗时会较单表操作呈指数级上升,甚至在多表关联的时候,因耗时过长、系统资源消耗过多而导致系统崩溃或无法返回。
举个经典的例子:员工、部门与公司,在关系型数据库中会用三个表来存储这些不同类型的实体,如果想要查找哪些员工在哪家公司的哪个部门工作,就需要动用三个表相互连接来实现——这个过程不但效率低下,而且非常不直观。如图1-21a所示,从员工表中查到员工属于哪个部门,再从部门表中查到每个部门隶属于哪家公司,最终再从公司表中查出每个公司ID所对应的公司的全部信息(名称、地址、网站等)。也许,你会说可以把所有信息都压缩在一个表内,但这么做的代价是制作一个巨大的表,里面有无数的冗余信息,而且这种设计理念与关系型数据库的规范化(归一化,normalization)原则是相背离的,在后面的章节中我们会深入谈及这个话题。
而在图上,因为它天然地是用来表达关联关系的,这个查询就是一个典型的图内深度为2的路径查询(见图1-21b)。把这个思路泛化到有大量业务部门和员工的表结构上,图计算与查询的效率会成千上万倍地高于基于SQL的关系型数据库查询。
图1-21 图数据库可实现迅捷的数据关联价值抽取 a)员工、部门与公司表 b)深度为2的路径查询