作者：赵裕众OceanBase资深技术专家

OceanBase 资深技术专家，2010 年加入支付宝后从事分布式事务框架的研发，2013 年加入 OceanBase 团队，目前负责存储引擎相关的研发工作。

近年来，随着应用场景多样化和数据量的增长，我们看到分布式数据库正快速普及到各行各业，通过数据一致性、高可用、弹性扩展等方面技术能力，为用户海量数据、高并发的业务场景提供极佳的解决方案。同时，分布式数据库天然会需要配置多台服务器，以保证高可用和性能。因此，在很多数据规模较小、相对简单的业务场景，用户通常会在发展初期选择门槛更低、性能更强（小规格下）的集中式数据库。 但这一选择也存在一定的弊端：随着用户的业务量不断增长，最终会到达集中式数据库的性能瓶颈，等到再进行架构调整重构时，将会带来极高的难度和成本。

在今年的云栖大会，OceanBase 社区版 4.0（代号：小鱼） 正式与大家见面，这也是业内首个兼容 MySQL 的单机分布式一体化数据库。 这一版本提供了许多用户期待的能力，我们通过单机一体化架构、单机部署、小规格降低部署成本，一键安装部署提升易用性，更强的 OLAP 能力提升分析能力，最终实现 OceanBase 社区版 4.0 在 4C16G 的生产系统能够稳定运行。我们希望可以通过单机与分布式的双重技术优势，为用户在数据库选型时带来“一次选择，终身受用”的新可能。

从用户的反馈来看，OceaBase 社区版 4.0 在单机分布式一体化、小型化方面备受大家关注。 我们认为，小型化不只是完备功能前提下的单机部署，更重要的是在同等硬件下可以实现更好的性能。 本篇文章将分享 OceanBase 对分布式数据库探索“小规格”的思考，介绍我们在实践单机分布式一体化架构时的技术创新思路与方案：

• 用户为什么需要小型化的分布式数据库；
• 分布式数据库小型化的关键步骤；
• OceanBase 在小规格下的性能表现。

一、选择小型化分布式数据库原因

在进入主题之前，我们先回顾一下 OceanBase 发展历程中的重要时刻：2010 年，OceanBase 正式创立，创立至今的 12 年间， OceanBase 相继打破 TPC-C、TPC-H 世界纪录 ，陪伴大家度过了一次次“双 11”，保障大家每一笔交易都能够安全高效地执行。 在这一次又一次的挑战中，OceanBase 作为一款完全自主研发的原生分布式数据库，扩展性和稳定性也被不断得到验证，从 TPC-C 第一次打榜的 203 台 ECS 服务器到第二次打榜的 1554 台 ECS 服务器，OceanBase 的性能都是随着机器数量增加而线性提升。

另一方面，随着 OceanBase 从金融场景逐步走向通用场景，我们意识到并不是所有用户的业务都具有“双 11”时所面对的数据量，事实上，在许多用户的业务发展初期，单机部署形态的数据库完全可以满足其需求。 因此，在用户业务初期数据量还很小的时候，给用户提供一个尽可能低的启动规格非常重要。这将帮助用户以一个非常低的成本，做业务启动探索，同时借助 OceanBase 的良好扩展性，在后期又可以弹性扩容，以面对不断增加的用户数据和性能需求。

▋ 从小到大，每一个创新业务对数据库的基本诉求

最新的 OceanBase 4.0 版本最小支持 4C8G 的部署规格。4C8G 是什么概念？其实就是一台稍好的笔记本电脑的配置，换句话说，OceanBase 4.0 可以在大家的个人电脑上安装部署并稳定运行了。

从 4C8G 开始，OceanBase 4.0 可以随着用户的业务增长进行弹性扩容，能够从小到大支持用户全生命周期的数据库需求，帮助用户更好地降本增效、进行业务创新。

