当前位置：首页 > news >正文

单机分布式一体化数据库的架构设计与优化

news 2025/7/9 14:54:07

作者：杨志丰，OceanBase产品总经理、首席架构师

本文摘自《OceanBase社区版在泛互场景的应用案例研究》，欢迎点击链接阅读详细内容。

综述

在OceanBase 十余年的技术演进中，共经历了三次大的架构升级：第一次架构升级是 OceanBase 0.1~0.5 版本（2010 年~2015 年），当时的 OceanBase 通过单写多读架构实现了准分布式，包含 UpdateServer、ChunkServer、MergeServer 等多种不同的角色；第二次架构升级是 OceanBase 1.0~3.0 版本（2016 年~2022 年），OceanBase 成为一个对等的全分布式架构，所有节点可读可写，逐步支持了完整的 SQL 功能；第三次架构升级是OceanBase 4.0 版本，于2022年8月正式被提出，是业内首个单机分布式一体化数据库。

OceanBase 4.0版本有一个形象的比喻叫做“小就是大”。这是因为，单机分布式一体化的核心是采用一套系统，实现从单机到分布式的转换，使用户无感知。通过单机分布式一体化架构，满足用户从小到大的业务规模化诉求：用户无需关心集中式或分布式技术路线选型，可以在业务量小的情况下从小规格单机部署起步，使用完备功能的单机部署形态，随着业务压力的变化将数据库从单机平滑扩容到多机甚至超大规模的分布式集群，同时具备多机平滑缩容到单机的能力。也就是说，通过一套数据库满足业务从小到大的集中式和分布式架构诉求，用一个系统满足每一个用户业务从小到大的全生命周期数据存储与管理需求。

本文从技术角度简要介绍单机分布式一体化架构的设计思路、技术优化和业务价值。

一、三次架构迭代，从分布式到单机分布式一体化

（一）从原生分布式到单机分布式一体化的技术挑战

OceanBase 从 2010 年开始研发，彼时分成存储和计算两层。上层是无状态提供 SQL 服务的服务层，下层是由两种 server 共同组成的存储集群。这样的架构具备一定的扩展性，尤其是读扩展性较强，并且 SQL 层是无状态的，可以自由伸缩。但该架构最大的问题是单点写入、多点读，导致在更大规模并发要求下，无法扩展。同时，存储层和SQL层的割裂使时延难以控制。

为解决上述问题，OceanBase 摒弃之前的架构，发展出了 OceanBase1.0 ~3.0 的架构，所有的节点都可以在处理 SQL 的同时，处理事务并保存数据。如图1所示，纵向为分布式可扩展层，通过不断加机器提升扩展性；横向为复制层。提供服务高可用能力。

图1 OceanBase1.0-3.0架构

在该架构下，OceanBase成为彼时唯一通过 TPC-C 测试的分布式数据库，证明了该架构的扩展性和并发处理能力可以满足绝大多数当前世界上在线服务系统需求。

但随着业务需求的迭代，OceanBase在走向通用数据库的道路上，希望能够支撑更小规模的应用。但卡点在于：3.0版本的架构下，事务日志流数目和存储分片数是对应绑定的，存储分片的粒度决定事务处理和高可用能力是相应粒度，这就导致存储分片增多，日志流随之增多，在越小规模的业务系统中，开销显得越大。因此，需要将存储分片数和事务日志流解耦，让若干个存储分片共享一个事务日志流以及这个日志流对应的高可用服务，实现扩展性与成本的平衡，以更好地支撑小规模应用。

此外，考虑到业务的发展规律与生命周期，数据库需要具备从支撑小规模应用的单机模式，平滑过渡为可处理海量数据的分布式模式。单机分布式一体化架构便被创新性地提出，该架构要求兼具分布式的扩展性和集中式数据库的功能和单机性能。事务的 ACID（ Atomicity，Consistency，Isolation，Durability）是数据库的基本要求，而分布式数据库的难点就在于如何在异常场景下保证事务的 ACID，核心就是如何基于重做日志（Redo log）实现故障恢复，以及基于重做日志实现异常场景下分布式事务的原子性。

为了真正实现一体化，需要解决如下三个关键的技术问题。

（1）应用透明： 从单机到多机不需要应用做改造，需要客户端支持动态路由技术，当后端数据库发生分区迁移时，能够动态路由到目的服务器上。另外，不管是单机还是分布式，需要支持全部的 SQL 功能。

