导读： 本文将从什么是图数据库，以及为什么要做图数据库开始，介绍 TuGraph 的特性以及未来规划。

介绍围绕下面三点展开：

1. 图数据库简介

2. TuGraph 简介

3. TuGraph 规划

---

分享嘉宾｜林恒博士 蚂蚁集团 蚂蚁开源图数据库负责人

编辑整理｜罗春海 佛山大学

出品社区｜DataFun

---

01/图数据库简介

1. 图是新型的数据模型，更适合表达事务及其相互关联关系

以经典的员工和公司关系为例：公司雇佣员工、员工 A 与员工 B 是好友关系、员工 C 参加某个项目等。

① 第一，这里所讲的"图"是图论里的"图（Graph）"，不是图片里的"图（Image）"。

② 第二，用图去表达的方式，天然地与直观理解相似，或者说与我们在黑板上跟别人描述事物的方式相同。图在数据存储的时候，点和边以及模型与实际场景是匹配。

③ 第三，如果这类数据放到传统的数据库中，其实就是关系型数据库（如 MySQL），可能会产生很多表。这里的案例是需要 6 张表，在数据建表过程中，需要填写每位员工的信息，人之间的雇佣关系。总体来说不是特别直观，具有一定入门门槛。

2. 图模型的表达能力强于关系模型

除了模型表达，图能解决什么问题呢？

**① 第一类问题：**基于模型建立出来后，可以在上面做查询。如果是简单的查询，类似于查询某个员工的年龄，那其实关系型数据库和图中表达是差不多的，只需要去查某个表或者某个边就行。

**② 第二类问题：**另外一类查询，比如查所有雇员数大于 5 的公司。在原来的关系型数据库中，需要查询雇佣关系表，以及它的记录数大于 5 的公司，是一句较为繁杂的 SQL 语句。在图里面，问题会变成去找某个顶点的某属性边数目，该顶点是一家公司，同时它雇佣的边数大于 5。

**③ 第三类问题：**当我们希望查员工 A 和员工 C 有什么关系，在关系型数据库里面，我们需要查询各种表。因为他们有的是好友关系，有的是受雇于同一家公司，通过多张表的查询，可以获得所需信息。但如果在图模型里面就比较简单了，只要查两个员工之间有什么路径，而这条路径就代表他们之间的关系。

**④ 第四类问题：**除了查这种直接关系之外，还可以查询间接关系，因为路径可以是两跳或者三跳，就相当于是一个深链分析，或者是深度隐藏的数据。这在关系型数据库中非常难表达，而在图里面只要查路径就可以了。所以对于基于关联关系的数据，图模型的表达能力要远高于关系型数据库的表达能力。

3. 图模型在各个领域受到广泛关注

图的应用范围很广。

**① 社交网络：**比如微博，我关注了姚晨，那其实就是两个账号之间有条关注的（无向）边。

**② 设备网络：**比如在电网，电线杆和电线杆之间连接的网络，以及我们家里的电是怎么通过发电厂传输过来，它们之间由电路组成的设备网络。

**③ 交通路网：**比如公路，A 到 B 存在一条路径，基于这个网络就可以分析，从我们这里去海南，哪条路比较方便。

**④ 供应链：**比如笔记本，其中键盘、CPU、内存这些硬件是从哪里采购的，每个零部件的下游又是从什么地方采购的，因此供应链也是一种图的关系。

**⑤ 资金交易网：**资金交易，在蚂蚁公司内部使用广泛，比如通过支付宝转账的交易记录，就可以做一些反欺诈调查。再比如一些不合规的贷款，都可以从资金网络里面去分析出来。

**⑥ 脑神经网络：**更深一点，比如脑神经网络，图的作用就非常大。我们人脑有数百亿的神经元，这些神经信号传递的数据规模，可能不止万亿而是百万亿。神经元是如何从突触去连接的，也是一个点和边的关系，如果我们能把这部分研究好，也非常有助于理解人脑是如何工作的。

4. 图数据库近 10 年越来越受关注

http://DB-Engines.com 是一个记录数据库发展态势的网站：包括 KV 存储数据库（KEY-VALUE STORES）、关系型数据库、时序数据库。根据综合指标，来评价数据库受关注的程度。

