为什么选择图形数据库，为什么选择Neo4j？
最近在抓取一些社交网站的数据，抓下来的数据用MySql存储。问我为什么用MySql，那自然是入门简单，并且我当时只熟悉MySql。可是，随着数据量越来越大，有一个问题始终困扰着我，那就是社交关系的存储。
就以新浪微博举例，一个大V少则十几万，多则几千万的粉丝，这些关注关系要怎么存呢？在MySql中，一条关注关系（大V id，大V的一个粉丝 id）存为一条数据，那么当用户数量上来的时候，关注关系轻松破亿，破十亿，甚至上百亿，并且为了保证每条数据的唯一性，还需要设置联合索引，MySql就有些力不从心了。那么有人要说了：分表呀。嗯，没错，分表的确可以在插入端和读取端提升一些速度。比如我们可以根据id哈希到100张表中。查询一个用户有哪些粉丝是快了，但是查询一个用户关注了哪些人时仍然需要遍历全表。好，这时候我们还可以以（id，其关注的一个用户的id）再构造100张表，于是两种查询都快了。然而，后面那100张表是冗余数据，看着就不爽...并且生成一张子图也不方便（需要多次写SQL查表）。
于是，在搜索更好的方案时无意间发现了图形数据库，查阅一番资料后感觉确实是个不错的选择，毕竟业界的一些大佬，如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"，所以单独存储，这有利于在图遍历的时候提高速度，也可以很方便地以任何方向进行遍历。
更多的资料可以看参考资料第一条。
关于为什么选图形数据库就说到这。如今可供选择的图形数据库也不少，为什么就选择了Neo4j呢？我简要归结为以下几点：
- 作为较早的一批图形数据库之一，文档和各种技术博客较多。
- 最开始曾尝试过flockdb（据说操作简单+轻量级），但是败于安装过程...，依赖太多。
- 网上经常有人将orientdb，arangodb与neo4j做对比，我当然也考虑过orientdb和arangodb。从易用性来说都差不多。速度上的话看过一些评测，arangodb应该是相对最快的，因为其使用了混合索引。但是从稳定性来说，neo4j是最好的。
时间有限，我并没有通读Neo4j的官方文档。但作为一个数据库使用者，能大概地了解为什么要选这个数据库就已经足够了。
最后做个总结吧。图形数据库是这几年兴起的，整体还不是很完善，而且适用面也是比较窄的。只有在明确自己的需求之后，才能确定是否选择图形数据库。
转载请注明出处：http://www.cnblogs.com/rubinorth/
