GaiaDB：全球唯一支持多云的云原生数据库

朱洁老师受邀作为 DTC 2024 云原生数据库专场主持人，并发表专题演讲《基于通用硬件构建的云原生数据库GaiaDB 4.0》。

以下内容根据朱洁老师的演讲内容总结而来。欢迎大家查看！

正文：

我今天演讲的题目是《基于通用硬件构建的云原生数据库 GaiaDB 4.0 》，为什么会讲要基于通用硬件去构建一个云原生数据库，是因为基于通用硬件构建的数据库，才具备多平台，多云的能力，才能更多用户使用到。GaiaDB 是全球唯一可以支持多云的云原生数据库，基于通用硬件实现了高性能硬件同样的效果和更好的可用性。具体怎么做的，我会在接下来的演讲内容中深入展开。

今天我演讲的内容会分为 5 个部分，分别是，云原生数据库的当前挑战，GaiaDB 的发展历程，GaiaDB 设计理念和架构解析，客户案例，以及未来5.0的展望。

讲到云原生数据库，先来简单回顾下云原生数据库的历史。云原生数据库不是一个新概念，10 年前，2014 年 AWS 推出了 aurora 第一个版本，因此开启了云原生数据库时代。

云原生数据库相比传统企业级数据库，有着云数据库 RDS 的全托管，免运维的优势，又再弹性，性能和大规模成本上要好于 RDS，因此云原生数据库推出来之后，一直是 AWS 主推产品，也是增速最快的产品。国内云厂商也推出类似的对标产品，例如百度的 GaiaDB。经过整整 10 年的 发展，按道理说云原生数据库优势众多，应该遍地开花，但实际上，根据调查，企业大概也就刚刚超过一半，57.9% 有意愿采用云原生数据库，从覆盖角度来看云原生数据库发展也碰到了自己的瓶颈，那云原生数据库离客户期望差距主要还在哪些方面？根据调查客户主要关心的有三点：

• 是否有做够灵活的部署模式，包括支持跨云，跨平台的能力；这个很容易理解，毕竟不是所有客户都能上云，尤其是国内云的渗透率不够。很多大客户，也有多云的诉求，期望能有一个跨云平台的产品，就不用来回切换技术栈。

• 技术上成熟度，应该说做云原生数据库的厂商很多，不是每家都有足够的场景进行充分的验证。

• 兼容性和服务可持续性。这个就是考虑厂商的工程能力，投入程度了。

总的来说，这三点都是非常考验云原生数据库的架构设计能力，已经背后团队持续投入，持续服务的能力的。

面临这些挑战，百度在这块的思考是怎么样的，以及怎么看云原生数据库这个赛道。这些内容都会在我接下来的介绍中展开，包括百度在云原生数据库上的一些思考，实践和未来的一些规划。

百度智能云对标 Aurora 产品名字叫 GaiaDB，这个是百度自研的企业级云原生数据库，采用存算分离的架构，计算层基于 MySQL 进行自研，因此 MySQL100% 兼容，单独的存储层池子，做到按需扩展。GaiaDB 在内外部已经有大量的客户在使用，实现了全行业覆盖，在线运行的最大的示例超过 500TB，数据量目前有数十 PB。作为云原生数据库，基础的弹性，兼容，高可用，高扩展这些 GaiaDB 都是非常强的，在这些基础上，GaiaDB有两个比较有特点的地方：

• 第一个是基于通用硬件设计实现的，不依赖特殊硬件就可以达到很好的性能。这样设计的好处是客户门槛低，成本低，云上云下，混合云很容易做，都是一套架构；

• 第二个高可用能力业界处在业界领先的优势，RTO < 3 秒，这个原因是 GaiaDB 对内部数据流，存储层协议做了深度的优化，底层存储内部协议原生就是支持，这个后面我们会展开讲。从用户看到的是，AZ 级别，Region 级别的，支持热切换，RTO 切换在 3 秒 以内，而且这个高可用能力也被多个大客户用起来了，是经过充分验证，非常成熟稳定的能力。

