共计 5427 个字符，预计需要花费 14 分钟才能阅读完成。
在近日举办的 DTCC 2022 第十三届中国数据库技术大会 - 图数据技术与利用翻新专场，蚂蚁团体图数据库负责人洪春涛博士分享了蚂蚁高性能图数据库 TuGraph-DB 的技术思考和实际，以下为演讲内容要点回顾。
图计算的劣势
图计算是一种高效的形象计算方法，能够不便地解决简单的多维数据。咱们将员工和公司之间的关系画成图，这样能够疾速查问员工的信息，例如员工的工作状况、与其余员工的关系以及与哪些公司有分割。相比之下，在关系数据库中，咱们须要别离建设员工信息表、公司信息表以及员工和公司之间的关系表。这就把整个数据切成了很多张二维表，在理论利用零碎中常常可能看到几百上千张表。这样会使得零碎变得更加简单，须要基于多张表去做推断，对人或机器来说都会带来挑战。
比照来看什么是简略查问和简单查问：
图中表格的前两行属于比较简单的查问，比方某个员工的工龄，间接找到对应的那一行而后取出来就能够；比方找出所有的雇员数大于 5 的公司，可能在雇佣关系表中就能找进去，在关系数据库里这些都属于惯例的操作。
但如果查问再简单一点，我想晓得员工 A 和员工 C 之间有什么关系，不肯定是一跳的关系，可能蕴含在同一家公司工作，也可能蕴含参加了同一个我的项目，甚至还蕴含他们有一个独特好友，这些关系就是多种多样的，想用 SQL 列举所有可能的关系其实就没有那么容易了。如果确定晓得这里可能有几种关系，还能靠 SQL 穷举进去，但随着表越来越多，外面的关系可能有几百上千的时候，再想去穷举就十分难了。
最初还有一种更简单的查问，比方想找员工 A 和员工 E 的所有关系，可能包含 A 意识 B，B 意识 C，C 意识 E，相当于在做一个不定长跳数的查问，在 SQL 外面就十分难写了，置信绝大多数人都难以写出这种查问。
业界有句话，所谓的关系数据库实际上并不善于解决关系。例如，员工 A 和 E 之间的所有关系实际上就是咱们要查问的关系，但在关系数据库中解决这种关系查问实际上是不够敌对的。这是图数据库的劣势所在，它们更善于解决简单的关系数据。咱们发现，大部分通俗的数据信息都能够比拟容易地开掘进去，但要想更深刻地利用数据产生更多的价值，就必须开掘更深层次的信息，这时就肯定会遇到这些简单的关系，这也是为什么图数据库越来越受欢迎的起因。
为什么图数据库开始风行
图数据库的概念最早呈现在七八十年代初期，但过后为什么人们没有抉择应用图数据库，而是抉择了关系数据库呢？我认为次要起因是，过后的计算机并不那么弱小，应用二维表格模式的关系数据库对计算机来说更敌对。咱们晓得，计算机最善于的事件就是反复的劳动，反复的工作。如果咱们要在一张二维表中找一行数据，咱们能够一行一行查找，或者应用二分查找（如果数据是树状有序的）。每一层都是反复的算法在运行，这对计算机来说是一个十分规整的数据，容易解决。但如果把数据抽象成一张图，那么难度就会大很多，对计算机来说会更难解决。
举个例子，一个员工可能与其他人有各种不同的关系，比方敌人关系、雇佣关系、参加我的项目关系，每种关系的类型都不同，对应的数据也都不同。此外，一个点上的边数也十分不法则，有的人可能只有几个好友，而在微博上，一个普通人可能有两三百个粉丝，而大 V 账号可能有数百万甚至上亿的粉丝。这样一来，存储数据时，普通人和大 V 之间的差距就十分大了，对计算机来说，解决这两种数据的差别也会很大。
咱们晓得，在七八十年代，计算机相对来说很弱，如果那个时候应用图来示意数据，整个解决和查问的难度就会大很多。所以，人们抉择应用关系数据表的模式示意数据。事实上，那个时候有人做过图数据库，但并没有流行起来，起因就是性能绝对关系数据库来说差得太多了。
咱们晓得，所有的事物，尤其是电脑，始终在不断进步。这包含硬件和软件方面的改良。现在的硬件和几十年前的硬件齐全不是一个概念，而当初的软件优化也大不相同。随着这些改良，咱们会发现对以后的电脑和计算机系统来说，应用图数据库带来的额定开销可能不是很大的问题。
举个例子，咱们会发现，过来人们都应用低级编程语言编写程序，但随着工夫的推移，有了高级语言。比方最开始、最原始的电脑可能是用纸袋和机器码写程序，起初有了汇编，再起初有 C 语言、C++，当初很多人都间接写 Python。尽管 Python 程序的执行速度可能较慢，然而写的很快，而用用 C ++ 或者汇编去写得写半天，对于编写程序到最终得出后果的整个过程来说，应用 Python 会更不便。
计算机编程语言的倒退是从低级向高级演变的，数据抽象也是一样。咱们认为，将来的数据抽象肯定会对人更敌对一些，而不是专一于对机器更敌对。如图所示，编程语言的倒退是从低级语言向高级语言转变的，咱们也认为数据抽象层次也会缓缓从低层次表格形象向高层次图表形象倒退。
图计算在蚂蚁的利用
自 2015 年开始，蚂蚁实际上投入了大量资源来钻研图计算，钻研如何在蚂蚁的业务中应用图计算。例如数据血统利用。在对业务的处理过程中，咱们须要较好地追踪这些数据的流转门路，如果批改了一份源数据会对上游数据产生什么影响，会对最终业务产生什么影响。为了更好地追踪，咱们应用图数据库来存储数据。
另一个比拟乏味的利用场景就是程序剖析。置信简直所有互联网公司外部都有大量的程序，因而，咱们须要治理这些程序，并在每次提交代码时理解将会对哪些内容产生影响。为此，蚂蚁负责程序剖析的团队会剖析这里的图数据。例如，定义一个变量 A，而后应用变量 A，“定义”与“应用”之间就会有一条边，应用关系会存储在图数据库中。目前咱们的图中曾经有超过 200 亿条边，这是一个十分大的数据量。咱们须要对这些数据进行存储、查问和剖析，这是蚂蚁公司外部十分多的图数据场景之一。
举个例子来阐明优惠券反套现的场景：满额返券是一种比拟常见的促销形式，比方购物满 2000 元就能够享受 100 元的优惠。这种状况下，如果失常生产，用户破费 2000 元，通过返券省下 100 元。然而有些人会想方法注册假商铺，进行虚伪交易，目标是把平台补贴的优惠券套出来。因而当用户去买货色，平台要去付补贴的过程，咱们须要去实时检测一下会不会有可疑的资金交易状况。
蚂蚁有很多业务须要钻研图计算零碎和图数据库等技术来满足需要，因为这些业务须要对大量的点边进行剖析，数据量超过了 100TB，基本上曾经达到了 PB 级别。咱们须要对这些图进行实时查问，吞吐率大概在百万级别。因为须要对用户的付款进行实时判断，所以须要比拟低的提早，大概在 20 毫秒的级别。如果提早太长，会导致用户体验很差，比方付款须要期待 5 秒能力实现，这样就会十分麻烦。
图计算零碎建设中的问题与挑战
在建设蚂蚁图计算零碎的过程中，咱们遇到了各种各样的问题。为了解决这些问题，咱们与学术界和许多钻研界的共事一起单干，并发表了许多相干的学术论文，包含 EuroSys 等。然而，咱们在建设零碎的过程中发现，目前的图计算仍处于较晚期的阶段，因而许多规范尚未成形。这对咱们来说是一个辣手的问题。例如，在关系型数据库中，查询语言基本上就是 SQL，但在图数据库中，仅查询语言就有许多种，包含 Gremlin、G-SQL 等等。这导致了市场的碎片化，人们学习和应用的老本也很高。
在建设图计算零碎的过程中，咱们也遇到了许多挑战。为了分担较大的通信量，须要将图数据分布到多台机器上，但这会导致边的信息在不同机器之间传递，造成大量的通信。此外，单次查问所波及的数据量也比拟大，例如五跳查问波及的点数就已达到 10 的五次方，图中还存在一些十分大的点。同时，用户对图计算零碎的需要也非常多样，既有疾速查问的需要，也有对简单算法（如社区发现）的需要，繁多零碎很难满足这些不同的需要。
TuGraph 技术劣势
蚂蚁本人开发了一套图计算零碎 TuGraph，既能解决图数据的存储问题，也能解决流式计算、离线计算和图学习的问题。目前，超过 100 个业务线和 300 多个场景都在应用这套零碎。这套零碎在 2021 年取得了世界互联网大会当先科技成果奖。
在 TuGraph 中，性能是一个重要的因素，因为图数据集的体积很大，如果性能不佳就会节约机器资源，导致许多状况下无奈实现工作。比方，心愿业务的查问能在几十毫秒内返回后果，然而如果做的性能不好，几秒钟能力返回后果，就无奈作为在线查问应用。因而，咱们是十分对性能是很器重的，其中在 LDBC-SNB 规范测试中（相似于数据库畛域性能规范测试 TPC-C），TuGraph 依然是世界纪录的保持者。
TuGraph 的整个图存储是建设在完满哈希的根底上的，这是咱们与其余图零碎的一个重要区别。目前，大多数图零碎应用的是基于数的存储，但数的问题在于永远存在一个 LogN 的查找操作。然而，在图中能够看到，不同的顶点之间实际上是无序的，不须要有程序，所以顶点这个级别实际上是基于哈希的，实践上，顶点的读取是最优的。
此外，TuGraph 还参加了许多规范的定制，整个零碎在尽量往标准化的方向去做。
除了为外部提供服务，咱们还向外提供服务，次要是因为，作为一个零碎，如果只为无限的客户提供服务，就很容易构建成一个专有零碎。咱们心愿这是一个标准化、凋谢的零碎，所以咱们也在对外提供图计算零碎的产品和服务。目前，咱们也有很多内部客户，包含金融、工业、互联网以及政企畛域。
开源凋谢，共建倒退
整个图计算零碎目前仍处于较晚期的阶段，咱们认为还有很多工作要做，包含晋升应用性、性能和降低成本。所有的零碎都会有这些问题。然而，如果心愿遍及，咱们认为最重要的是有衰弱的生态，来推动图计算零碎的倒退，须要有更多的用户和更多的场景应用这个零碎。
所有的计算机系统都须要去有一个更凋谢、更大的生态能力促成倒退。蚂蚁有一句话叫做“成熟一个、凋谢一个”，一个零碎成熟当前，咱们就会试着凋谢进来，让更多的人去用。往年 9 月，咱们曾经在 GitHub 上开源了 TuGraph 中的单机幅员数据库，以及一个离线图剖析引擎 TuGraph Compute。分布式图数据库和流式图计算当初曾经蕴含在咱们的商业化版本中，包含一站式图研发平台。咱们打算在将来迭代更多更丰盛的零碎性能，心愿能做得更好。
TuGraph 开源版特色
为什么要去开源单机版而不是分布式版本？次要是思考到它的部署和应用老本比分布式版本要低得多，同时性能也很残缺、独立。咱们心愿这样能够让许多刚开始应用图数据库或有应用图数据库解决问题的想法的人，能够先尝试用咱们的单机幅员数据库。因为它的部署非常简单，如果跑起来没有问题，那么再思考是否须要分布式版本。如果的确须要，咱们能够再跟进这个问题。
咱们的单机幅员数据库曾经可能反对 TB 级别的数据，咱们外部也有很多状况应用单机幅员数据库。在单台机器上，咱们最大的数据量也达到了 2TB 多，在线上运行，可能解决百亿级别的点边。事实上，大多数用户应用单机幅员数据库都是足够的。因为单机版的图数据库很容易优化，咱们对它进行了极致的优化，因而单机幅员数据库在性能上能够满足绝大多数场景的需要。此外，它的零碎个性也很全面，包含高可用性、多图反对、权限治理、日志记录等，它能够被看作是一个成熟、易用的图数据库，相似于 MySQL。
图中所列出的开源版 TuGraph 几个个性包含：
- 单机幅员数据库可能解决数据量几个 TB 的数据，前提是磁盘足够大。
- 老本很低，因为是单机版，部署和运维都很容易。
- 性能很好，咱们对其进行了大量优化。TuGraph 的 LDBC-SNB 测试目前是世界第一，大家能够在 GitHub 上获取测试 SNB 的条款并进行测试。
- 单机幅员数据库是一个十分易用的残缺零碎，咱们提供了导入导出工具和查询语言。此外，还提供了底层 API，用户能够应用它来编写简单的程序。
咱们的开源版本的指标次要有三点：
首先，咱们心愿提供一个收费的图数据库产品，可能让更多的人应用图数据库，尝试用它来解决问题。
其次，咱们心愿促成图数据库规范的成形。目前图数据库的差别太大，每个数据库都有所不同，咱们心愿通过提供一个参考答案来帮忙大家达成趋同。这样大家就能够依据咱们提供的设计来判断哪些特色正当，如果感觉正当就能够遵循这个设计，缓缓地大家就会逐步凑近。如果所有产品在次要特色上保持一致，这样所有人的学习老本就会升高。
最初，根底研究性问题能够一直优化倒退，包含存储方面的问题，例如哈希可能是实践上最优的，然而是否还有其余须要调整的货色？目前没有一个很好的研究性平台让大家去进行这些尝试和钻研，咱们心愿提供的开源 TuGraph-DB 能成为这些钻研人员的比照基线，促成钻研的倒退。
TuGraph 企业版特色
除了开源版本，咱们也持续提供商业版本。这个版本蕴含一个分布式图数据库，以及离线计算引擎和流式图计算性能。此外，咱们还提供了 TuGraph Platform 一站式图平台，包含运维、可视化等性能。在这个平台上，用户能够在图数据库中执行流式计算，并在线写回数据库。这种形式通常用于实时查问后果，因为流式计算的工夫可能比拟长，但用户能够立刻查问到较早的后果。这对于在线业务来说十分重要。
商业化产品还提供私有化部署，也能够通过一体机的形式部署硬件，并将很快推出云上部署计划，这样大家就能够在云上体验咱们的产品。
总结
蚂蚁在图计算方面投入了大量资源，并在泛滥业务场景中磨难出了一整套在线查问、流式计算、离线剖析以及图学习的体系。目前，咱们曾经在 GitHub 上开源了单机版（https://github.com/TuGraph-db），同时也提供企业版来满足不同用户需要。
