本文就图数据库相关知识进行介绍和总结，并且就可能运用到图数据库中的项目场景进行分析。
注意：本文所讲的图数据库，和graphQL并没有什么联系，graphQL只是一种用于前端的类似图查询语言，而图数据库更多的是服务端层面关注的内容(类比mysql、mongodb)。
从 NoSQL 数据库说起
最近几年，相比于 mySQL 等 SQL 数据库，我们同样能听到的还有 NoSQL 类型数据库，比如 redis、mongodb，实际上，NoSQL 这个词知识定义了它所代表的那些数据存储不是什么——它们不是以 SQL 为中心的关系型数据库——而没有定义他们是什么。 NoSQL 数据库不只是我们熟知的 redis 等键值对数据库，还有图数据库、列族、文档等几类数据库。
这次，我们主要分析 NoSQL 数据库中的图数据库。
为什么使用图数据库？
图数据库有其特定的应用场景，而这些特定的应用场景如果使用 mySQL 数据库等往往会有巨大的性能开销。
我们举一个例子，假设在一个社交关系数据库中，我们只考虑用户和用户之间的朋友关系(这里我们注意，对于两个用户A，A认为B是A的朋友，并不代表B认为A是B的朋友，这里考虑的是一种有向关系)，针对用户A，假如我们想分析谁是用户A的朋友，这个查询通常会比较快，但是我们如果查询“谁的朋友是用户A”，这个时候如果我们的表没有经过特殊设计，我们是需要遍历整个关系表的，如果是更复杂的多层反向查询问题，那么这个代价只会更高。
同样的，在商品数据库中，我们查询某个客户买了哪些商品通常效率比较高，但是我们要查询”那些客户买了这个商品”甚至是“有哪些买了这个商品的客户也买了那个商品”的这种多层关系的时候，数据库通常就显得力不从心了。
实际上，关系型数据库在处理反向查询以及多层次关系查询的时候通常开销较大。
相比之下，图数据库在处理这类问题就能发挥更大的优势，原因主要有如下几点：
- 同等的看待节点和边(关系)，节点和边都是一等公民并建立表
- 采用双向指针，原生的图存储，在查节点之间的关系通常可以做到常数级别
图数据库查询语言
图数据库也有自己的查询语言，Cypher，对于使用 SQL 数据库的用户，这里先简单说明一下下面中提到的名词的含义：
- neo4j 可以类比 mySQL，是一种图数据库的比较标准的实现
- Cypher 可以类比 SQL语句，用于图数据库中的查询
Cypher 是一种非常直观的图数据库查询语言，这里并不打算介绍 Cypher 的语法，但是还是会通过例子来进行简明介绍。
以下 Cypher 代码的作用是查询 Jim 和他的好朋友的共同好友：
MATCH (a:Person {name:'Jim'}) -[:KNOWS]-> (b) -[:KNOWS]-> (c)
(a) -[:KNOWS]-> (c)
RETURN b,c
这个查询想必看起来非常直观，我认为，相比于 SQL 语句那种类似英文语句的写法， Cypher更类似于画图的写法，通过把关系画出来，进行查询。
MATCH 语句表示实例匹配，可以结合 RETURN 语句将匹配到的部分返回出来。
在图数据库中 --> 和 <-- 表示联系，在两个 - 中间，我们可以加入联系的标签，表明联系类型。
(a:Person {name:'Jim'}) 则表示要匹配出标签为 Person 并且 name 属性为 Jim 的节点。
我们在这里不再进行更多的举例。
构建基于图数据库的应用
图数据库特别适合用于关系网络类和推荐系统的应用构建，我们可以使用 neo4j 来进行构建，我们可以到这里下载neo4j server，其有如下几个特点：
- REST API： 服务器公开了丰富的REST API，允许客户端通过HTTP发送JSON格式的请求。响应包括JSON格式的含有链接的富文本。
- 平台独立性，由于访问是通过 HTTP 发送 JSON 格式的文档，因此neo4j 服务器几乎可以被运行于任何平台上的客户端访问，唯一需要的是一个 HTTP 客户端库。
- 对服务器集群、负载均衡、事务等进行了支持，并且网络开销较小。
当然，我认为最好的方式是通过构建服务端扩展来使用 neo4j(比如通过nodeJS发送查询请求，而不是前端直接调用REST API)，这样前端可以不必管后端到底是用mySQL 还是neo4j，只会发现的是，响应速度的确提高了很多。
总结
图数据库这个领域目前并不如传统的关系型数据库那么稳定和被人熟知，但是其肯定是未来数据库的趋势之一(也许并不是neo4j，可能是其他实现)，其在社交网络、大数据分析、推荐系统、web安全方面目前看来有非常大的优势。
用了这么多年的 mySQL，现在，可以考虑在下一个项目中开始使用图数据库了。