GaiaDB 能达到当前的规模和能力，也是经过很多年的一个发展。百度智能云还是坚定看好云原生数据库这个赛道，因此对 GaiaDB 进行一个持续的投入，从 2020 年开始发布第一个版本，解决了存算分类，容量弹性的问题，到去年10月我们发布了4.0重点优化了内部数据流，新增了并查，列存索引等能力，解决了原生 MySQL 的通病，复杂查询比较弱的 问题。现在最新的我们发布了 4.1版本，在 flash back，大 blob 查询上提升了 10 多倍。GaiaDB 通过持续迭代和众多客户打磨，已经成长为一个成熟，稳定，综合能力领先的企业级云原生数据库。我们技术的成熟度，以及持续服务客户的能力已经在多年服务众多大客户中得到充分的证明。

基于通用硬件在降低门槛，多云场景等有着巨大的优势，但同时对数据库内部的优化挑战就很大，接下来我深入展开讲一下，GaiaDB 是怎么基于通用硬件同样实现高性能。

要实现一个分布式数据库，如果将单机数据库引擎和分布式存储框架简单组合，把数据库嫁接到一个分布式存储上，很多开源数据库的实现逻辑就和左边图示例的一样。如果这样做，会有一个比较大的问题是，性能非常差，尤其是长尾时延非常差，这在数据库，尤其是 TP 场景是不能接受的。为什么会比较差？

继续看左边的图，我们会发现为了保证可靠性，计算引擎要主从同步，要写日志，分布式框架要保证自己的可靠性又有一层主从同步，日志和持久化逻辑，到最下层的存储引擎为了确保数据不丢，又得来一遍日志以及最终的数据的写入。

这几层为了各自可靠性，多层冗余了日志导致写放到非常大，同时网络也要反复确认，所以需要多跳才能完成，而且这个写入过程是一个串行，同步的过程，从而导致了数据库的性能很难优化，尤其是在分布式系统中长尾非常难控制，这个如果大家用开源的分布式数据库，相信就会常常碰到这个问题。

与之相反的右边的图就是 GaiaDB 的优化思路，GaiaDB 通过深度融合数据库和存储技术，把日志全部统一到全部统一到 redo 物理日志，由 logservice 统一负责其可靠性和可用性，将持久化，快照，数据库回放功能融入存储节点中。通过这样的重组和融合，就大大简化了整个数据流，降低了网络，分布式确认的开销，同时减少了数据放大，所以性能上的收益巨大。同时因为数据流和逻辑上得到了简化，内部数据库流统一到数据库语义，也降低了工程复杂度，提升了可靠性。

接下来分别讲一下深度融合的具体的核心技术细节是怎么实现的，首先是网络协议的优化。

传统没有融合之前，计算和存储是分开的，业界通用的一般使用 Raft 来实现存储数据可靠性，就像右上角图示一样，计算节点把数据发给存储节点 leader，存储节点 leader 收到之后，再发给follower，至少需要收到一个 follower 的确认，才返回成功，这个过程就需要至少两跳网络，而大家知道，整个计算机系统里面，网络是最慢的，网络的跳数越多，性能肯定就越低，怎么想办法降低网络传输路径是第一个优化的核心要点。

GaiaDB 的实现可以看右小角的图，GaiaDB 把数据库的主库逻辑和存储的一致性逻辑都合并到计算节点，WAL 和物理日志统一合并成物理日志。计算节点 CN 直接往 log 多个节点发请求即可，只要收到多个返回，数据就是存储成功了。这个好处不光是节省了一跳网络，还带了整个数据库系统复杂性的降低：

对于数据库 crash recovery 场景，由于统一使用了数据库的语义，主库统筹事务和多副本一致性，反而避免了多种日志逻辑之间相互转换和同步带来的复杂度风险，降低了实现复杂度，整体流程更加健壮。

Snapshot 和数据库的 MVCC 合并，统一使用数据库多版本，大大节省了落盘 IO。

总得来说，通过这个优化，线上的吞吐提升了 40%+，时延降低了 30%+，同时由于链路简化，也把长尾的时延，进行了大大的优化，降低了一个数量级。