• 在用户业务发展初期， 数据量并不大，对容灾也没太高需求，便可以在单台服务器上部署运行 OceanBase 4.0，同时利用 OceanBase 的备份功能定期做下冷备以防万一；
• 当用户业务逐步成长起来， 可以先对服务器做纵向升级，此时用户对容灾有了一定需求，OceanBase 和传统数据库一样支持主备库部署，用户可以使用两台服务器做基础的在线容灾（由于主备架构的限制，此时容灾管理仍需要人工介入）；
• 当用户业务初具规模， 数据变得越来越重要，此时用户可以升级到 OceanBase 的三副本架构，使用三台服务器来保证高可用，容灾也将变成自动化：即使单台机器发生故障，OceanBase 4.0 仍然可以保证 RTO < 8s（8s 内业务恢复）和 RPO = 0（数据不丢）；
• 当用户业务进一步变大， 单机配置升级到顶，此时用户就会遇到和当初淘宝、支付宝一样“幸福”的烦恼，此时，OceanBase 的透明分布式扩展能力可以帮助用户把集群从 3 台扩展到 6 台、9 台乃至上千台。

图1 不同业务规模下 OceanBase 与传统数据库部署方式演进对比

▋ 平滑过渡，让性能保持线性增长

OceanBase 的单机分布式一体化架构，可以帮助用户在从单机形态部署直至多集群的分布式部署，始终能够平滑过渡，并保持性能的线性增长。

借助 OceanBase 良好的单机纵向扩展性，单机配置的升级通常会取得性能的线性增长。当用户进行分布式扩展时（例如从 3 台扩展到 6 台服务器），通常会引入分布式事务，一般而言，分布式事务的引入通常会带来一定的性能损失，但 OceanBase 可以通过多种机制降低分布式事务发生的概率：首先可以通过 OceanBase 的 TableGroup 机制，将多张表绑定在一起来降低分布式事务发生的概率；其次 OceanBase 良好设计的负载均衡策略也能帮助减少分布式事务。

此外，OceanBase 良好的分布式扩展性也能够保证随着用户使用的服务器数量增加，性能保持线性增长。例如在 TPC-C 测试中，尽管包含了大约 10% 左右的分布式事务 ，随着数据库集群规模的增大，OceanBase 性能的提升仍然是线性的。

图2 OceanBase 在不同节点数量下的 TPC-C 测试结果

更重要的是，在从一台到两台，到三台以及上千台的扩容过程中，所有操作都可以通过对 OceanBase 集群的运维来完成，对业务是完全透明的，用户上层的业务不需要修改一行代码，也不需要手动搬迁操作数据。当然，如果用户使用的是 OceanBase Cloud，所有的备份、扩容、运维操作都将一站式完成，更方便用户的使用。

从 OceanBase 4.0 版本开始研发的第一天起，我们就在思考如何让分布式数据库运行在更小规格的硬件上，并具备更强劲的性能，帮助用户在不同的业务场景下满足对性价比和高可用的要求。OceanBase 4.0 的小型化，不仅可以在具备完整功能的前提下实现单机部署，更重要的是能在同等硬件下实现更好的性能。

二、4.0小型化的关键技术

在基础软件领域，把数据库系统“做大”是一件非常困难的事情，因为随着系统中的节点不断增多，出故障的概率也会不断增加。例如，OceanBase 做 TPC-C 第二次打榜时使用了 1554 台 ECS 服务器，其中出现单台机器故障的频率大约是一天一次到两天一次。 这需要我们把产品做的足够稳定和高可用，才可以让这样一个大的集群保持正常运行。

而把数据库系统“做小”同样不容易，因为这需要深入到每一个细节，几乎是用显微镜去抠每一处资源的使用。 不仅如此，在大规格下一些合适的设计或者配置，到小规格下会变得完全不可接受。而更困难的是，我们要在同一套架构里面同时兼顾小和大，这需要我们在大小规格之间做设计上的权衡取舍，尽可能减少分布式架构带来的额外开销，同时在很多场景中让数据库系统根据机器规格做自适应处理。下面我们将以 CPU 消耗、内存消耗者两个主要难点的解决过程为例，介绍 OceanBase 4.0 的技术思路。

▋ 实现动态日志流控制，降低 CPU 消耗

OceanBase 4.0 实现小型化，要解决的第一个问题是 CPU 消耗，在 4.0 版本之前，OceanBase 会为每个数据表的分区创建一个 Paxos 日志流，通过 Paxos 协议来保证分区数据的多副本一致性。这样的设计非常灵活，因为 Paxos 组是基于分区的，这意味着分区可以非常灵活地在不同服务器之间迁移；但同时也带来了很大的 CPU 开销，由于对每个 Paxos 日志流都会有选主、心跳和日志同步的开销，当服务器规格较大或者分区数量较少时，这些额外开销相对来说占的比例并不是很高；但当服务器规格变小时，Paxos 协议带来的开销就变得难以接受了。

