OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考

关于作者
赵裕众

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 可以随着用户的业务增长进行弹性扩容,能够从小到大支持用户全生命周期的数据库需求,帮助用户更好地降本增效、进行业务创新。

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

 

OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第1张图片
图1 不同业务规模下 OceanBase 与传统数据库部署方式演进对比

 

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

 

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

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

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

 

OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第2张图片
图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 日志流的数量减少到与服务器个数同量级的程度,那么这部分开销就和传统数据库主备库模式下的日志开销差不多了。

 

OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第3张图片
图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 会让一部分元数据在内存中常驻,当内存规格较大时,这些内存所占的比例并不是很高;而当服务器规格要降低到很小时,这些元数据内存的大小就变得难以接受了。为了带给用户更加极致的小规格能力,我们实现了所有元数据的动态加载。

 

OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第4张图片

图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 倍。

 

OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第5张图片

图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。

 

OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第6张图片 OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第7张图片
OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第8张图片 OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第9张图片

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

 

OceanBase 4.0 解读:降低分布式数据库使用门槛,谈谈我们对小型化的思考_第10张图片

表1 OceanBase 社区版 4.0 & RDS for MySQL 8.0 Sysbench 性能测试结果(吞吐量和响应时间)

 

写在最后

 

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

你可能感兴趣的:(技术解读,数据库,分布式,oceanbase)