（2）单机操作： 单机只有一个 redo 日志，单机事务写 redo 日志的方式和经典的单机数据库相似。经典的单机数据库采用B+树存储引擎，OceanBase 的技术创新是将 B+ 树数据分块的思路融入 LSM 树存储引擎，一方面能够像 LSM 树一样具备高压缩能力，并把热点数据放在内存中提供服务，另一方面通过类似 B+ 树的数据分块思路来减少 LSM 树的写入放大。在OceanBase 4.1版本中，即使在三台机器做强同步的情况之下无论是单机的性能还是存储成本都优于 MySQL 8.0。

（3）跨机操作： 跨机操作通过底层的分布式架构提供，上层的 SQL 功能不受影响。如果事务只涉及一台机器，走单机事务；如果涉及多台机器，通过两阶段提交实现分布式事务。另外，通过分布式、并行、异步化等技术手段尽可能地优化性能。

（二）可行性分析，如何消除分布式带来的overhead？

架构设计的首要任务是可行性分析，核心在于取舍。在设计OceanBase单机分布式一体化架构时，我们也做了这样的设计假设：对于一个分布式数据库，虽然能够处理的数据量很大，但大部分操作仍为单机操作（>80%），少部分操作才是跨机操作（<20%）。

基于早期OceanBase在阿里体系内部推广的经验：在泛互行业，To C 的在线业务基本都能够按照用户号 (user_id) 做 sharding 实现分布式，后续的绝大部分操作都是单用户内部的操作，只有非常少数的跨用户操作；金融行业类似，大部分时间都在读写自己的账户，少部分时间才做转账等跨账户操作。于是，系统的优化目标变成：首先确保 80% 的单机操作没有任何分布式相关的 overhead（本文指额外开销），这部分操作能够和单机数据库站在同一起点比较性能，其次才是优化另外 20% 跨机操作的性能，尽可能追求极致。

单机操作的分布式相关 overhead 主要来自于两个方面：一方面是高可用，另一方面是可扩展性。曾在2023年，支付宝 Oracle DBA 分享其经验：当 Oracle 打开强同步时，性能降低至少 30% 。OceanBase 为了实现无损容灾，底层采用了基于 Paxos 的强同步方案，即通过改变架构以达到单机高性能。

我们的做法是把数据库中的 redo 日志提交给异步化，以避免数据库内部的工作线程等待日志提交返回结果，即使网络和磁盘情况较差，强同步带来的开销也相对小。我们使用 sysbench 对 OceanBase 三台机器强同步进行性能评测，结果表明 Paxos 强同步对于 OceanBase 的性能损失只有 8% 左右。这是完全可以接受的，且可以通过其它模块的优化弥补这部分损失。可扩展性带来的性能损耗主要是数据分片导致的，每个数据分片都需要写单独的 redo日志，可以简单地把每个数据分片想象成一个 mini 数据库，分片越多，每台机器上分片管理相关的分布式 overhead 就越大。

单机分布式一体化架构的创新就在于动态日志流。每台机器上的每个租户只有一个日志流，一个租户上的所有数据分区都动态绑定在该日志流之上，从而避免大量日志流导致的 overhead。另外，分区到日志流是动态绑定的，当系统增加新的服务器时，可以把分区从源端的日志流动态解绑并重新绑定到目的端的日志流，从而实现分区动态迁移。

二、技术优化：通过改造日志流，保证单机和分布式的灵活切换及性能与扩展性

在传统数据库方案中（见图2），随着业务规模的增长，选型路径会经历从支撑小型业务的小规格 MySQL，到支撑中型业务的高规格的 Oracle，再到大型业务使用 Oracle RAC 解决基础的扩展性问题，后续可能还要升级到小型机+DB2 的方案承载核心业务。

图 2: 企业业务规模与数据库选型策略示意图

这一传统路径存在几大缺陷。首先，扩展性存在天花板，无法做到随业务体量无限灵活扩展。其次，每次升级改造都涉及大量软硬件的替换，带来无法估计的成本。最后，这条升级路线是“单行道”，面对现实场景中更曲折的业务变化难以“回头”，无法规避超额的成本投入。

OceanBase“单机分布式一体化”概念的提出，旨在探索用一套解决方案，应对企业在不同发展阶段、不同业务体量带来的不同挑战，让数据库伴随业务成长，满足企业“一次选择支撑全生命周期业务发展”的需求。