可以看到，图数据库发展受关注的情况，从 2013 年开始，图数据库的发展趋势一骑绝尘，处于蓬勃发展期。

5. 图技术已成为许多现代数据和分析能力的基础

最近商业分析公司 Gartner，预测图技术在 2021 年，数据分析和创新中占的比例较低只有 10%，但是预计到 2025年，图技术在数据和分析创新中的比例将会占到 80%。在未来的几年里面，图的应用落地会变得越来越普遍。

6. 图市场方兴未艾

这是另外一个数据，现在图的市场规模。

可以看到有两列蓝色的和绿色的直方图，

① 蓝色（中国国内图相关应用核心产品市场规模）：2019 年是 65 亿，2020 年上 82 亿，2025 将达到 237.9 亿。

② 绿色（中国国内图应用带动经济增长规模）：如果算上图应用带动的经济增长，那数据就非常大了。

全世界数据库的市场规模大约在千亿级，图大概是在几亿的规模。它在整个数据库的领域里面，目前是占到 1% 以内，后面会增长到 10% 左右，在未来几年里会发展得非常迅速。

7. 图数据库发展三阶段

我们认为图的发展分成三个阶段：

① 第一阶段： 一开始有一些事情不用图做不了，我们称为使能阶段。现在大部分金融行业都处在这个阶段。

② 第二阶段： 有些场景用关系型数据库也可以，但是用图更好，称为优化阶段 。用图能降低建模成本，提高机器利用率。现在蚂蚁就处于这个优化阶段。

**③ 第三阶段：**图技术普及之后，一开始就可以用图去构思，用图去解决反欺诈、数据分析等问题。图会成为更符合我们大部分人的直觉建模和解决问题的过程，这是我们要一起努力的目标。

8. 什么时候应该用图

什么时候能用图呢？

图的主体是点和边，图就是用来表达点和边的关联关系。现在经常讲万物互联或者物联网时代，这种关联关系就特别适合用图去解决问题。我们可以去找路径、关系、群体。

9. 图模型的优势与挑战

图具备优势，同时也存在挑战：

**① 优势：**图是更自然的关系表达方式，不需要进行分表操作。图本身是万物互联的关系，使得数据所见即所存。实际上看到的模型和存储到数据库中是一致的。图具有更强的兼容性，在数据治理方面，可以很好的处理传统关系型数据库中庞大复杂的表之间关系。图的点、边不需要太多限制，就可以轻松把各种异构数据放到同个图中。举个例子，图能够将蛋白质的关联关系、分子结构以及已有研究放到同一个图中，图模型可以容纳更多的数据源，并轻松的处理它们之间的关系，当数据量足够时便可以轻松地把这些数据都使用起来，推导出更好的结果。此外，图能做很多更灵活的算法设计，比如寻找路径、发现群体等。

**② 挑战：**图带来巨大好处的同时，对底层的数据库、模型也提出了更高的要求，因为假若真需要万物互联，数据量就会十分庞大，十亿、百亿都非常正常。另外，图里面有另一个非常大的问题，是负载均衡问题。举个例子，比如微博，有的人是大 V 博主，拥有好几亿的粉丝。我们去分析目标点的时候，会发现分析他所需要的资源，会比分析普通的用户所需的计算量大非常多。所以数据的密率分布也会造成严重的负载均衡问题。另外，图操作的性能瓶颈主要是数据访问，而非注CPU 使用率。下文中会讲到 TuGraph 的解决方案。

--

02/TuGraph 简介

1. TuGraph 背景

（1）2016 年

**北京费马科技成立：**致力于图数据的研发和商业化。

（2）2017 年

**Alpha 版本发布：**彼时 TuGraph 用 LightGraph 的名字。

（3）2020 年

**①（07 月）通过 LDBC-SNB 测试：**功能完善之后，由于 TuGraph 做的是面向高性能，因此做了 LDBC 的 SNB（在社交图中进行模拟真实查询场景）的测试（类似于数据库性能 TPC-C 测试），测出了非常好的值，就拿到了榜一，打破了原记录。

**②（11 月）费马科技并入蚂蚁集团产品融合：**我们这波人更想注重于技术开发，就和蚂蚁集团做了融合，蚂蚁也有更多的数据和场景去帮助 TuGraph 进行向前演进。

（3）2022 年

