相信您和我一样，在使用关系型数据库时常常会遇到一系列非常复杂的设计问题。例如一部电影中的各个演员常常有主角配角之分，还要有导演，特效等人员的参与。通常情况下这些人员常常都被抽象为Person类型，对应着同一个数据库表。同时一位导演本身也可以是其它电影或者电视剧的演员，更可能是歌手，甚至是某些影视公司的投资者(没错，我这个例子的确是以赵薇为模板的)。而这些影视公司则常常是一系列电影，电视剧的资方。这种彼此关联的关系常常会非常复杂，而且在两个实体之间常常同时存在着多个不同的关系：
在尝试使用关系型数据库对这些关系进行建模时，我们首先需要建立表示各种实体的一系列表：表示人的表，表示电影的表，表示电视剧的表，表示影视公司的表等等。这些表常常需要通过一系列关联表将它们关联起来：通过这些关联表来记录一个人到底参演过哪些电影，参演过哪些电视剧，唱过哪些歌，同时又是哪些公司的投资方。同时我们还需要创建一系列关联表来记录一部电影中哪些人是主角，哪些人是配角，哪个人是导演，哪些人是特效等。可以看到，我们需要大量的关联表来记录这一系列复杂的关系。在更多实体引入之后，我们将需要越来越多的关联表，从而使得基于关系型数据库的解决方案繁琐易错。
这一切的症结主要在于关系型数据库是以为实体建模这一基础理念设计的。该设计理念并没有提供对这些实体间关系的直接支持。在需要描述这些实体之间的关系时，我们常常需要创建一个关联表以记录这些数据之间的关联关系，而且这些关联表常常不用来记录除外键之外的其它数据。也就是说，这些关联表也仅仅是通过关系型数据库所已有的功能来模拟实体之间的关系。这种模拟导致了两个非常糟糕的结果：数据库需要通过关联表间接地维护实体间的关系，导致数据库的执行效能低下;同时关联表的数量急剧上升。
这种执行效能到底低下到什么程度呢?就以建立人和电影之间的投资关系为例。一个使用关联表的设计常常如下所示：
如果现在我们想要通过该关系找到一部电影的所有投资人，关系型数据库常常会执行哪些操作呢?首先，在关联表中执行一个Table Scan操作(假设没有得到索引支持)，以找到所有film域的值与目标电影id相匹配的记录。接下来，通过这些记录中的person域所记录的Person的主键值来从Person表中找到相应的记录。如果记录较少，那么这步就会使用Clustered Index Seek操作(假设是使用该运算符)。整个操作的时间复杂度将变为O(nlogn)：
可以看到，通过关联表组织的关系在运行时的性能并不是很好。如果我们所需要操作的数据集包含了非常多的关系，而且主要是在对这些关系进行操作，那么可以想象到关系数据库的性能将变得有多差。
除了性能之外，关联表数量的管理也是一个非常让人头疼的问题。刚刚我们仅仅是举了一个具有四个实体的例子：人，电影，电视剧，影视公司。现实生活中的例子可不是这么简单。在一些场景下，我们常常需要对更多的实体进行建模，从而完整地描述某一领域内的关联关系。这种关联关系所涵盖的可能包含影视公司的控股关系，各控股公司之间复杂的持股关系以及各公司之间的借贷款情况及担保关系等，更可能是人之间的关系，人与各个品牌之间的代言关系，各个品牌与所属公司之间的关系等。
可以看到，在需要描述大量关系时，传统的关系型数据库已经不堪重负。它所能承担的是较多实体但是实体间关系略显简单的情况。而对于这种实体间关系非常复杂，常常需要在关系之中记录数据，而且大部分对数据的操作都与关系有关的情况，原生支持了关系的图形数据库才是正确的选择。它不仅仅可以为我们带来运行性能的提升，更可以大大提高系统开发效率，减少维护成本。
于是，在搜索更好的方案时无意间发现了图形数据库，查阅一番资料后感觉确实是个不错的选择，毕竟业界的一些大佬，如twitter，Adobe等也在用。
那么，什么是图形数据库呢？在这里我贴上较为官方的定义：a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data – independent of the way the data is stored internally. It’s really the model and the implemented algorithms that matter.注意，这里只是说数据模型是图结构的，没有说数据的存储也一定要是图结构的。其数据模型如下图
进入今天的主题，我将以Neo4j为例，说明为什么选择图形数据库？
首先，先简要介绍一下Neo4j。Neo4j是由Java和Scala写成的一个NoSql数据库，专门用于网络图的存储。更详细的内容可见官网。作为一个图形数据库，Neo4j有以下优点：
- 更快的数据库操作。当然，有一个前提条件，那就是数据量较大，在MySql中存储的话需要许多表，并且表之间联系较多（即有不少的操作需要join表）。
- 数据更直观，相应的SQL语句也更好写（Neo4j使用Cypher语言，与传统SQL有很大不同）。
- 更灵活。不管有什么新的数据需要存储，都是一律的节点和边，只需要考虑节点属性和边属性。而MySql中即意味着新的表，还要考虑和其他表的关系。
- 数据库操作的速度并不会随着数据库的增大有明显的降低。这得益于Neo4j特殊的数据存储结构和专门优化的图算法。
接着，试着从更深一些的层次看图形数据库。我将从Neo4j的数据存储和数据读写两方面来说明为什么选它。
-
数据存储
Neo4j对于图的存储自然是经过特别优化的。不像传统数据库的一条记录一条数据的存储方式，Neo4j的存储方式是：节点的类别，属性，边的类别，属性等都是分开存储的，这将大大有助于提高图形数据库的性能。如下图：
-
数据读写
在Neo4j中，存储节点时使用了"index-free adjacency"，即每个节点都有指向其邻居节点的指针，可以让我们在O(1)
的时间内找到邻居节点。另外，按照官方的说法，在Neo4j中边是最重要的,是"first-class entities"，所以单独存储，这有利于在图遍历的时候提高速度，也可以很方便地以任何方向进行遍历。