OceanBase 的“单机分布式一体化”架构在部署形态（见图3）方面有两层含义。第一层含义是指同一个 OBServer 既可以单机部署，也可以分布式部署。第二层含义是在 OceanBase 分布式集群中，可以存在单机形态的租户。并且，无论在租户层面还是集群层面，单机和分布式的形态可以灵活调整切换，以便企业选择最适合当前需求的部署模式。

图 3: OceanBase 单机分布式一体化产品形态示意图

在初始阶段，企业可以使用小规格机器部署单机 OceanBase。随着数据规模的增长，可以选择替换更大规格的单机进行垂直扩展，同时主备库、三副本等部署模式支持企业的容灾和高可用需求。当数据规模进一步扩展时，企业可以选择水平扩展，扩大集群规模，支撑大型业务。

“单机分布式一体化”听起来并不复杂，当一个数据库可以解决复杂的分布式事务时，似乎单机部署也并不是一件难事。然而事实并非如此。在分布式架构方面，OceanBase 多年来在分布式 TP 领域的丰富经验，以及打破 TPC-C 世界纪录的成绩已经证明了其处理分布式事务的能力。因此在面对“单机分布式一体化”命题时，挑战主要存在于“单机”和“一体化”两方面。

挑战1：如何提升数据库在小规模单机模式下的性能，使其与单机数据库相当？

分布式系统为了实现分布式事务的原子性和持久性，其日志流设计相比单机数据库会产生更大的开销，支撑单机事务和小规格分布式事务的性能表现显著低于单机集中式数据库。对一些企业来说，采用分布式系统反而会导致数据库性能下降，因此宁愿选择用更高成本对现有数据库进行机器规格上的垂直升级。

具体而言，日志流是数据库实现事务原子性和持久性的保障。基于日志流，分布式数据库为了保证原子性而引入了两阶段提交等分布式事务协议；为了保障持久性，又引入了 Paxos 等选举协议。这些相比单机数据库额外增加的操作也带来了更大的开销。另一方面，分布式的写入是多点的，因此会产生多条日志流。日志流的数量会影响参与两阶段提交和参与 Paoxs 选举的组的数量，从而影响分布式事务的开销。

在常见的分布式系统中，日志流的数量对应数据分片的数量，数据量越大，分区的数量越大，分布式事务的开销就越大、性能受到的影响越明显。想要让分布式数据库的单机性能和单机数据库性能相媲美，就需要降低日志流的数量。

面对这一问题， OceanBase 的做法是将日志流的数量降到和节点数相关。单机部署模式下的 OceanBase，从架构上来说和传统的单机数据库没有区别，只有一条日志流，在进行分布式扩展时，日志流数量仅与节点数相关，分布式代价的增长显著降低。

通过对日志流的改造，OceanBase 实现了在单机模式和小规模分布式部署模式下，性能与单机数据库相当。如图4所示，在 4C16G 的小规格场景下，Sysbench 测试结果显示，OceanBase 4.0 的 insert 和 update 性能可以达到 MySQL 8.0 的两倍，其他几项性能也能做到与 MySQL 8.0 相当。同时，单机部署模式下，OceanBase 的存储成本更低。经测试，在 TPC-H 100G 场景下 OceanBase 4.0 的存储成本仅有 MySQL 的 1/4。

图 4: 4C16G 规格 Sysbench 性能测试对比 OceanBase 社区版 4.0 v.s RDS for MySQL 8.0

挑战2：如何在不牺牲性能的情况下，实现单机模式和分布式的灵活调整切换？

解决了单机和分布式部署模式下的性能问题，如何在不牺牲性能的情况下保障水平方向的灵活扩展成为了单机分布式一体化架构需要解决的另一个问题。

除了前文提到的，通过对日志流的改造，在进行水平扩展时，日志流数量随节点数增加，从而减少开销之外，OceanBase 还引入了多种方法，支持用户通过手动或自动的方式提升扩展性能。

作为分布式数据库，为了满足扩展性和多点写入等需求，OceanBase 数据库支持分区功能，即将一个表的数据分成多个分区来存储，将分区方式相同的表聚集到一起就形成了表组。在系统进行负载均衡时，表组可以帮助用户将具有关联关系的数据聚集在同一台机器上，即同一个表组的表会被绑定在同一个日志流中。通过设置表组，用户可以避免大量的跨机器操作，从而有效降低连接场景下的数据传输的开销，提升性能。极端情况下，如果一个事务涉及的表在一个表组内，那么它即为一个单机事务，不会存在分布式开销。