①（08 月）再次刷新 LDBC-SNB 成绩。

②（09 月）TuGraph 单机版开源。

③（12 月）TuGraph 上阿里云：目前已经可以免费试用了。

总结来讲，TuGraph 是一个开源的、易用的、先进的，同时功能完备的单机高性能图数据库。

2. 技术先进

TuGraph 具备良好的学术基础，做了大量的基础研究，相关论文发表在国际顶级会议，如 SIGMOD、VLDB 等，我们先进行了一些学术研究，再把这些学术研究在工业界中去落地，也有很多的专利和软著。

3. 产品及技术广受行业认可

它设计出来除了用来打榜之外，还有很多商业上的行为，我们拥有众多客户，同时蚂蚁集团的 TuGraph 入选了 IDC 的主流图数据库供应商，也同时入选了世界互联网的先进科技成果，LDBC-SNB 的测试也居榜首。

4. 系统架构

整体架构上，跟大部分的图数据库类似。

（1）操作系统 & CPU

**① 操作系统：**CentOS、SUSE、麒麟。

**② CPU：**X86、ARM、鲲鹏、海光等。

兼容绝大部分的操作系统和 CPU，包括麒麟和 SUSE 的操作系统，鲲鹏和海光的 CPU。

（2）KV 存储层 & 图存储层

**① KV 存储层：**ACID、索引、属性图模型、多图。

**② 图存储层：**多版本 B+ 树、WAL（Write Ahead Log）。

图存储这一层是基于 KV 做的，在上面嵌了一层图的语义，能使其更加高效。

（3）Core API

**作用：**计算跟存储之间，以一层 Core API 隔开。好处是层次比较清楚，有利于模块化的开发。

（4）计算层

**① Cypher：**基于描述性的图查询语言，等到类似于 SQL 的国际标准图查询语言出来之后，我们会集成 ISO GQL 接口。

② 存储过程 API：除了 Cypher，还提供了一个更底层的存储过程的 API，有更好的性能和更灵活的表达力。

（5）客户端

① 支持不同语言的客户端：包括 Java（OGM）、Python、C++。

②可视化工具：包括 TuGraph Browser、TuGraph Explorer，接下来会进一步介绍。

（6）生态工具

包括一些常见的工具，不再展开。

5. TuGraph Broswer

TuGraph Browser 是一个 WEB 端，可以进行可视化交互。比如基于点边的画布，双击能展开邻居顶点，点击可以看到属性。TuGraph 的几乎所有功能都可以可视化交互完成。

6. TuGraph Explorer

另外，TuGraph Explorer 侧重应用层，对点、边的逻辑操作做进一步具象化。Explorer 的开发基于 GraphInsight，也是蚂蚁开源的项目之一。形式上可以通过拖拽的方式，创建定制化的交互页面，更符合业务逻辑。其中，点可以换成不同的图标，可以预制一些算法，这样完全不懂技术的业务方也可以通过简单的操作，得到他想要的业务逻辑，以及查询的结果。

7. 多版本图存储

**（1）Copy-on-write B 树：**最底下的存储，是基于 Copy-on-write 的 B+ 树，多版本的 B+ 树，好处是读性能会非常好。对于 Scan 的操作，图经常会有一个点需要找出它所有边的这种行为，这一类操作会非常快。

（2）无锁操作：RocksDB 是一个非常常见的底层 KV 数据库，在测试中会发现 RocksDB 的写性能会比 LMDB 更好，但读性能不如 LMDB。我们分析了一些线上的业务，也参考 LDBC-SNB 测试，发现它们的读写比大概是 20:1，即 20 个读会有 1 个写。读在大数据里面更加频繁，更需要关注其性能。从这个角度来讲， TuGraph 倾向于使用 LMDB。

（3）自适应数据映射：TuGraph 把图的语义映射到一个 LMDB 这种 KV 的上面，需要解决大点的读写操作问题，采用自适应的映射，具体技术细节不再展开。

8. HTAP：一份数据，多种用途

HTAP 是指，除了跑类似于 K-Hop 的图查询，还可以跑类似 PageRank 和 BFS 这种较复杂的全图分析。

（1）HTAP 框架接口

**① 事务操作（事务接口）：**从左边看，K-Hop 的查询操作会有一些事务接口在图存储上。