OceanBase 4.0 是如何解决这一问题呢？我们认为最直接有效的办法是减少 Paxos 日志流的数量。如果能够将 Paxos 日志流的数量减少到与服务器个数同量级的程度，那么这部分开销就和传统数据库主备库模式下的日志开销差不多了。

图3 OceanBase 4.0 动态日志流集群架构图

在 OceanBase 4.0 中，我们将多个数据表分区聚合为一个 Paxos 日志流，并进行动态日志流控制。如上图所示，一个数据库集群中有三个 zone，每个 zone 各包含两台服务器。假设有一个租户配置了两个 unit，那么相应地这个租户就会有两个 Paxos 日志流，一个日志流中包含分区（P1, P2, P3, P4），另一个日志流中包含分区（P5, P6）。

• 如果两台服务器的负载不均衡，那么 OceanBase 的负载均衡模块会在 Paxos 日志流之间做分区的调度；
• 如果需要做集群的扩容，那么可以将一个 Paxos 日志流分裂为多个 Paxos 日志流，并做 Paxos 日志流的整体迁移；

• 如果需要做集群的缩容，那么可以将多个 Paxos 日志流迁移到一起，并做多个 Paxos 日志流的归并。

  通过动态日志流控制，OceanBase 4.0 在保证高可用灵活扩展的基础上，极大减少了分布式架构带来的 CPU 开销。

▋ 元数据动态加载，让小内存支持高并发

OceanBase 4.0 实现小型化，要解决的第二个关键问题是内存消耗。在 4.0 版本之前，出于性能的考虑，OceanBase 会让一部分元数据在内存中常驻，当内存规格较大时，这些内存所占的比例并不是很高；而当服务器规格要降低到很小时，这些元数据内存的大小就变得难以接受了。为了带给用户更加极致的小规格能力，我们实现了所有元数据的动态加载。

图4 SSTable 分层存储

如上图所示，我们将 SSTable 做了分层存储，将 SSTable 的根存储在分区内，在内存中只维护分区的句柄。只有当需要对分区进行访问时，才将需要访问的数据通过 kvcache 动态加载起来。 我们做到了让 OceanBase 4.0 可以在较小内存的规格下，支持较大数据量的高并发访问。

三、在小规格下的性能对比

为了测试小规格下的实际性能效果，我们基于三台 4C16G 的服务器，按照 1:1:1 模式来部署 OceanBase 社区版 4.0，并同时和 4C16G 的 RDS for MySQL 8.0 通过 Sysbench 进行性能对比， 可以看到绝大多数场景中，OceanBase 社区版 4.0 的性能都优于 RDS for MySQL 8.0，尤其在 Insert 和 Update 两个场景中，同样的硬件条件下，OceanBase 社区版 4.0 的吞吐量表现是 RDS for MySQL 8.0 的 1.9 倍。

图5 OceanBase 社区版 4.0 & RDS for MySQL 8.0 Sysbench 性能测试结果（吞吐量，4C16G）

此外，我们也在用户最为常用的 8C32G、16C64G、32C128G 场景，分别进行了对比测试。随着服务器规格的提升，OceanBase 社区版 4.0 与 RDS for MySQL 8.0 的单机性能差距逐渐拉大。 在 32C128G 的硬件规格下，OceanBase 社区版 4.0 吞吐量最高可达 RDS for MySQL 8.0 的 4.3 倍，响应时间缩短至 RDS for MySQL 8.0 的 1/4。

图6 OceanBase 社区版 4.0 & RDS for MySQL 8.0 Sysbench 性能测试结果（吞吐量）

点击查看大图
表1 OceanBase 社区版 4.0 & RDS for MySQL 8.0 Sysbench 性能测试结果（吞吐量和响应时间）

4、写在最后

无论是对大规格 TPC-C 测试中上千台机器下极致性能的追逐，还是对小规格 4C16G 单台机器测试下极致的资源使用，背后始终不变的是 OceanBase 的初心：让数据管理和使用更简单。把复杂留给自己，把简单留给用户，是每一位 OceanBase 工程师的信念。OceanBase 还在快速成长，也还并不完美。无论是更大规格下的性能优化，还是更小规格下的资源节省，我们都还有大量的工作要做。OceanBase 社区版 4.0 版本已经上线，我们也期待和所有用户一起，打造一款真正好用、通用的数据库。