From f4fedeb8498dc03bf0da4729630e055201d072d7 Mon Sep 17 00:00:00 2001
From: Abby <78209557+abby-cyber@users.noreply.github.com>
Date: Fri, 25 Feb 2022 14:04:44 +0800
Subject: [PATCH 1/2] synchronize book with 3.0.0

---
 docs-2.0/1.introduction/0-0-graph.md          | 230 ++++++++++++++++
 docs-2.0/1.introduction/0-1-graph-database.md | 245 +++++++++++++++++
 docs-2.0/1.introduction/0-2.relates.md        | 251 ++++++++++++++++++
 docs-2.0/20.appendix/history.md               |  34 +++
 mkdocs.yml                                    |  68 ++---
 5 files changed, 796 insertions(+), 32 deletions(-)
 create mode 100644 docs-2.0/1.introduction/0-0-graph.md
 create mode 100644 docs-2.0/1.introduction/0-1-graph-database.md
 create mode 100644 docs-2.0/1.introduction/0-2.relates.md
 create mode 100644 docs-2.0/20.appendix/history.md

diff --git a/docs-2.0/1.introduction/0-0-graph.md b/docs-2.0/1.introduction/0-0-graph.md
new file mode 100644
index 00000000000..153b6c1eecf
--- /dev/null
+++ b/docs-2.0/1.introduction/0-0-graph.md
@@ -0,0 +1,230 @@
+# 图
+
+当前，从计算机行业巨头（例如 Amazon 和 Facebook）到小型研究团队，都投入了大量的资源探索图数据库在解决各种数据关系问题上的潜力。当然你也可以选择像他们这样进行尝试，现在可供选择的数据库有很多。那么图数据库究竟是什么？它可以做些什么？作为一类数据库，它在数据库领域里处于什么位置呢？要回答这些问题，我们首先得了解图。
+
+图是计算机科学研究的主要领域之一。图能够高效地解决目前存在的诸多问题。本章将从图说起，继而说明图数据库的优点及其在现代应用程序开发中的巨大潜力，然后介绍分布式图数据库的区别和几种其他类型的数据库。
+
+## 图、图片与图论
+
+图无处不在。当听到图这个词时，很多人都会想到条形图或折线图，因为有时候我们确实会把它们称作图。从传统意义上来说，图是用来展示两个或多个数据系统之间的联系的。最简单的例子如下图，下图展示了 Nebula Graph GitHub 仓库星星数量随时间推移的变化。
+
+![image](https://user-images.githubusercontent.com/42762957/91426247-d3861000-e88e-11ea-8e17-e3d7d7069bd1.png "这不是本书所说的图")
+
+这是相对比较简单的一种图，横轴为时间，纵轴为星星数量。可以看到，星星数量是随着时间推移而上升的。这种类型的图通常称为折线图。折线图可以显示随时间（根据常用比例设置）而变化的连续数据。此处我们只给出了折线图的例子。当然图的形式有多种，比如饼图、条形图等。
+
+还有一种“图”在日常口语中会更多的被提及，例如，“图像识别”，“美图秀”，“修图”等。例如下“图”的左边。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/image.png "这也不是本书所说的图")
+
+但是——总会有但是——我们在本书中讨论的图是另外一个概念——“图论”中的图。
+
+在数学的分支图论中，图是基本研究对象，用于表示实体与实体之间的关系。一张图由一些小圆点（称为顶点或节点，即 Vertex）和连接这些圆点的直线或曲线（称为边，即 Edge）组成。“图（Graph）”这一名词最早由西尔维斯特在 1878 年提出。
+
+通常，在英文中，为了区分这两种不同的图，前者会称为 Image，后者称为 Graph。在中文中，前者会强调为“图片”，后者会强调为“拓扑图”、“网络图”等。
+
+![Image](https://docs-cdn.nebula-graph.com.cn/books/images/undirectedgraph.png)
+
+ 这才是本书所说的图。
+
+简单来说，图论就是研究图的学问。图论始于 18 世纪初期的柯尼斯堡七桥问题。柯尼斯堡当时是普鲁士的城市（现在属于俄罗斯，更名为加里宁格勒）。普雷格尔河穿过柯尼斯堡，不仅把柯尼斯堡分成了两部分，而且还在河中间形成了两个小岛。这就将整个城市分割成了四个区域，各区域由七座桥连接。当时有一个与柯尼斯堡相关的小游戏，即如何只穿过每座桥一次，浏览整个城市的四个区域。下图为柯尼斯堡七座桥的简化图。 有兴趣的话可以试试寻找这个小游戏的答案[^171]。
+
+![image](https://user-images.githubusercontent.com/42762957/91536940-1526c180-e948-11ea-8fe8-90f40ce28171.png)
+
+[^171]: 图片来源 https://medium.freecodecamp.org/i-dont-understand-graph-theory-1c96572a1401.
+
+大数学家欧拉为了解决了这一问题。通过将城市的四个区域抽象成点，将连接城市的七座桥抽象成连接点的边，欧拉证明了这一问题是无法解决的。简化的抽象图如下[^063]：
+
+![image](https://user-images.githubusercontent.com/42762957/91538126-e578b900-e949-11ea-980c-5704254e8063.png)
+
+[^063]: 图片来源 https://medium.freecodecamp.org/i-dont-understand-graph-theory-1c96572a1401
+
+图中四个点代表柯尼斯堡的四个区域，点之间的线代表连接四个区域的七座桥。从图中不难看出，偶数座桥连接的区域可以轻松通过，因为来去可以选择不同的路线。奇数座桥连接的区域只能作为起点或者终点，因为同样的路线只能走一次。和节点相关联的边的条数称为节点度。现在可以证明，只有两个节点有奇数度，另外节点有偶数度时，也即两个区域必须有偶数座桥，剩下的区域有奇数座桥时，柯尼斯堡问题才能解决。然而由上图得知，柯尼斯堡的任何区域都没有偶数座桥，所以这个谜题无解。
+
+## 属性图
+
+从数学角度来说，图论是研究建模对象之间关系结构的学科。但是从工业界使用的角度，通常会对基础的图模型进行扩展，称为**属性图模型**。属性图通常由以下几部分组成：
+
+- 节点，即对象或实体。在本书中，通常简称为点（Vertex）。
+- 节点之间的关系，在本书中，通常简称为边（Edge）。通常边是有方向或者无方向的，以表示两个实体之间有持续的关系。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/un-directed.png)
+
+- 此外，在节点和边上，还可以有属性（properties）。
+
+在现实生活中，有很多属性图的例子。
+
+例如企查查或者 BOSS 直聘这类的公司，用图来建模商业股权关系网络。这个网络中，点通常是一个自然人或者是一家企业，边通常是某自然人与某企业之间的股权关系。点上的属性可以是自然人姓名、年龄、身份证号等。边上的属性可以是投资金额、投资时间、董监高等职位关系。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/enterprise-relations.png)
+
+在一个股票市场里面，点可以是一家上市公司，边可以是上市公司之间的相关性。点的属性可以为股票代码、简称、市值、板块等；边的属性可以为股价的时间序列相关性系数[^T01]。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/JGraphT01.png)
+
+[^T01]: https://nebula-graph.com.cn/posts/stock-interrelation-analysis-jgrapht-nebula-graph/
+
+图关系还可以是类似《权力的游戏》这样电视剧中的人物关系网[^s-01]：点为人物，边为人物之间的互动关系；点的属性为人物姓名、年龄、阵营等，边的属性（距离）为两个人物之间的互动次数，互动越频繁距离越近。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/game-of-thrones-01.png)
+
+[^s-01]: https://nebula-graph.com.cn/posts/game-of-thrones-relationship-networkx-gephi-nebula-graph/
+
+图也可以用于 IT 系统内部的治理。例如，对于像微众银行这样的公司，通常有着非常庞大的数据仓库，以及相应的数仓管理工具。这些管理工具记录了数仓内 Hive 表之间通过 Job 实现的 ETL 关系[^ware]，这样的 ETL 关系，可以非常方便的用图的形式呈现和管理，当出现问题时也可以非常方便地追溯根源。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/dataware.png)
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/dataware2.png)
+
+[^ware]: https://nebula-graph.com.cn/posts/practicing-nebula-graph-webank/
+
+图也可以用于记录一个大型 IT 系统内部错综复杂的微服务之间的调用关系[^tice]，运维团队用其进行服务治理。这里每个点表示一个微服务，边表示两个微服务之间的调用关系；这样，运维人员可以方便地寻找可用性低于阈值 (99.99%) 的调用链路，或者发现那些出故障会影响面特别大的微服务节点。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/microserve.png)
+
+图也可以用于提升代码开发效率。用图存放代码之间的函数调用关系[^tice]，可以提升研发团队审查和测试代码的效率。在这样的图中，每个点是代码中的一个函数或者变量，每个边是函数或者变量之间的调用关系。当有新提交的代码之时，人们可以更方便的看到可能会受到影响到的其他接口，这样可以帮助测试人员更好的评估潜在的上线风险。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/code.png)
+
+[^tice]: https://nebula-graph.com.cn/posts/meituan-graph-database-platform-practice/
+
+此外，相对于静态不发生变化的属性图，我们还可以通过增加一些时间信息，发掘出更多的使用场景。
+
+例如，在一个银行间账户资金流向网络里面[^1440w]，点是账户，边是账户之间的转账记录。边属性记录了转账的时间、金额等。同盾、邦盛、半云科技等公司采用图技术，可以方便地通过图的方式探索发现明显的资金挪用、“以贷还贷”、“团伙贷款”等现象。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/bank-transfer.jpg)
+
+[^1440w]: https://zhuanlan.zhihu.com/p/90635957
+
+同样的方法也可以用于探索发现加密货币的流向。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/block-chain.png)
+
+在一个黑产账户和设备网络中[^360]，其中的点可以是账户、手机设备和 WIFI 网络，边是这些账户与手机设备之间的登录关系，以及手机设备和 WIFI 网络之间的接入关系。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/360-user-1.png)
+
+这些登录记录的网络构成了黑产群体网络的团伙作案特征。360 数科[^360]、快手[^kuaishou]、微信[^weixin]、知乎[^zhihu]、携程金融这些公司都通过图技术实时（毫秒级的）识别超过百万个的黑产社群。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/360-user-2.png)
+
+[^360]: https://nebula-graph.com.cn/posts/graph-database-data-connections-insight/
+
+[^kuaishou]: https://nebula-graph.com.cn/posts/kuaishou-security-intelligence-platform-with-nebula-graph/
+
+[^weixin]: https://nebula-graph.com.cn/posts/nebula-graph-for-social-networking/
+
+[^zhihu]: https://mp.weixin.qq.com/s/K2QinpR5Rplw1teHpHtf4w
+
+更进一步，除了时间这个维度外，我们通过添加一些地理位置信息，还能发现属性图更多的应用场景。
+
+例如新冠病毒的流行病学溯源[^CoV02]，点是人物，边是人与人之间的接触；点属性为人物的身份证、发病时间等信息，边属性为人物之间发生密切接触的时间和地理位置等。为卫生防疫部门快速识别高风险人群和其行为轨迹提供帮助。
+
+![image](https://www-cdn.nebula-graph.com.cn/nebula-blog/nCoV02.png)
+
+[^CoV02]: https://nebula-graph.com.cn/posts/detect-corona-virus-spreading-with-graph-database/
+
+地理位置与图的结合也可以用于一些 O2O 的场景，例如基于 POI（Point-of-Interest）的实时美食推荐[^mt]，使得美团这类本地生活服务平台公司能在消费者在打开 APP 的时候，实时推荐出更为合适的商家。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/meituan2.png)
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/meituan.png)
+
+[^mt]: https://nebula-graph.com.cn/posts/meituan-graph-database-platform-practice/
+
+图还可以用于更深度的知识推理，华为、vivo、OPPO、微信、美团等公司，将图用于表征底层知识关系的数据模型。
+
+## 为什么要使用图数据库
+
+虽然关系型数据库与 XML/JSON 等半结构类型的数据库，都可以用来描述图结构的数据模型，但是，图（数据库）不仅可以描述图结构与存储数据本身，更着眼于处理数据之间的关联（拓扑）关系。具体来说，图（数据库）有这么几个优点：
+
+- 图是一种更直观、更符合人脑思考直觉的知识表示方式。这使得我们在抽象业务问题时，可以着眼于“业务问题本身”，而不是“如何将问题描述为数据库的某种特定结构（例如表格结构）”。
+
+- 图更容易展现数据的特征，例如转账的路径、近邻的社区。例如，如果要分析《权力的游戏》中的人物派别关系和人物重要性，表的组织方式如下：
+
+  ![image](https://www-cdn.nebula-graph.com.cn/nebula-blog/gephi-01.jpeg)
+
+  这显然不如下方图的组织方式直观：
+
+  ![image](https://www-cdn.nebula-graph.com.cn/nebula-blog/game-of-thrones-01.png)
+
+  特别是当某些中心节点被删除：
+
+  ![image](https://www-cdn.nebula-graph.com.cn/nebula-blog/tv-game-thrones.png)
+
+  或者，增加一条边，可以彻底地改变整个图拓扑：
+
+  ![image](https://www-cdn.nebula-graph.com.cn/nebula-blog/tv-game-thrones-02.png)
+
+  虽然只是个别数据的细微改变，图可以比表更直观地表现其中的重要而系统的信息。
+
+- 图查询语言是针对图结构访问设计的，可以更加直观。例如，下面是一个 LDBC 中的查询示例，要求：查找某人（Person）在社交网络上发布的帖子（Posts）；查找相应的回复（Message，回复本身还会被多次回复）;发帖时间、回帖时间都满足一定条件；根据回帖数量对结果排序。
+
+  ![image](https://docs-cdn.nebula-graph.com.cn/books/images/efficientquery.png)
+
+  如果使用 PostgreSQL 编写查询语句：
+
+  ```SQL
+  --PostgreSQL
+  WITH RECURSIVE post_all(psa_threadid
+                        , psa_thread_creatorid, psa_messageid
+                        , psa_creationdate, psa_messagetype
+                         ) AS (
+      SELECT m_messageid AS psa_threadid
+           , m_creatorid AS psa_thread_creatorid
+           , m_messageid AS psa_messageid
+           , m_creationdate, 'Post'
+        FROM message
+       WHERE 1=1 AND m_c_replyof IS NULL -- post, not comment
+         AND m_creationdate BETWEEN :startDate AND :endDate
+    UNION ALL
+      SELECT psa.psa_threadid AS psa_threadid
+           , psa.psa_thread_creatorid AS psa_thread_creatorid
+           , m_messageid, m_creationdate, 'Comment'
+        FROM message p, post_all psa
+       WHERE 1=1 AND p.m_c_replyof = psa.psa_messageid
+       AND m_creationdate BETWEEN :startDate AND :endDate
+  )
+  SELECT p.p_personid AS "person.id"
+       , p.p_firstname AS "person.firstName"
+       , p.p_lastname AS "person.lastName"
+       , count(DISTINCT psa.psa_threadid) AS threadCount
+  END) AS messageCount
+       , count(DISTINCT psa.psa_messageid) AS messageCount
+    FROM person p left join post_all psa on (
+         1=1   AND p.p_personid = psa.psa_thread_creatorid
+     AND psa_creationdate BETWEEN :startDate AND :endDate
+     )
+   GROUP BY p.p_personid, p.p_firstname, p.p_lastname
+   ORDER BY messageCount DESC, p.p_personid
+   LIMIT 100;
+  ```
+
+  如果使用为图专门设计的图语言 Cypher 编写查询语句：
+
+  ```Cypher
+  --Cypher
+  MATCH (person:Person)<-[:HAS_CREATOR]-(post:Post)<-[:REPLY_OF*0..]-(reply:Message)
+  WHERE post.creationDate >= $startDate AND post.creationDate <= $endDate
+    AND reply.creationDate >= $startDate AND reply.creationDate <= $endDate
+  RETURN
+    person.id, person.firstName, person.lastName, count(DISTINCT post) AS threadCount,
+    count(DISTINCT reply) AS messageCount
+  ORDER BY
+    messageCount DESC, person.id ASC
+  LIMIT 100
+  ```
+
+- 由于存储引擎和查询引擎可以针对图的结构专门设计，图的遍历（对应 SQL 中的 join）要高效得多。下图是知名产品 Neo4j 所做的一个对比[^mt]。
+
+  ![image](https://docs-cdn.nebula-graph.com.cn/books/images/neo4jhop.png)
+
+- 图数据库具有广泛的适用场景。例如数据集成（知识图谱）、个性化推荐、欺诈与威胁检测、风险分析与合规、身份（与控制权）验证、IT 基础设施管理、供应链与物流、社交网络研究等。
+
+- 根据文献[^Ubiquity] 的统计，使用图技术最多的领域，依次是：信息技术(IT)、学术界研究、金融、工业界实验室、政府、医疗健康、国防、制药业、零售与电子商务、交通运输、电信、保险。
+
+[^Ubiquity]: https://arxiv.org/abs/1709.03188
+
+- 2019 年，根据 Gartner 的问卷调研，27% 的客户（500 组）在使用图数据库，20% 有计划使用。
+
+## RDF
+
+受篇幅所限，本章不讨论 RDF 数据模型。
diff --git a/docs-2.0/1.introduction/0-1-graph-database.md b/docs-2.0/1.introduction/0-1-graph-database.md
new file mode 100644
index 00000000000..e6942c40c94
--- /dev/null
+++ b/docs-2.0/1.introduction/0-1-graph-database.md
@@ -0,0 +1,245 @@
+# 图数据库的市场概况
+
+既然已经讨论了什么是图，接下来让我们进一步认识基于图论和属性图模型发展起来的图数据库。
+
+不同的图数据库在术语方面可能会略有不同，但是归根结底都是在讲点、边和属性。至于更多的功能，例如标签、索引、约束、TTL、长任务、存储过程和UDF等这些高级功能，在不同图数据库中，会存在明显的差异。
+
+图数据库用图来存储数据，而图是最接近高度灵活、高性能的数据结构之一。图数据库是一种专门用于存储和检索庞大信息网的存储引擎，它能够高效地将数据存储为点和边，并允许对这些点边结构进行高性能的检索和查询。我们也可以为这些点和边添加属性。
+
+图数据库几乎适用于存储所有领域的数据。因为在几乎所有领域中，事物之间都是由某种相关联的。图数据库支持存储实体之间的丰富关系，并且能够将这些关系完美地呈现出来，而无需像其他建模方式那样，将关系也当成实体存储。因此图数据库能够以最接近对数据直观认知的形式存储数据。
+
+## 三方机构的统计和预测
+
+### DB-Engines 的统计
+
+根据世界知名的数据库排名网站DB-Engines.com的统计，图数据库至2013年以来，一直是“增速最快”的数据库类别[^dbe]。
+
+该网站根据一些指标来统计每种类别的数据库的流行度变化趋势，这些指标包括基于Google等搜索引擎的收录和趋势情况、主要IT技术论坛和社交网站上讨论的技术话题、招聘网站的职位变化等。该网站共收录了371种数据库产品，并分为12个类别。这12个类别中，图数据库这种类别的增速远远快于其他任何的类别。
+
+![Image](https://docs-cdn.nebula-graph.com.cn/books/images/db-rankings.png)
+
+[^dbe]: https://db-engines.com/en/ranking_categories
+
+### Gartner 的预测
+
+世界顶级智库Gartner早在2013年之前[^Gartner1]，就将图数据库作为主要的"商业智能与分析技术趋势"。在那个时候，Big Data正火热的如日中天，数据科学家更是炙手可热的职位。
+
+![Image](https://docs-cdn.nebula-graph.com.cn/books/images/gartner.jpg)
+
+[^Gartner1]: https://www.yellowfinbi.com/blog/2014/06/yfcommunitynews-big-data-analytics-the-need-for-pragmatism-tangible-benefits-and-real-world-case-165305
+
+直到最近，图数据库及相关的图技术依旧是"2021年十大数据与分析趋势"[^Gartner2]:
+
+![Image](https://images-cdn.newscred.com/Zz01NWM5ZDE3YzcxM2UxMWViODBhMDE5NTExMjNjOTZmZQ==)
+
+!!! quote "趋势八：图技术使一切产生关联（Graph Relates Everything）"
+    
+    图技术已成为许多现代数据和分析能力的基础，能够在不同的数据资产中发现人、地点、事物、事件和位置之间的关系。数据和分析领导者依靠图技术快速回答需要在了解情况并理解多个实体之间的联系和优势的性质后才能回答的复杂业务问题。
+
+    Gartner预测，到2025年图技术在数据和分析创新中的占比将从2021年的10%上升到80%。该技术将促进整个企业机构的快速决策。       
+
+[^Gartner2]: https://www.gartner.com/smarterwithgartner/gartner-top-10-data-and-analytics-trends-for-2021/
+
+可以注意到，Gartner 的预测比较好的吻合了 DB-Engines 的统计结论。技术的进步并不是完全线性的，通常会有一段快速发展的泡沫期，然后进入一段平台期，之后由于新的技术的出现产生新一轮的泡沫期，再经历一段平台期。以此往复螺旋形的循环发展。
+
+### 对于市场规模的预测
+
+根据 verifiedmarketresearc[^ver], fnfresearch[^fnf],  marketsandmarkets[^mam], 以及 gartner[^gar] 等智库的统计和预测，图数据库市场（包括云服务）规模在2019年大约是8亿美元，将在未来6年保持25%左右的年复合增长(CAGR)至 30-40 亿美元，这大约对应于全球数据库市场 5-10% 的市场份额。
+
+![Image](https://www.verifiedmarketresearch.com/wp-content/uploads/2020/10/Graph-Database-Market-Size.jpg)
+
+[^ver]: https://www.verifiedmarketresearch.com/product/graph-database-market/
+
+[^fnf]: https://www.globenewswire.com/news-release/2021/01/28/2165742/0/en/Global-Graph-Database-Market-Size-Share-to-Exceed-USD-4-500-Million-By-2026-Facts-Factors.html
+
+[^mam]: 
+https://www.marketsandmarkets.com/Market-Reports/graph-database-market-126230231.html
+
+[^gar]: https://www.gartner.com/en/newsroom/press-releases/2019-07-01-gartner-says-the-future-of-the-database-market-is-the
+
+## 市场参与者
+
+### （第一代）图数据库的先行者 Neo4j
+
+虽然在 1970 年代，人们已经提出了一些类似于"图”的数据模型和产品原型（例如 CODASYL[^DDIA])和相应的图语言 G/G+ 语言[^Glang]。但真正能够让“图数据库”这个概念流行起来，不得不说到这个市场最主要的先行者 Neo4j，甚至(标签)属性图和图数据库这两个主要术语就是 Neo4j 最早提出并实践的。 
+
+[^DDIA]: https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321
+
+[^Glang]: I. F. Cruz, A. O. Mendelzon, and P. T. Wood. A Graphical Query Language Supporting Recursion. In Proceedings of the Association for Computing Machinery Special Interest Group on Management of Data, pages 323–330. ACM Press, May 1987.
+
+
+!!! Info "本小节关于Neo4j和其创造的图查询语言Cypher的历史内容主要摘录自 ISO WG3 的工作论文"An overview of the recent history of Graph Query Languages"[^Tobias2018] 和[^Glang]，本书作者根据最新两年的进展有删减和更新。"
+
+!!! Note "关于图查询语言(Graph Query Language，GQL) 和国际标准的制定"
+
+    熟悉数据库的读者可能都知道结构化查询语言SQL。通过使用SQL，人们以接近自然语言的方式访问数据库。在 SQL 被广泛采用和标准化之前，关系型数据库的市场是非常碎片和割裂的——各家厂商的产品都有完全不同的接入访问方式，数据库产品自身的开发人员、数据库产品周边工具的开发人员、数据库最终的使用人员，都不得不学习各个厂商的完全不同的产品，在不同产品之间迁移极其困难。当1989年SQL-89标准被制定后，整个关系型数据库的市场快速收敛到SQL-89上。这大大降低了上述各种人员的学习曲线。
+
+    类似的，在图数据库领域，图语言(GQL)承担了类似于SQL的作用，是一种用户与图数据库主要的交互方式。但不同于SQL-89这种国际标准，GQL还没有任何国际标准。目前有两种主流的图语言：
+
+    Neo4j的Cypher (及其后续——ISO正在制定过程中的 GQL-standard 草案)和Apache TinkerPop的Gremlin。前者通常被称为声明式语言(Declarative query language)——也即用户只需要告诉系统“要什么”，而不管“怎么做”；后者通常被称为命令式语言(Imperative query language)，用户会显式地指定系统的操作。
+    
+    GQL国际标准正在制定过程中。
+
+[^Tobias2018]: "An overview of the recent history of Graph Query Languages". Authors: Tobias Lindaaker, U.S. National Expert.Date: 2018-05-14 
+
+#### 年表简述
+
+- 2000 年，Neo4j 的创始人产生将数据建模成网络（network）的想法。
+- 2001 年，Neo4j 开发了最早的核心部分代码。
+- 2007 年，Neo4j 开始以一个公司的方式运作。
+- 2009 年，Neo4j 团队借鉴 XPath 作为图查询语言，Gremlin[^Gremlin]最初也是基于这个想法。
+- 2010 年，Neo4j 的员工 Marko Rodriguez 采用术语属性图（Property Graph）来描述 Neo4j 和 Tinkerpop / Gremlin 的数据模型。
+- 2011 年，第一个公开发行版本 Neo4j 1.4; 并发布了Cypher的第一个版本。
+- 2012 年，Neo4j 1.8 为 Cypher 增加写入图的能力。Neo4j 2.0 增加了标签和索引，Cypher 成为一种声明式的语言。
+- 2015 年，Neo4j 将 Cypher 开源为 openCypher。
+- 2017 年，ISO WG3 工作组开始讨论如何将属性图查询能力引入 SQL。
+- 2018 年 12 月，从 Neo4j 3.5 开始其核心部分转为闭源。
+- 2019 年, ISO 正式立项两个项目(ISO/IEC JTC 1 N 14279和ISO/IEC JTC 1/SC 32 N 3228），启动关于图数据库语言国际标准的制定工作。
+- 2021 年，Neo4j 完成 F 轮 3.25 亿美元的融资，是整个数据库（包括关系型）历史上最大一轮融资。
+
+[^Gremlin]: Gremlin是基于Apache TinkerPop开发的图语言(https://tinkerpop.apache.org/)。
+
+#### Neo4j 的早期历史
+
+Neo4j 和属性图这种数据模型，最早构想于 2000 年。Neo4j 的创始人们当时在开发一个媒体管理系统，所使用的数据库的 schema 经常会发生重大变化。为了支持这种灵活性，Neo4j 的联合创始人 Peter Neubauer，受到 Informix Cocoon 的启发，希望将系统能够建模为一种概念相互连接的网络。印度理工学院孟买分校的一群研究生们实现了最早的原型。Neo4j 的联合创始人 Emil Eifrém 和这些学生们花了一周的时间，将 Peter 最初的想法扩展成为一个更抽象的模型：节点通过关系连接，key-value 作为节点和关系的属性。这群人开发了一个 Java API 来和这种数据模型交互，并在关系型数据库之上实现了一个抽象层。
+
+虽然这种网络模型极大的提高了生产力，但是性能一直很差。所以 Neo4j 联合创始人 Johan Svensson 花了不少精力，为这种网络模型实现了一个原生的数据管理系统。这个就成为了 Neo4j。在最初的几年，Neo4j 作为一个内部产品很成功。在 2007 年，Neo4j 的知识产权转移给了一家独立的数据库公司。
+
+在 Neo4j 的第一个公开发行版中（Neo4j 1.4，2011 年），数据模型由节点和有类型的边构成，节点和边都有 key-value 组成的属性。Neo4j 的早期版本没有任何的索引，应用程序只能从根节点开始自己构造查询结构（search structure）。因为这样对于应用程序非常笨重，Neo4j 2.0（2013.12）引入了一个新概念——点上的标签（label）。基于点标签，Neo4j 可以为一些预定义的节点属性建立索引。
+
+"节点"、"关系"、"属性"、"关系只能有一个标签"、"节点可以有零个或者多个标签"，以上这些概念构成了 Neo4j 属性图的数据模型定义。随着后来增加的索引功能，让 Cypher 成为了与 Neo4j 交互的主要方式。因为这样应用程序开发者只需要关注于数据本身，而不是上段提到的那个开发者自己构建的查询结构（search structure）。
+
+#### Gremlin 的创造
+
+Gremlin是基于Apache TinkerPop开发的图语言，其风格接近于一连串的函数（过程）调用。最初 Neo4j 的查询方式是通过 Java API。应用程序可以将查询引擎作为库(library)嵌入到应用程序中，然后使用 API 来查询图。
+
+就在这段时间，NOSQL 这个概念开始出现。NOSQL 型的数据库引擎一般用 REST 和 HTTP 来交互和查询。Neo4j 的早期员工 Tobias Lindaaker、Ivarsson、Peter Neubauer 、Marko Rodriguez用 XPath 作为图查询，Groovy 提供循环结构，分支和计算（等图灵完毕的功能）。 这个就是 Gremlin 最初的原型。 2009 年 11 月发布了第一个版本。
+
+后来，Marko 发现同时用两种不同的解析器（XPath 和 Groovy）有很多问题，就将 Gremlin 改为基于 Groovy 的一种领域特定语言（DSL）。
+
+#### Cypher 的创造
+
+Gremlin 和 Neo4j 的 Java API 一样，最初用于表达如何查询数据库的一种过程（Procedural）。它允许更短的语法来表达查询，也允许通过网络远程访问数据库。Gremlin 这种过程式的特性，需要用户知道如何采用最好的办法查询结果，这样对于应用程序开发人员来说仍旧有负担。与此同时，在过去30年中，声明式语言 SQL 取得了极大的成功：SQL 可以将“获取数据的声明方式”和“引擎如何获取数据”相分开，所以 Neo4j 的工程师们希望开发一种声明式的图查询语言。
+
+2010 年，Andrés Taylor 作为工程师加入 Neo4j。受 SQL 启发，他启动了一个项目来开发图查询语言，而这种新语言于 2011 年 Neo4j 1.4 发布，这种新语言就是如今大多数图查询语言的先祖——Cypher 。
+
+Cypher 的语法基础，是用 "ASCII艺术(ASCII art)" 来描述图模式。这种方式最初来源于 Neo4j 工程师团队在源代码中评注如何描述图模式。可以看下图的例子：
+
+![Image](https://www-cdn.nebula-graph.com.cn/nebula-blog/the-origin-of-cypher.png)
+
+ASCII art 简单说，就是如何用可打印文本来描述点和边。Cypher 文本用`()`表示点，`-[]->`表示边。`(query)-[modeled as]->(drawing)` 来表示`起点 query`，`终点 drawing`，`边 modeled as`，这样一个最简单的图关系(也可以称为图模式)。
+
+Cypher 第一个版本实现了对图的读取，但是需要用户说明从哪些节点开始查询。只有从这些节点开始，才可以支持图的模式匹配。
+
+在后面的版本，2012 年 10 月发布的 Neo4j 1.8 中，Cypher 增加了修改图的能力。但查询还是需要指明从哪些节点开始。
+
+2013 年 12 月，Neo4j 2.0 引入了 label 的概念，label 本质上是个索引。这样，查询引擎就可以利用索引，来选择模式所匹配到的节点，而不需要用户指定开始查询的节点。
+
+随着 Neo4j 的普及，Cypher 有着广泛的开发者群体，在各行各业的得到广泛的使用。至今仍是最受欢迎的图查询语言。
+
+2015 年 9 月，Neo4j 发起成立了 openCypher Implementors Group（oCIG），将 Cypher 开放为 openCypher，通过开源的方式来治理和推进语言自身的演化。
+
+#### 后续
+
+Cypher 启发了一系列后续的图查询语言，包括
+
+2015 年，Oracle 发布图引擎PGX使用的图语言PGQL。
+
+2016 年，Linked Data Benchmarking Council, LDBC 是一个行业知名的图性能基准评测机构。LDBC 发布 G-CORE
+
+2018 年，基于 Redis 的图库(library) RedisGraph 采用 Cypher 作为其图语言
+
+2019 年，国际标准组织 ISO 启动两个项目，基于 openCypher, PGQL, GSQL[^GSQL], and G-CORE 等现有业界成果，启动图语言国际标准的制定过程
+
+[^GSQL]: https://docs.tigergraph.com/dev/gsql-ref
+
+2019 年，Nebula Graph 以 openCypher 为基础发布其扩展的图语言 Nebula Graph Query Language, nGQL。
+
+![Image](https://docs-cdn.nebula-graph.com.cn/books/images/langhis.jpg "图语言的历史")
+
+### 分布式图数据库
+
+大约 2005-2010 年，随着 Google 云计算"三驾马车"的发布，各种分布式的架构开始越来越流行，其中就包括以开源方式运作的 Hadoop 和 Cassandra 等。这里包括几个方面的影响：
+
+1. 由于数据量和计算量越来越大，相比于单机(例如 Neo4j)或者小型机这种方案，分布式系统的技术和成本优势更加明显；而同时，分布式系统使得应用程序在访问这成千上万台机器时，就如同访问本地的系统一样，不需要在代码层面进行过多改造；
+
+2. 开源方式使得更多的人（包括代码开发者、数据科学家、产品经理等）以更加低成本和有效的方式参与新兴的技术，并反馈给社区。
+
+严格说，Neo4j 也提供了不少的分布式的能力，但都和业界意义上的（对等、分片的）分布式系统有较大的不同:
+
+- Neo4j 3.X 要求全量数据必须存放在单机中。虽然其也提供多机之间(Master-slave/slave)做全量复制和高可用，但数据不可切分为不同子图存放。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/causal.png)
+
+- Neo4j 4.X 允许在不同机器上各存放一部分数据（子图），然后在应用层需通过一定方式拼装后(其称为编织 Fabric)[^fosdem20]，将读写分发到各个机器上。这种做法需要应用层代码有大量的参与和工作。例如，设计如何把不同子图应该放置在哪些机器上，如何将从各机器获取的部分结果重新编织为最终的结果。
+
+![](https://dist.neo4j.com/wp-content/uploads/20200131191103/Neo4j-Fabric-LDBC-sharding-scheme.jpg)
+
+[^fosdem20]: https://neo4j.com/fosdem20/
+
+其语法风格大体是
+```Cypher 
+USE graphA  # S1.1 从 Shard A 读
+MATCH (movie:Movie)
+Return movie.title AS title
+    UNION   # S2. 在代理服务器 Join 结果
+USE graphB  # S1.2 从 Shard B 读
+MATCH （move:Movie)
+RETURN movie.title AS title
+```
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/fabric.png)
+
+#### 第二代（分布式）图数据库：Titan 和其后继者 JanusGraph
+
+2011 年，Aurelius 公司成立，致力于开发一个开源的分布式图数据库 Titan[^titan]。到 2015 年 Titan 的第一个正式版发布，Titan 后端可以支持多种主流的分布式存储架构（例如 Cassandra, HBase, Elasticsearch, BerkeleyDB)，并可以复用 Hadoop 生态的诸多便利，前端以 Gremlin 为统一的查询语言。对于程序员使用、开发和社区参与都很方便。大规模的图，可以分片后存放在 HBase 或者 Cassarndar上(这些当时都已经是相对成熟的分布式存储方案)，Gremlin 语言虽然略微冗长但相对功能完备。整个方案在当时(2011-2015)体现了不错的竞争力。
+
+[^titan]: https://github.com/thinkaurelius/titan
+
+下图显示了 2012年 - 2015 年，Titan 和 Neo4j 在 GitHub.com 上 star 的增长情况。
+
+![Image](https://docs-cdn.nebula-graph.com.cn/books/images/titan-2015-neo4j.png)
+
+2015 年 Aurelius(Titan) 被 DataStax 收购，这之后 Titan 逐渐转变为一个闭源的商业产品 (DataStax Enterprise Graph)。
+
+在 Aurelius(Titan) 被收购后，市场对于开源分布式的图数据库一直仍有比较强烈的需求，而当时市场上成熟和活跃的产品并不多。大数据时代，数据仍在远快于摩尔定律的速度，源源不断的产生。Linux 基金会以及一些技术巨头(Expero, Google, GRAKN.AI, Hortonworks, IBM and Amazon) 在2017年，复制并分叉(fork)了原有的Titan项目，并启动为一个新项目 JanusGraph[^Janus]。之后大多数的社区工作，包括开发、测试、发布和推广都逐步转移到了新的 JanusGraph。
+
+[^Janus]: https://github.com/JanusGraph/janusgraph
+
+下图显示了两个项目2012-2021年日常代码提交(pull request)的变化情况，可以观察到几点：
+
+1. 即使 Aurelius(Titan) 2015 年被收购后，其开源代码仍有一定的活跃度(左侧)，但增速已经明显放缓。这体现了社区的力量。
+
+2. 新项目 JanusGraph 项目在 2017 年 1 月启动后，其社区迅速活跃起来，短短一年时间就超越了 Titan 过去 5 年累计的 pull request 数量。而与此同时，Titan 开源项目就此停滞。
+
+![Image](https://docs-cdn.nebula-graph.com.cn/books/images/titan-janus-dev.png)
+
+#### 同期知名产品 OrientDB, TigerGraph, ArangoDB, 和 DGraph
+
+此后更多的厂商加入整个市场，除了由Linux基金会托管的 JanusGraph，还有一些由商业公司主导开发的分布式图数据，各方采用的数据模型和访问方式也有明显的不同。
+本文不做一一介绍，仅简单列出主要区别。
+
+| 厂商名 | 创立时间 | 核心产品名 | 开源协议 | 数据模型 | 查询语言 | 
+| ----- | ----- | ----- | ----- | ----- | ----- |
+| OrientDB LTD (2017 年 被 SAP 收购) | 2011 | OrientDB | 开源 | 文档 + KV + 图 | OrientDB SQL (基于SQL扩展的图能力) |
+| GraphSQL (后改名 TigerGraph) | 2012 | TigerGraph | 商业版本 | 图(分析) | GraphSQL (类SQL风格) |
+| ArangoDB GmbH | 2014 | ArangoDB | Apache License 2.0 | 文档 + KV +  图 | AQL (同时操作文档, KV 和图) |
+| DGraph Labs | 2016 | DGraph | Apache Public License 2.0 + Dgraph Community License | 原 RDF，后改为 GraphQL | GraphQL+- |
+
+#### 传统巨头微软、亚马逊和甲骨文纷纷入场
+
+除了聚焦于图产品的厂商外，传统巨头也纷纷进入这个领域。
+
+Microsoft Azure Cosmos DB[^cosmos] 是一个在微软云上的多模数据库云服务，可以提供SQL、文档、图、key-value等多种能力；
+Amazon AWS Neptune[^neptune] 是一种由 AWS 提供图数据库云服务, 可以提供属性图和 RDF 两种数据模型；
+Oracle graph[^Oracle] 是关系型数据库巨头 Oracle 在图技术与图数据库方向的产品。
+
+[^cosmos]: https://azure.microsoft.com/en-us/free/cosmos-db/
+
+[^neptune]: https://aws.amazon.com/cn/neptune/
+
+[^Oracle]: https://www.oracle.com/database/graph/
+
+#### 新一代开源分布式图数据库 Nebula Graph
+
+在下一章，我们将正式介绍新一代开源分布式图数据库 Nebula Graph。
diff --git a/docs-2.0/1.introduction/0-2.relates.md b/docs-2.0/1.introduction/0-2.relates.md
new file mode 100644
index 00000000000..78b22e4a91a
--- /dev/null
+++ b/docs-2.0/1.introduction/0-2.relates.md
@@ -0,0 +1,251 @@
+# 相关技术
+
+本节主要介绍两个和分布式图数据库关系密切的领域，数据库方面和图技术方面。
+
+## 数据库方面
+
+### 关系型数据库
+
+关系型数据库，是指采用了关系模型来组织数据的数据库。关系模型为二维表格模型，一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。说到关系型数据库，大多数人都会想到 MySQL。MySQL 是目前最流行的数据库管理系统之一，支持使用最常见的结构化查询语言（SQL）进行数据库操作，并以表格、行、列的形式存储数据。这种存储数据的方法源自埃德加·科德（Edgar Frank Codd）于 1970 年提出的关系型数据模型。
+
+在关系型数据库中，可以为待存储的每种类型的数据创建一个表。例如，球员表用来存储所有的球员信息，球队表用来存储球队信息等。SQL 表中的每行数据都必须包含一个主键（primary key）。主键是该行数据的唯一标识符。一般地，主键作为字段 ID 都是随行数自增的。关系型数据库自问世以来一直为计算机行业提供着非常好的服务，并将未来很长的时间内继续服务下去。
+
+如果你用过 Excel、WPS 或其他类似的应用，你就会大概了解到关系数据库是如何工作的。首先设置好列，然后在对应的列下添加行数据。你可以对某一列数据进行求平均值或其他聚合操作，这与在关系型数据库 MySQL 中求平均值的操作类似。而 EXcel 中的数据透视表则相当于在关系型数据库 MySQL 中使用聚合函数和 CASE 语句对数据进行查询。一个 EXcel 文件可以有多张表，一张表就相当于 MySQL 的一张表。一个 EXcel 文件则类似于一个 MySQL 数据库。
+
+#### 关系型数据库中的关系
+
+与图数据库不同，关系型数据库（或 SQL 型的数据库）中的边也是作为实体存储在专门的边表中的。先创建两个表，球员（player）和球队（team），然后再创建表 player_team 作为边表。边表通常由相关的表 join 而成。例如，此处的边表 player_team 就由球员表和球队表 join 而成。
+
+![image](https://user-images.githubusercontent.com/42762957/91702816-dc872200-ebab-11ea-8b36-577c29a3fe7a.png)
+
+这种存储边的方式在关联小型数据集时问题并不大，但是当关系型数据库中的关系太多时，问题就出现了。事实上，关系型数据库是非常“反关系的”。具体来说，当你只想查询一个球员的队友时，你必须对表中的所有数据进行 join 操作，然后再过滤掉你不需要的所有数据，当你的数据集达到一定规模时，这将给关系型数据库带来巨大压力。如果你想关联多张不同的表，可能在 join 爆炸（join bombs）前系统就已经无法响应了。
+
+#### 关系型数据库起源
+
+上文提到，关系型数据模型最早是由 IBM 的工程师埃德加·科德（Edgar Frank Codd）于 1970 年提出的。科德写了几篇数据库管理系统方面的论文，论述了关系型数据模型的潜力。关系型数据模型不依赖于数据链接列表（网状数据或层级数据），而是更多依赖于数据集。他使用元组演算（tuple calculus）的数学方法论证了这些数据集能够完成与导航数据库管理系统相同的任务。唯一的要求是，关系型数据模型需要一种合适的查询语言，以保证数据库的一致性要求。这就为后来声明型的结构化查询语言（SQL）提供了灵感来源。IBM 的 R 系统是关系型数据模型的最早使用者之一。然而，由前 IBM 员工拉里·埃里森创办的名叫软件开发实验室的小公司在市场上击败了 IBM。该公司的产品就是后来为我们熟知的 Oracle。
+
+由于“关系数据库”在当时是一个比较时髦的词汇，因此许多数据库供应商都喜欢在其产品名称中使用这个词汇，尽管他们的产品实际上并不是关系型的。为了防止这种情况并减少关系型数据模型的错误使用，科德提出了著名科德 12 定律（Codd's 12 rules）。所有关系型数据系统都必须遵循科德 12 定律。
+
+### NoSQL 数据库
+
+图数据库并不是可以克服关系型数据库缺点的唯一替代方案。现在市面上还有很多非关系型数据库的产品，这些产品都可以叫做 NoSQL。NoSQL 一词最早于上世纪 90 年代末提出，可以解释为“非 SQL” 或“不仅是 SQL”，具体解释要根据语境判断。为便于理解，这里 NoSQL 可以解释成 “非关系型数据库”。不同于关系型数据库，NoSQL 数据库提供的数据存储、检索机制并不是基于表关系建模的。 NoSQL 数据库可以分为四类：
+
+- 键值存储（key-value stores）
+- 列式存储（column-family stores）
+- 文件存储（document stores）
+- 图数据库（graph databases）
+
+下面将分别介绍这四类数据库。
+
+#### 键值存储
+
+键值存储，顾名思义，就是使用键值对存储数据的数据库。不同于关系型数据库，键值存储是没有表和列的。如果一定要做类比，键值数据库本身就像一张有很多列（也就是键）的大表。在键值存储数据库中，数据（即键值对中的值）都是通过键来存储和查询的，通常用哈希列表来实现。这比传统的 SQL 数据库要简单得多，而且对于某些 web 应用来说，这就足够了。
+
+键值模型对于 IT 系统来说优势在于简单、易部署。多数情况下，这种存储方式对非关联的数据很适用。如是只是存储数据而无需查询的话，使用这种存储方法就没有问题。但是如果 DBA 只对部分值进行查询或更新的时候，键值模型就显得效率低下了。常见的键值存储数据库有：Redis、Voldemort、Oracle BDB。
+
+#### 列式存储
+
+NoSQL 数据库的列式存储与 NoSQL 数据库的键值存储有许多相似之处，因为列式存储仍然在使用键进行存储和检索。区别在于列式存储数据库中，列是最小的存储单元，每一列均由键、值以及用于版本控制和冲突解决的时间戳组成。这在分布式扩展时特别有用，因为在数据库更新时，可以使用时间戳定位过期数据。由于列式存储良好的扩展性，因此适用于非常大的数据集。常见的列式存储数据库有：HBase、Cassandra、HadoopDB 等。
+
+#### 文档存储
+
+准确来说，NoSQL 数据库文档存储实际上也是基于键值的数据库，只不过对功能做了增强。数据仍然以键值的形式存储，但是文档存储中的值是结构化的文档，而不仅仅是一个字符串或单个值。也就是说，由于信息结构的增加，文档存储能够执行更优化的查询，并且使数据检索更加容易。因此，文档存储特别适合存储、索引并管理面向文档的数据或者类似的半结构化数据。
+
+从技术上讲，作为一个半结构化的信息单元，文档存储中的文档可以是任何形式可用的文档，包括 XML、JOSN、YAML 等，这取决于数据库供应商的设计。 比如，JSON 就是一种常见的选择。虽然 JSON 不是结构化数据的最佳选择，但是 JSON 型的数据在前端和后端应用中都可以使用。常见的文档存储数据库有：MongoDB、CouchDB、Terrastore 等。
+
+#### 图存储
+
+最后一类 NoSQL 数据库是图数据库。本书重点讨论的 Nebula Graph 也是一种图数据库。虽然同为 NoSQL 型数据库，但是图数据库与上述 NoSQL 数据库有本质上的差异。图数据库以点、边、属性的形式存储数据。其优点在于灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱。我们将在随后的章节中详细讨论图数据库。不过在本章中，你只要知道图数据库是一种 NoSQL 类型的数据库就可以了。常见的图数据库有：Nebula Graph、Neo4j、OrientDB 等。
+
+## 图技术方面
+
+来看一张 2020 年的图技术全景[^lan]
+
+[^lan]: https://graphaware.com/graphaware/2020/02/17/graph-technology-landscape-2020.html
+
+![Image](https://raw.githubusercontent.com/GraphCoding/graph-technology-landscape/master/GraphTechnologyLandscape.jpg)
+
+和图有关联的技术有很多，可以大致分为这么几类：
+
+- 基础设施：包括图数据库、图计算(处理)引擎、图深度学习、云服务等。
+
+- 应用：包括可视化、知识图谱、反诈骗、网络安全、社交网络等。
+
+- 开发工具：包括图查询语言、建模工具、开发框架和库。
+
+- 电子书籍[^info]和会议等。
+
+[^info]: 学习目的(非商业用途)可以联系[作者]((mailto:min.wu@vesoft.com)获取电子版。
+
+
+<!-- TODO from VLDB 2019
+### 分类法
+
+-->
+
+### 图语言
+
+在上一节中，我们介绍了图语言的历史。在这一节中，我们对图语言的功能做一个分类：
+
+- 近邻查询：查询给定点或者边的邻边、邻点，或者是 K 跳的近邻。
+
+- 图模式匹配(Pattern matching)：找到一个/所有的子图，满足给定的图模式；这个问题非常接近于"子图同构映射(subgraph isomorphism)"——虽然两个看上去不同的图，但其实是一模一样的[^subiso]。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/samegraph.png)
+
+[^subiso]: https://en.wikipedia.org/wiki/Graph_isomorphism
+
+- 可达性（连通性）问题：最常见的可达性问题就是最短路径问题。泛化一些，这类问题通常用正则路径(Regular Path Query)的方式来描述——一系列联通的点组构成了一条路径，而该路径需要满足某种正则表达。
+
+- 分析型问题：通常与一些汇聚型算子相关（平均值、count、最大值、点的出入度），或者度量所有两两点之间的距离、某节点与其他节点之间的互动程度（介数中心性）等。
+
+### 图数据库(Graph Database)与图处理(Graph processing)系统
+
+一个图系统通常会涉及到复杂的数据流水线[^biggraph]，从数据源(左边)到处理输出(右边)，会经过多个数据加工处理环节和系统；大的模块可以分为 ETL模块，图数据库系统(Graph OLTP)，图处理系统(Graph OLAP)，基于图引擎的应用系统（BI、知识图谱等）。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/graphpipe.png)
+
+[^biggraph]: The Future is Big Graphs! A Community View on Graph Processing Systems. https://arxiv.org/abs/2012.06171
+
+虽然这两类系统都是与图数据和图技术相关的系统，也处理类似的目标，但是他们有着不同的起源和特长（及弱点）：
+
+- （在线）图数据库目标是图的持久化存储管理、高效的子图操作。硬盘（及网络）是目标运行设备，物理/逻辑数据映射，数据完整性和（故障）一致性是主要目标。每一个请求通常只会涉及到全图的一小部分，通常可以在一台服务器上完成；单个请求时延通常在毫秒到秒级别，请求并发量通常在几千到几十万。早期的 Neo4j 是图数据库领域的起源之一。
+
+- （离线）图处理系统目标是全图的大批量、并行、迭代、处理与分析，内存（及网络）是目标运行设备。每一个请求会涉及到所有的图节点，需要所有的服务器参与完成；单个请求的时延通常在分钟到小时（天），请求并发量通常为个位数。Google 的 Pregel[^Pregel] 是图处理系统的典型起源代表，它的点中心编程抽象与BSP的运行模式构成的编程范式，相比之前 Hadoop Map-Reduce 是更为图友好的 API 抽象。
+
+[^Pregel]: G. Malewicz, M. H. Austern, A. J. Bik, J. C. Dehnert, I. Horn, N. Leiser, and G. Czajkowski. Pregel: a system for large-scale graph processing. In Proceedings of the International Conference on Management of data (SIGMOD), pages 135–146, New York, NY, USA, 2010. ACM
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/databaseandprocess.png)
+[^iga]
+
+[^iga]: https://neo4j.com/graphacademy/training-iga-40/02-iga-40-overview-of-graph-algorithms/
+
+### 图的分片方式
+
+对于一个大规模的图数据来说，是很难存放在单个服务器的内存中的，即使仅仅存放图结构本身也不够。而且通过增加单服务器的能力，其成本价格通常成指数级别上升。
+此外，随着数据量的增加，例如到达千亿级别的时候，已经超过了市面上所有商用服务器的容量能力。
+
+于此对应的，另外一个经常使用的方案，是对数据进行分片，并将每个分片放置在不同的服务器上（并进行冗余备份），以此来增加可靠性和性能。对于一些 NoSQL 型的系统，例如 key-value 或者文档型的系统来说，这个分片方式是比较直观和自然的；通常可以根据 key 或者 docID，来将每个记录或者数据单元(key-value, doc)放在不同的服务器上。 
+
+但是图这种数据结构的分片通常不那么直观，这是因为通常图是“全联通”的，每个点通常只要6跳就可以联通到其他任何节点；
+而理论上早已证明图的划分问题是 NP 的。
+与此同时，当把整个图数据分散到多个服务器时，跨服务器的网络访问时延10倍于同一个服务器内部的硬件(内存)访问时间；因此对于一些深度优先遍历的场景，会发生大量的跨网络访问，导致整体时延极高。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/lessrpc.png)[^gpml]
+
+[^gpml]: https://livebook.manning.com/book/graph-powered-machine-learning/welcome/v-8/
+
+另一方面，通常图有着明显的幂律分布；少量节点的邻边稠密程度远大于平均的节点，虽然处理这些节点通常可以在同一台服务器内，减少了跨网络访问，但这也意味着这些服务器压力会远大于平均。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/Power_Law_Distribution.png)
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/singleserver.png)
+
+因此，常见的图分片(Sharding)方式有几类：
+
+- 偏应用层面的分片：应用层感知并控制每个点和边应该落在哪个分片上，一般来说可以根据点和边的类型（比如业务意义来人为）判断。将一组相同类型的点放在一个分片，另一组相同类型的点放在另一个分片。当然，为了高可靠，分片本身还可以做多副本。在应用使用时，从各个分片取回所要的点和边，然后在偏应用侧（或者某个代理服务器端），将取回的数据拼装成最终的结果。其典型代表是 Neo4j 4.x 的 Fabric。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/neo4j4x.png)
+
+- 使用分布式的缓存层：在硬盘之上增加内存缓存层，并对重要的部分分片和数据（例如图结构）进行缓存，并预热这部分缓存。
+
+- 增加（只读）副本或视图 (View)：为部分图分片增加只读的副本或者建立一个视图，将较重的读请求负载通过这些分片服务器承担。 
+
+- 进行细颗粒度的图划分：例如将点和边组成多个小分片（Partition），而不是一台服务器一个大分片（Sharding)，再将关联性较强的 Partition 尽量放置在同一个服务器上[^arr]。 
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/smartgraph.png)
+
+[^arr]: https://www.arangodb.com/learn/graphs/using-smartgraphs-arangodb/
+
+具体工程实践时，也会混合使用上述几种方式。通常，离线的图处理系统会通过一个ETL过程，将图进行一定程度的预处理以提高局部性；而在线图数据库系统通常会选择周期性的数据再平衡过程来提高数据局部性。
+
+### 一些技术上的挑战
+
+在文献[^Ubiquity]中，对于无处不在的大图和挑战做了详尽的调研，下面是其列出的十大图技术挑战：
+
+[^Ubiquity]: https://arxiv.org/abs/1709.03188
+
+
+- 可扩展性(软件可以处理更大的图规模): 包括大图的加载、更新、图计算和图遍历，触发器，超级节点；
+- 可视化：可定制布局，大图的渲染，多层次展示，动态（更新）的展示
+- 查询语言和编程 API：包括语言表达能力、标准兼容性、与现有系统的兼容性；子查询的设计和跨多图之间的关联查询
+- 更快的图（及机器学习）算法
+- 易用性（配置和使用）
+- 性能指标与测试
+- 更通用的图技术软件（例如，处理离线、在线、流式的计算）
+- 图清洗（ETL）
+- Debug 调试与测试
+
+### 一些开源的单机图工具
+
+对于图数据库通常会有一个误解，只要涉及到图结构的数据存取就需要存放在图数据库中。这通常是一种误解。
+
+当数据量并不大时，通常单机内存可以放下，例如数据量几千万的点边关系，使用一些单机的开源工具也可以取得很好的效果。
+
+- JGraphT[^JGraphT]: 一个知名的开源 Java 图论库(library)，其实现了相当多的高效图算法。
+
+[^JGraphT]: https://jgrapht.org/
+
+- igraph[^igraph]: 一个轻量且功能强大的 Library, 支持R、python、C
+
+[^igraph]: https://igraph.org/
+
+- NetworkX[^NetworkX]: 数据科学家做图论分析第一选择， python。
+
+[^NetworkX]: https://networkx.org/
+
+- Cytoscape[^Cytoscape]: 功能强大的可视化开源图分析工具。
+
+[^Cytoscape]: https://cytoscape.org/
+
+- Gephi[^Gephi]: 功能强大的可视化开源图分析工具。
+
+[^Gephi]: https://gephi.org/
+
+- arrows.app[^Arrow]： 非常简单的脑图工具，用于可视化生成 Cypher 语句.
+
+[^Arrow]: https://arrows.app/
+
+### 一些行业数据集和 Benchmark
+
+#### LDBC
+
+关联数据基准委员会（LDBC[^LDBC]，Linked Data Benchmark Council）是由Oracle、Intel等软硬件巨头和主流图数据库厂商Neo4j和TigerGraph等组成的非赢利机构，是图的基准指南制定者与测试结果发布机构，在行业内有着很高的影响力。
+
+[^LDBC]:https://github.com/ldbc/ldbc_snb_docs
+
+社交网络基准测试（SNB，Social Network Benchmark）是由关联数据基准委员会（LDBC）开发的面向图数据库的基准测试（Benchmark）之一，分为交互式查询（Interactive）和商业智能（BI）两个场景。其作用类似于 TPC-C, TPC-H 等测试在 SQL 型数据库中的功能，可以帮助用户比较多种图数据库产品的功能、性能、容量。
+
+SNB 数据集模拟一个社交网络的人、发帖之间的关系，考虑了社交网络的分布属性、人的活跃度等等社交信息。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/ldbc.png)
+
+其标准数据量从 0.1 GB (scale factor 0.1) 到 1000 GB (sf1000)，也可以生成 10 TB，100 TB等更大的数据集；其点、边数量如下表。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/ldbcsf.png)
+
+
+## 一些趋势
+
+### 虽然图的各种技术起源和目标并不相同，但在相互借鉴和融合
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/convergenceofcapability.png)
+
+### 上云的趋势在加速，对于弹性能力提出更高要求
+
+根据 Gartner 的预计，云服务一直保持较快的增速和渗透率[^cl]。大量的商业软件，正在从 10 年前完全私有本地逐步转向基于云服务的商业模式。
+云服务的一大优点是其提供了近乎无限的弹性能力；这也要求各种基于云基础设施的软件必须有更好的快速弹性扩缩容能力。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/cloudtrends.png)
+
+[^cl]: https://cloudcomputing-news.net/news/2019/apr/15/public-cloud-soaring-to-331b-by-2022-according-to-gartner/
+
+### 硬件趋势，SSD 将成为主流的持久化设备
+ 
+硬件决定了软件的架构——从发现摩尔定律的 50 年代到进入多核的 00 年代，硬件发展趋势和速度一直深刻的决定了软件的架构。数据库类系统大多围绕“硬盘+内存”设计，高性能计算型系统大多围绕“内存 + CPU”设计，分布式系统面对千兆、万兆和 RDMA 网卡的设计也完全不同。
+
+图基于拓扑的遍历有着极其明显的随机访问特点，因此大多数早期图数据库系统都采用了“大内存 + HDD” 的架构————通过设计**常驻**在内存中的一些数据结构（例如B+树、Hash表等），在内存中实现随机访问目的，以优化图的拓扑遍历，再将这些随机访问转换成 HDD 所适合的顺序读写。整套软件的架构（包括存储和计算层）都必须基于和围绕这样的 IO 流程来展开。随着 SSD 价格的快速下降[^ssdhdd]，SSD 正在替代 HDD 成为持久化设备的主流。SSD 随机访问友好、IO 队列深、按快存取的特点与 HDD 高度顺序、随机时延极高、磁道易损坏的访问特点有着明显的不同。全部的软件架构也需要重新设计，这成为沉重的历史技术负担。
+
+![](https://docs-cdn.nebula-graph.com.cn/books/images/ssdhdd.png)
+
+[^ssdhdd]: https://blocksandfiles.com/2021/01/25/wikibon-ssds-vs-hard-drives-wrights-law/
diff --git a/docs-2.0/20.appendix/history.md b/docs-2.0/20.appendix/history.md
new file mode 100644
index 00000000000..3b00e0fcd92
--- /dev/null
+++ b/docs-2.0/20.appendix/history.md
@@ -0,0 +1,34 @@
+# Nebula Graph 年表
+
+1. 2018.9.5 由 @[dutor](https://github.com/dutor) 提交了第一行代码。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/dutor.png)
+
+2. 2019.5 发布了 v0.1.0 alpha 版本, 并开源。
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/alpha-bj.png)
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/alpha-hz.jpg)
+ 
+此后一年内陆续发布 v1.0.0-beta, v1.0.0-rc1, v1.0.0-rc2, v1.0.0-rc3, v1.0.0-rc4
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/v010.png)
+
+3. 2019.7 在 HBaseCon 第一次公开亮相[^Hbasecon]@[dangleptr](https://github.com/dangleptr)
+
+![image](https://www-cdn.nebula-graph.com.cn/nebula-blog/HBase01.png)
+
+[^Hbasecon]: Nebula Graph 1.x 版本支持 RocksDB 和 HBase 两种主要的后端，但在 Nebula Graph 2.x 版本取消了默认对 HBase 的支持。
+
+3. 2020.3 在 v1.0 开发的收尾阶段，启动了 v2.0 项目的研发
+
+4. 2020.6 发布了第一个正式大版本 v1.0.0 GA
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/v100GA.png)
+
+5. 2021.3 发布了第二个大版本 v2.0 GA
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/v200.png)
+
+6. 2021.8 发布 v2.5.0
+
+![image](https://docs-cdn.nebula-graph.com.cn/books/images/2.5.0.png)
diff --git a/mkdocs.yml b/mkdocs.yml
index 25cfb191b6b..55fb0bd56e9 100755
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -124,6 +124,9 @@ extra:
 nav:
   - 前言: README.md
   - 简介:
+      - 图: 1.introduction/0-0-graph.md
+      - 图数据库: 1.introduction/0-1-graph-database.md
+      - 相关技术: 1.introduction/0-2.relates.md
       - 什么是 Nebula Graph: 1.introduction/1.what-is-nebula-graph.md
       - 数据模型: 1.introduction/2.data-model.md
       - 路径: 1.introduction/2.1.path.md
@@ -517,6 +520,7 @@ nav:
       - 生态工具概览: 20.appendix/6.eco-tool-version.md
       - 导入工具选择: 20.appendix/write-tools.md
       - 社区参与: 15.contribution/how-to-contribute.md
+      - 年表: 20.appendix/history.md
       - 思维导图: 20.appendix/mind-map.md
 
   - English Docs: https://docs.nebula-graph.io/
@@ -539,38 +543,38 @@ markdown_extensions:
   - pymdownx.arithmatex:
       generic: true
 
-# Plugins
-plugins:
-  - search
-  - macros:
-      include_dir: docs-2.0/reuse/
-  - git-revision-date-localized
-
-  - exclude:
-# Exclude files with unix-style wildcards (globs)
-      glob:
-# Exclude all files in a directory. The path starts with the directory name in docs-2.0, such as `20.appendix/*`.
-        - nebula-flink/*
-        - CHANGELOG.md
-        - spark-connector/*
-        - nebula-operator/*
-        - 4.deployment-and-installation/5.zone.md
-        - 4.deployment-and-installation/3.upgrade-nebula-graph/upgrade-nebula-from-200-to-latest.md
-        - nebula-cloud/*
-# Exclude the file with the following file name.
-#        - abc.md
-# Exclude files with regular expressions (regexes)
-#    regex:
-#      - '.*\.(tmp|bin|tar)$'
-
-  - with-pdf:
-      copyright: 2022 vesoft Inc.
-      cover_subtitle: v3.0.0
-      author: 吴敏，周瑶，梁振亚，杨怡璇，黄凤仙
-      cover: true
-      back_cover: true
-      cover_logo: 'https://cloud-cdn.nebula-graph.com.cn/nebula-for-pdf.png'
-      output_path: pdf/NebulaGraph-CN.pdf
+# # Plugins
+# plugins:
+#   - search
+#   - macros:
+#       include_dir: docs-2.0/reuse/
+#   - git-revision-date-localized
+
+#   - exclude:
+# # Exclude files with unix-style wildcards (globs)
+#       glob:
+# # Exclude all files in a directory. The path starts with the directory name in docs-2.0, such as `20.appendix/*`.
+#         - nebula-flink/*
+#         - CHANGELOG.md
+#         - spark-connector/*
+#         - nebula-operator/*
+#         - 4.deployment-and-installation/5.zone.md
+#         - 4.deployment-and-installation/3.upgrade-nebula-graph/upgrade-nebula-from-200-to-latest.md
+#         - nebula-cloud/*
+# # Exclude the file with the following file name.
+# #        - abc.md
+# # Exclude files with regular expressions (regexes)
+# #    regex:
+# #      - '.*\.(tmp|bin|tar)$'
+
+#   - with-pdf:
+#       copyright: 2022 vesoft Inc.
+#       cover_subtitle: v3.0.0
+#       author: 吴敏，周瑶，梁振亚，杨怡璇，黄凤仙
+#       cover: true
+#       back_cover: true
+#       cover_logo: 'https://cloud-cdn.nebula-graph.com.cn/nebula-for-pdf.png'
+#       output_path: pdf/NebulaGraph-CN.pdf
 
 extra_javascript:
   - js/version-select.js

From 9619bcfec9ce09c490db0b7e1a199cfd6a3d907e Mon Sep 17 00:00:00 2001
From: Abby <78209557+abby-cyber@users.noreply.github.com>
Date: Fri, 25 Feb 2022 14:05:25 +0800
Subject: [PATCH 2/2] Update mkdocs.yml

---
 mkdocs.yml | 64 +++++++++++++++++++++++++++---------------------------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/mkdocs.yml b/mkdocs.yml
index 55fb0bd56e9..d82d74fdfb2 100755
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -543,38 +543,38 @@ markdown_extensions:
   - pymdownx.arithmatex:
       generic: true
 
-# # Plugins
-# plugins:
-#   - search
-#   - macros:
-#       include_dir: docs-2.0/reuse/
-#   - git-revision-date-localized
-
-#   - exclude:
-# # Exclude files with unix-style wildcards (globs)
-#       glob:
-# # Exclude all files in a directory. The path starts with the directory name in docs-2.0, such as `20.appendix/*`.
-#         - nebula-flink/*
-#         - CHANGELOG.md
-#         - spark-connector/*
-#         - nebula-operator/*
-#         - 4.deployment-and-installation/5.zone.md
-#         - 4.deployment-and-installation/3.upgrade-nebula-graph/upgrade-nebula-from-200-to-latest.md
-#         - nebula-cloud/*
-# # Exclude the file with the following file name.
-# #        - abc.md
-# # Exclude files with regular expressions (regexes)
-# #    regex:
-# #      - '.*\.(tmp|bin|tar)$'
-
-#   - with-pdf:
-#       copyright: 2022 vesoft Inc.
-#       cover_subtitle: v3.0.0
-#       author: 吴敏，周瑶，梁振亚，杨怡璇，黄凤仙
-#       cover: true
-#       back_cover: true
-#       cover_logo: 'https://cloud-cdn.nebula-graph.com.cn/nebula-for-pdf.png'
-#       output_path: pdf/NebulaGraph-CN.pdf
+# Plugins
+plugins:
+  - search
+  - macros:
+      include_dir: docs-2.0/reuse/
+  - git-revision-date-localized
+
+  - exclude:
+# Exclude files with unix-style wildcards (globs)
+      glob:
+# Exclude all files in a directory. The path starts with the directory name in docs-2.0, such as `20.appendix/*`.
+        - nebula-flink/*
+        - CHANGELOG.md
+        - spark-connector/*
+        - nebula-operator/*
+        - 4.deployment-and-installation/5.zone.md
+        - 4.deployment-and-installation/3.upgrade-nebula-graph/upgrade-nebula-from-200-to-latest.md
+        - nebula-cloud/*
+# Exclude the file with the following file name.
+#        - abc.md
+# Exclude files with regular expressions (regexes)
+#    regex:
+#      - '.*\.(tmp|bin|tar)$'
+
+  - with-pdf:
+      copyright: 2022 vesoft Inc.
+      cover_subtitle: v3.0.0
+      author: 吴敏，周瑶，梁振亚，杨怡璇，黄凤仙
+      cover: true
+      back_cover: true
+      cover_logo: 'https://cloud-cdn.nebula-graph.com.cn/nebula-for-pdf.png'
+      output_path: pdf/NebulaGraph-CN.pdf
 
 extra_javascript:
   - js/version-select.js