OceanBase 也提供了自动化的调度，帮助提升扩展性能。例如 OceanBase 支持自动对 RPC 进行聚合，还支持通过自动负载均衡将分布式事务的分区调度在一起，减少分布式开销。

图5展示了 TPC-C 测试 OceanBase 集群节点数从 3 台机器扩展到 1500 台机器的过程中，tpmC 的数值变化。测试结果表明，即使在包含 10%分布式事务的情况下，OceanBase 集群性能仍能随集群规模扩展实现线性提升。

图 5: TPC-C 性能测试 OceanBase 在不同节点数规模下 tpmC 值变化情况

基于上述技术优化，OceanBase单机分布式一体化架构，一方面具备单机数据库高性能、低成本的优势，帮助客户降本增效；另一方面具备分布式数据库高可用、可扩展等优势，帮助客户更好地挖掘数据价值。此外，还拥有三个特点：灵活、简单、开放。

1.灵活。

除了上文提到的单机和分布式模式灵活切换外，OceanBase 通过内置的多租户隔离架构，能够实现共享实例，从而尽可能降低成本。当用户的业务量越来越大时，通过单机分布式一体化架构，可以逐步从小规格实例扩展到分布式实例，灵活扩容、缩容。

2. 简单。

OceanBase 4.0 希望降低数据库选型和运维的复杂度，尽可能用一套数据库满足不同场景的需求。一方面，单机和分布式的架构差异可以通过上文提到的动态日志流方案统一起来；另一方面，在一套系统中实现 OLTP、实时 OLAP、Key-Value、JSON、GIS 等多种数据模型的处理，避免用户因为基础设施能力不足而采用多套系统。

3.开放。

OceanBase 早期版本支持本地部署，后来逐步支持多云部署，并选择开放的存储计算分离方案。具体做法是抛开 SQL 和 KV 分层方案，数据库读写数据块时支持本地或者远程的各种分布式文件系统，数据库用来做计算，文件层用来做存储。这种方式最大的难点是需要将高可用和可扩展的处理融入到分布式事务，实现复杂，好处是保证了性能和开放性，数据库内部的 SQL 和 KV 模块之间不再需要 RPC 交互，且能够适配多云平台上的各种存储系统。另外，OceanBase 在设计存储格式时降低了对外部文件系统的依赖，以便用户可按实际业务需求，将数据库部署到不同的云平台甚至多云，并确保系统稳定和高性能。

三、一次选择支撑业务全生命周期发展

对用户和开发者来说，单机分布式一体化架构看起来什么都行，既能做单机，又能分布式，现阶段的侧重点到底是什么呢？短期来看，OceanBase 单机分布式一体化能力对于用户和开发者有以下两个维度的价值和意义。

（1）极大地降低分布式数据库的门槛。 原先的 NewSQL 单机性能太差，业界主流的 NewSQL 系统如 CockroachDB 和 YugabyteDB 的单机 sysbench 性能只有 MySQL 的 1/5 ~ 1/10（数据日期：2023年）。随着单机分布式一体化数据库逐步成熟，这类 NewSQL 会被逐步取代。同时即使是在分布式部署场景下，相较于其他分层的分布式数据库，OceanBase 的性能有很大的优势，如果用户做精细控制的话，单机事务比例增加后，效率可与单机数据库相当。目前已经有很多用户将 NewSQL 系统替换为 OceanBase 以实现降本增效。

**（2）解决用户从小到大扩展的需求。**大多数中小企业的业务发展在不同的发展阶段对数据库规模和性能有着不同的需求。OceanBase 既可以单机方式部署，提供单机数据库相当的能力，并且可以在任何时刻，管理员可以去做形态的变换，由一个单机的形态变成分布式形态，从分布式形态变回单机形态，动态切换。相较之下，即使业务现阶段数据量不大，采用单机数据库足以支撑，但对比业务发展后再修改应用更换数据库，选择一开始就采用单机分布式一体化数据库，显然是更好的选择。

总结而言，OceanBase通过原生分布式保障分布式事务 ACID 的同时提供满足扩展性需求，在业务无感知的情况下支撑企业实现快速迭代升级；通过单机分布式一体化架构，有效支撑企业全生命周期的规模与需求变化，伴随业务成长，从根源解决企业数据库应用难题。