**② 简单图分析算法（动态图分析框架）：**直接在原来的图上操作，就像找两个点之间的最短路径，或者跑 Jacord 这种稍微局部一点的分析。

**③ 复杂图分析算法（静态图分析框架）：**如果分析比较复杂，比如 PageRank 或者 Louvain，会有额外的操作，先把数据导入 Snapshot，再在 Snapshot 上去跑真正的分析算法。因为导数据需要开销，只有后面的分析足够复杂，才能盖过这部分开销，让后面在一个合适的数据结构上跑的更快。

（2）HTAP 框架存储

**外部存储：**在整个框架上，复杂分析和算法也能直接从外部存储上去取，不一定要先导到 TuGraph 里边。

9. 支持 6 大类 30 多种图分析算法，便于挖掘业务价值

算法有 34 种，可分为六大类：1）社区发现；2）图结构算法；3）路径查询算法；4）重要性分析；5）关联性分析；6）模式匹配。

其中模式匹配里，子图匹配算法是跑一个子图同构的算法，Motif 算法是去数小图的 Pattern，可以说 TuGraph 能够支持绝大部分的图算法。

10. 灵活丰富的接口

TuGraph 有一层 Core API 把存储和计算分开，有基于存储过程 C++ 和 Python 的语言，也有更加简单的类似于 GQL 的 Cypher 的语言，也有不同的客户端，中间会通过 REST 的过程、RPC 的网络协议去连接。

--

03/TuGraph 规划

1. 技术规划

TuGraph 现在已经开源，之后会持续推进。TuGraph 没有计划去做 Sharding 的图存储分布式版本，但是会有基于高可用的版本。

（1）KV 存储层

**下一代存储引擎：**LMDB 的写性能仍有改进空间，可能会去做基于 Hash 的优化，或者重新设计。

（2）图存储层

**隐私计算：**有可能会做，因为我们希望 TuGraph 架构简单。所以有一些学术界、工业界的尝试，都可以先拿 TuGraph 试一遍。

（3）计算层

① Cypher（性能优化）。

**② ISO GQL：**等 ISO GQL 发布之后，或者现在已经拿到的 Draft，同步去实现 ISO GQL 的查询语言。

**③ 图分析引擎（Python 接口）：**目前的图分析使用的是 C++，后面会尝试在中间做一层 Python 的接口（在3.4.0版本中已经具备）。

**④ 图神经网络引擎：**已经简单集成 DGL，后期会做更深度的集成，让两边的交互更简单。

（4）生态工具

**① 云化部署：**已经上阿里云，后面也计划上 AWS。

**② 一键迁移：**希望能做一些小工具，比如原来用 Neo4j 时候，发现数据量比较大的时候，性能不佳，也能够比较方便的一键迁移到 TuGraph。

2. 目标群体

（1）直接用户 & 解决方案提供商。

（2）开发人员。

（3）研究人员。

希望有部分的图数据库开发和研究的人员，能够参与到我们中间来，因为 TuGraph 是开源的产品。我们会日常去维护它，在使用过程中，有任何问题也可以联系我们。

3. 社区使用指南

（1）我们的官网（http://www.tugraph.org）和公众号，是集中发布信息的地方。

（2）技术问答，推荐大家使用 GitHub 的 Discussion，我们每天都会去上面回答相关问题。

（3）作为开发者，可以提交 Issue、Repo，工具都是完备的，我们也会在上面跟进。我们还会继续完善设计文档。后面会通过做 Demo 和开 Meetup 的方式，把整个社区环境运营起来。

（4）交流群，大家可以去钉钉上面提问。

（5）其他社区（SegmentFault、CSDN、Bilibili），我们也会在上面发布一些信息，建议优先使用 GitHub。

4. 阿里云免费试用

阿里云的免费试用现已开放，只需通过链接点击试用，配置是 4vCPU、32GB 内存的机器。启动 TuGraph，点击就能创建，运行后会有 IP 端口，可在页面上进行操作。如果想更定制化，或者是性能测试，可以去 GitHub 上，根据指引下载代码，自行编译运行。

参考链接：

TuGraph 开源地址：https://github.com/TuGraph-family/tugraph-db

一键云上免费部署：https://aliyun-computenest.github.io/quickstart-tugraph/

今天的分享就到这里，谢谢大家。