关于作者
赵裕众
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 的小型化，不仅可以在具备完整功能的前提下实现单机部署，更重要的是能在同等硬件下实现更好的性能。
OceanBase 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 可以在较小内存的规格下，支持较大数据量的高并发访问。
OceanBase 在小规格下的性能表现
为了测试小规格下的实际性能效果，我们基于三台 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 性能测试结果（吞吐量和响应时间）
写在最后
无论是对大规格 TPC-C 测试中上千台机器下极致性能的追逐，还是对小规格 4C16G 单台机器测试下极致的资源使用，背后始终不变的是 OceanBase 的初心：让数据管理和使用更简单。把复杂留给自己，把简单留给用户，是每一位 OceanBase 工程师的信念。OceanBase 还在快速成长，也还并不完美。无论是更大规格下的性能优化，还是更小规格下的资源节省，我们都还有大量的工作要做。OceanBase 社区版 4.0 版本已经上线，我们也期待和所有用户一起，打造一款真正好用、通用的数据库。