前面讲的是整体架构上的重组和融合，网络链路得到简化，缩短了链路，那接下来进一步提升吞吐的方法就是要提高并发。提高并发的前提是要能异步，不能是串行的。由于都统一成了物理日志，日志里面带了版本号，长度等信息，所以就不需要串行来发，GaiaDB借鉴了类似 TCP 滑动窗口的思路，让日志异步发送，日志服务根据版本自动选择最新的数据落盘，批量返回最新的水位，这样就大大节省了日志确认的负担。整个日志流从串行变成了一个异步批量写，大大提高了吞吐。

同时为了避免再高负载场景下，IO 资源被争抢，采用了专用的 IO 线程技术。通过再链路内部的优化，实现了不依赖特殊硬件，多协议的自动适应，整个RPC短到短延迟缩短 60%+，稳定到百 us级别。

前面讲到日志链路通过优化从串行变成了异步的，提高了吞吐和降低了时延。这个时候，可能大家会有疑问，是不是系统的最终一致性会降低，导致数据丢失或者不一致的问题，答案是否定的，这里面用了 GaiaDB 中非常重要的能力，存储的自适应回放能力。GaiaDB 底层存储是一个 MVCC 多版本系统，计算节点请求的时候，会带上需要的版本号，存储会根据版本号，回放到任意目标版本再返回。如果所有的回放都是日志节点来实现的，分布式环境下，由于异步原因，一些节点比较慢，就可能拖累整个系统。所以 GaiaDB 计算节点也是支持回放的。

大家可以看右边这个图，比如左边的存储节点目前版本比较新，有能力回放的时候就回放工作就由存储节点负责，右边节点是慢节点，存储节点尽力回放之后，仍不满足要求，那它只需要尽量回放，计算节点可以进行后续数据回放，自动兼容慢节点。这样就充分利用了存储节点的计算能力，又能兼容慢节点，从而避免了在分布式系统中的慢节点，多个节点协同的问题。这个优化对高负载的情况下，IO 的延迟有超过 50% 的提升。

最后看下真实的测试结果，通过多项优化综合之后，不管是读性能，写性能，读写性能都有大幅提升，尤其是写性能最高提升 89%。这些优化都是再普通介质和网络的测试下得出的，主要得益于数据链路的缩短，同步转异步，存储多版本自适应动态回放能力的优化。

一款数据库除了性能之后，最重要的就是高可用能力。数据库作为最底层存储环节，可用性、可靠性直接影响系统整体。而一个在线系统，尤其是分布式系统，情况是复杂多变的，任何一个单点都可能出故障。因此真正的高可用系统，一定是一个支持多层次，多级的高可用。GaiaDB 支持从单体到多可用去到多区域的高可用。

单体支持多副本，副本之间没有耦合 0

多可用区，机房故障了不影响业务

多地域高可用，地域间独立资源池，相互故障不影响，而且支持快速切换

同时这些高可用是有能力支持热活能力，只有支持热切换才能提供用户最小的 RPO。

先简单讲一下集群内部的是怎么实现高可用的，这个是基础。GaiaDB 架构比较简单，分三层，计算层，日志层和存储层。

• 计算层本身无状态，支持热活，热切，所以单个节点故障了秒级别就能切换备份节点上。

• 日志层采用多数派协议，前面在讲网络优化的时候展开了讲了。因为是采用的是多数派协议，所以从原理上就是可以容忍少数派故障，任意节点故障了不会需要选主，也不会出现卡顿。

• 存储层对称的多副本，可以容忍 n-1 故障，另外存储是自适应的，部分副本变慢的时候会快速重试其他副本。

综合下来，GaiaDB 独特的日志和存储设计，让整个系统故障的时候冗余度比较高，系统只有在极端情况下才会出现异常切换的情况，系统整体的可用性因此很高。

接下来看跨可用区，跨地域高可用。这个在GaiaDB也是支持非常好。因为 GaiaDB 是多副本对称的，因此多可用区和单体本质上是一样的，只是需要把不同的副本部署到不同的可用区。

因此多可用区是支持热活的，也支持就近访问，以及自动平滑慢节点，这个在云原生数据库里面能力还是比较领先的。

