随着社交、电商、金融、零售、物联网等行业的快速发展，现实社会织起了了一张庞大而复杂的关系网，传统数据库很难处理关系运算。大数据行业需要处理的数据之间的关系随数据量呈几何级数增长，亟需一种支持海量复杂数据关系运算的数据库，
图数据库应运而生。
1. 图数据简介
1.1 何为图？
学过数据结构这么课程的同学脑海中应该或多或少有 图的概念。
形式上，图是顶点(Vertices)和边(Edge)的集合，用以表现节点间的接关联关系；
在图数据库的建模中用节点表示实体，用边表现关系。
在我们的现实生活中，图表示的关系可以说是无处不在。 Gartner定义了商业世界中5个最重要的图——社交、意向、消费、兴趣和移动，并认为运用这些图的能力是一个项”可持续的竞争优势“
1.2 图数据库 GraphDB
图数据库(Graph database)并非指存储图片的数据库，而是以 图这种数据结构存储和查询数据。
图形数据库是一种在线数据库管理系统，具有处理图形数据模型的创建，读取，更新和删除（CRUD）操作。
与其他数据库不同，关系在图数据库中占首要地位。这意味着应用程序不必使用外键或带外处理（如MapReduce）来推断数据的关联关系。
与关系数据库或其他NoSQL数据库相比，图数据库的数据模型也更加简单，更具表现力。图形数据库是为与事务（OLTP）系统一起使用而构建的，并且在设计时考虑了事务完整性和操作可用性。
根据存储和处理模型不同，市面上图数据库也有一些区分。
1.2.1 图存储
一些图数据库使用 原生图存储，这类存储是经过优化的，并且是专门为了存储和管理图而设计的。并不是所有图数据库都是使用原生图存储，也有一些图数据库将图数据序列化，然后保存到关系型数据库或者面向对象数据库，或其他通用数据存储中。
1.2.2 图处理引擎
原生图处理（也称为 无索引邻接）是处理图数据的最有效方法，因为连接的节点在数据库中物理地指向彼此。非本机图处理使用其他方法来处理CRUD操作。
比如：
Neo4J就是属于原生图数据库，它使用的后端存储是专门为Neo4J这种图数据库定制和优化的，理论上说能更有利于发挥图数据库的性能。AllegroGraph不是原生图数据库，而将数据存储在其他成熟的非图后端系统上，比如Mysql或者Hbase。
1.3 应用场景
世界上很多著名的公司都在使用图数据库。比如：
社交领域：Facebook, Twitter，Linkedin用它来管理社交关系，实现好友推荐
零售领域：eBay，沃尔玛使用它实现商品实时推荐，给买家更好的购物体验
金融领域：摩根大通，花旗和瑞银等银行在用图数据库做风控处理
汽车制造领域：沃尔沃，戴姆勒和丰田等顶级汽车制造商依靠图数据库推动创新制造解决方案
电信领域：Verizon, Orange和AT&T 等电信公司依靠图数据库来管理网络，控制访问并支持客户360
酒店领域：万豪和雅高酒店等顶级酒店公司依使用图数据库来管理复杂且快速变化的库存
2. 图数据 In NoSQL
NoSQL数据库大致可以分为四类，而图数据库正是其一，各种图数据库对比，请见下方图表。
| 分类 | 数据模型 | 优势 | 劣势 | 举例 |
|---|---|---|---|---|
| 键值数据库 | 哈希表 | 查找速度快 | 数据无结构化，通常只被当作字符串或者二进制数据 | Redis |
| 列存储数据库 | 列式数据存储 | 查找速度快；支持分布横向扩展；数据压缩率高 | 功能相对受限 | HBase |
| 文档型数据库 | 键值对扩展 | 数据结构要求不严格；表结构可变；不需要预先定义表结构 | 查询性能不高，缺乏统一的查询语法 | MongoDB |
| 图数据库 | 节点和关系组成的图 | 利用图结构相关算法(最短路径、节点度关系查找等) | 可能需要对整个图做计算，不利于图数据分布存储 | Neo4j |
3. 图数据库 VS 关系型数据库
与关系型数据库和 NoSQL 数据库相比，定义良好的图数据库都有着明显优势。具体如下
- 性能: 与关系型数据库和NoSQL存储处理关联数据相比，选择图数据库会有绝对的性能提升。随着数据集的不断增大，关系型数据库处理密集join（join-intensive）查询的性能也会随之变差，而图数据库则不然。在数据集增大时，它的性能趋向于保持不变，这是因为查询总是只与图的一部分相关。因此，每个查询的执行时间只和满足查询条件的那部分遍历的图的大小（而不是整个图的大小）成正比。
- 灵活: 图天生就是可扩展的，这意味着我们可以对一个已经存在的结构增加不同种类的联系、新节点和新子图，而不用担心破坏已有的查询或应用程序的功能。这些特点对于开发者的生产力和项目风险一般都有积极的意义。同时由于图模型的灵活性，我们不必在项目最初就穷思竭虑地把领域中的每一个细枝末节都考虑到模型中—这种做法在不断变化的业务需求面前，简直就是蛮干。图的天然可扩展性也意味着我们会做更少的数据迁移，从而降低维护开销和风险。
- 敏捷性: 因为图数据库不需要schema，所以它缺少以schema为导向的数据管理机制，即在关系世界中我们已经熟知的机制。但这并不是一个风险，相反，它促使我们采用了一种更可见的、可操作的管理方式。正如我们在第4章会讲到的，图数据库的管理通常作用于编程方式，利用测试来驱动数据模型和查询，以及依靠图来断言业务规则。这不再是一个有争议的做法，事实上这已经比关系型开发应用更广了。图数据库开发方式非常符合当今的敏捷软件开发和测试驱动软件开发实践，这使得以图数据库为后端的应用程序可以跟上不断变化的业务环境。
4. 关系查询性能对比
在数据关系中心，图形数据库在查询速度方面非常高效，即使对于深度和复杂的查询也是如此。在《Neo4j in Action》这本书中，作者在关系型数据库
和图数据库(Neo4j)之间进行了实验。
他们的实验试图在一个社交网络里找到最大深度为5的朋友的朋友。他们的数据集包括100万人，每人约有50个朋友。实验结果如下：
| 深度 | MySQL执行时间(s) | Neo4J执行时间(s) | 返回记录数 |
|---|---|---|---|
| 2 | 0.016 | 0.01 | ~2500 |
| 3 | 30.267 | 0.168 | ~110 000 |
| 4 | 1543.505 | 1.359 | ~600 000 |
| 5 | 未完成 | 2.132 | ~800 000 |
在深度为2时（即朋友的朋友），两种数据库性能相差不是很明显；深度为3时(即朋友的朋友的朋友)，很明显，关系型数据库的响应时间30s，已经变得不可接受了；深度到4时，关系数据库需要近半个小时才能返回结果，使其无法应用于在线系统；深度到5时，关系型数据库已经无法完成查询。而对于图数据库Neo4J，深度从3到5，其响应时间均在3秒以内。
可以看出，对于图数据库来说，数据量越大，越复杂的关联查询，约有利于体现其优势。从深度为4/5的查询结果我们可以看出，图数据库返回了整个社交网络一半以上的人数。
5. 主流数据图产品
根据DB-Engines最新发布的图数据库排名：
- Neo4j 业界老大，行业标杆，江湖一哥；
- Nebula 异军突起，厚积薄发，当红新锐；
二者搜索热度对比： https://db-engines.com/en/system/Nebula+Graph%3BNeo4j
具体特性对比：
对比总结
- 性能与成本：Neo4j开源版本是单机的，最少2G内存就可以支持亿级别的数据；Nebula性能突出但是维护成本较高，很吃资源（测试环境需要至少8G内存才能启动）；
- 学习成本：Neo4j有专属查询语言“Cypher”，Nebula也有自己的“NQL”，二者都需要学习
- 开发成本：Neo4j和Spring紧密合作，对于Java生态支持的更好；Nebula 在这方面刚刚起步
6. Cypher查询语言
Cypher是Neo4j的图形查询语言，允许用户存储和检索图形数据库中的数据。
比如下面我们直接通过代码来对比下 MySQL 和 Neo4j 里面的查询，我相信即使不写任何注释，即使第一次接触 Neo4j 的人也能轻轻松松的看懂这些查询语句。
SELECT p.*
FROM products as p;
MATCH (p:Product)
RETURN p;
SELECT p.ProductName, p.UnitPrice
FROM products as p
ORDER BY p.UnitPrice DESC
LIMIT 10;
MATCH (p:Product)
RETURN p.productName, p.unitPrice
ORDER BY p.unitPrice DESC
LIMIT 10;
SELECT p.ProductName, p.UnitPrice
FROM products AS p
WHERE p.ProductName = 'Chocolade';
MATCH (p:Product)
WHERE p.productName = "Chocolade"
RETURN p.productName, p.unitPrice;
MATCH (p:Product {productName:"Chocolade"})
RETURN p.productName, p.unitPrice;
SELECT p.ProductName, p.UnitPrice
FROM products as p
WHERE p.ProductName IN ('Chocolade','Chai');
MATCH (p:Product)
WHERE p.productName IN ['Chocolade','Chai']
RETURN p.productName, p.unitPrice;
SELECT p.ProductName, p.UnitPrice
FROM products AS p
WHERE p.ProductName LIKE 'C%' AND p.UnitPrice > 100;
MATCH (p:Product)
WHERE p.productName STARTS WITH "C" AND p.unitPrice > 100
RETURN p.productName, p.unitPrice;
SELECT DISTINCT c.CompanyName
FROM customers AS c
JOIN orders AS o ON (c.CustomerID = o.CustomerID)
JOIN order_details AS od ON (o.OrderID = od.OrderID)
JOIN products AS p ON (od.ProductID = p.ProductID)
WHERE p.ProductName = 'Chocolade';
MATCH (p:Product {productName:"Chocolade"})<-[:PRODUCT]-(:Order)<-[:PURCHASED]-(c:Customer)
RETURN distinct c.companyName;
SELECT e.EmployeeID, count(*) AS Count
FROM Employee AS e
JOIN Order AS o ON (o.EmployeeID = e.EmployeeID)
GROUP BY e.EmployeeID
ORDER BY Count DESC LIMIT 10;
MATCH (:Order)<-[:SOLD]-(e:Employee)
RETURN e.name, count(*) AS cnt
ORDER BY cnt DESC LIMIT 10
下面在看一些更为复杂的例子，我们要查找Joe的所以二度好友：
MATCH
(person:Person)-[:KNOWS]-(friend:Person)-[:KNOWS]-
(foaf:Person)
WHERE
person.name = "Joe"
AND NOT (person)-[:KNOWS]-(foaf)
RETURN
foaf
// Joe认识Sally，Sally认识Anna。Bob被排除在结果之外，因为除了通过Sally成为二级朋友之外，他还是一级朋友。
图数据库会经常处理树形结构数据，必须要遍历Block树的最大深度
match (n:Block)
where (n)-[:OWN]->() and not ()-[:OWN]->(n) // 找到根节点
match p = (n)-[:OWN*1..]->(m) //查询所有从根节点出发的路径
return p, length(p) as L
order by L desc // 找到路径长度最大的
limit 1
或者是要从固定节点(aid = 1000)向上寻找到另一个节点（aid=10）的最短路径
match p = shortestPath( (e:block {aid:10000}) <-[*0..1000]- (r:block {aid:1}) )
return p;
更多cypher语法请阅读官方文档： Cypher语法
7. 总结
图数据库应对的是当今一个宏观的商业世界的大趋势：凭借高度关联、复杂的动态数据，获得洞察力和竞争优势。国内越来越多的公司开始进入图数据库领域，研发自己的图数据库系统。对于任何达到一定规模或价值的数据，图数据库都是呈现和查询这些关系数据的最好方式。而理解和分析这些图的能力将成为企业未来最核心的竞争力。
更多学习资料：
- 如何使用Neoj4建模
- Cypher语法
- 深度运算法 https://ramona-chen.top/2020/03/24/neo4j-cha-xun-duo-shen-du-guan-xi-jie-dian/
- Neo4j Java Driver https://neo4j.com/docs/developer-manual/current/drivers/get-started/
- Spring 实体映射关系 https://github.com/neo4j/neo4j-ogm
- 官方学习数据 https://neo4j.com/graphgists/
- 运维 Shell 脚本命令 https://neo4j.com/docs/operations-manual/4.3/tools/cypher-shell/