同时底层采用了物理同步的协议，在跨地域使用物理复制，时延仅几十 ms，跨 region 高可用的同时，也保持很好的性能，支持延迟低吞吐高。

时间有限，今天只分享了内核部分一些关键设计，最后 summary 一下 GaiaDB，作为一款成熟的云原生数据库产品，GaiaDB 同时具备高弹性、高性能，高可用，低成本能力，这些能力在云原生数据库都处于领先的地位。同时GaiaDB非常有特点是在多云，降低门槛上：

• 易部署：因为本身架构非常简单，所以部署也特别容易，是全球唯一能支持多云的云原生数据库 GaiaDB，支持多云，IDC。

• 易运维：除了多云融合管控平台，还支持大模型加持的 copilot 的能力。

• 易使用：为了方便开发人员调试，我们还开发了可以运行在笔记本上的单机 GaiaDB，这样开发人员就可以下载到自己的 Mac 笔记本上调试，非常方便开发人员使用

GaiaDB 是全球唯一支持多云多多平台云原生数据库，GaiaDB 让企业级云原生数据库进入多云时代，让云原生数据库赋能千行百业，普惠，易用。

GaiaDB 4年时间以来，已经被大量客户采用，数据量已经达到数十PB级别。接下来讲两个典型案例。

首先是百度地图案例，百度地图是国门级应用，日活超过了 5.6 亿，同时节假日的时候业务会暴增，这就对数据库在可用性，弹性，低成本上有非常高的要求。百度地图采用 GaiaDB 之后

目前规模上成功支持了PB级别的数据量，百万级别QPS，这个估计是目前国内最大的云原生数据库应用。

高可用上，采用了四地多活，这在国内也是非常领先的。

同时弹性的能力，帮助百度地图节省超过60%的成本。

在这些规模，弹性基础上，GaiaDB 的服务质量非常高，保持 4 个 9 以上的稳定性，RTO 小于 3s，数据可靠性 RPO=0。总结一句话就是，GaiaDB成功帮助百度地图实现极致的弹性和成本。

第二个 case 是一个 saas 厂商，神州三丰是国内知名的 saas 厂商，帐三丰是旗下财税 saas 软件。saas 厂商显著特征主要有三个：

• 第一个是支持多租户，一套 saas 软件能同时支持多个用户使用。

• 第二个是 saas 是 online 的服务，所以对服务的稳定性，可靠性要求高，尤其是财务软件。

• 第三个就是 saas 是基于云的应用产品，云部署，易用性很关键。

GaiaDB 完美的满足了客户再多租户，可用性，可靠性，易用性的要求，上线以来客户帮助客户成功度过流量高峰，性能，稳定性，服务支持各方面都得到客户的高度认可。

今天时间非常有限，分享这两个典型客户，GaiaDB 再各种能力系统的得到了大量客户使用，非常成熟和稳定。

最后简单展望一下 GaiaDB 5.0，我们大概会再 10 月左右发布 5.0 版本。GaiaDB 5.0 会继续迭代，增强很多能力，重点方面会瞄着更普惠，更智能，更强大三个大块去演进。

• 更普惠：我们会支持单主集群，serverless，以及混合云版本，这几个关键能力都是分别满足不同场景低门槛的诉求，让用户使用 GaiaDB 更轻松和容易。

• 更智能：会再支持 copilot 的基础上从开发、运维、使用多个角度利用大模型的能力进行增强。包括 NL2SQL，智能运维，智能问数的能力。

• 更强大：GaiaDB 会持续改善高可用，高性能，高弹性等硬核能力；其中高可用核心会进一步优化热切换能力，RTO 进一步降低；高性能方面通过支持行列混合引擎，进一步改善复杂查询以及提高性价比；高弹性，我们会在当前存储可以扩展的基础上，今年会把计算节点横向扩展搞定，GaiaDB 就能从计算，存储等多方面弹性和扩展。

我们相信通过持续迭代优化，给我们客户一个更好的能力回报客户的信任。也希望更多的人了解 GaiaDB，试用 GaiaDB。

我今天的演讲就到这里，谢谢大家!