分库分表还是分布式？如何用 OceanBase的单机分布式一体化从根本上解决问题

随着企业业务规模的不断增长，单机集中式的数据库系统逐渐难以承载企业日益增长的数据存储与处理需求。因此，MySQL 的分库分表方案成为了众多企业应对数据存储量激增及数据处理能力需求扩张的“止痛药”。尽管这一方案短期内有效缓解了企业面临的大规模数据处理压力，但同时也引发了一系列棘手的问题。

01 分库分表：业务需求扩张的短时止痛药

数据库经过了数十年演进，在分布式技术飞速发展的今天，即使大家对分库分表的缺陷已经有了一定认知，关于“分库分表还是分布式”的争论依然屡见不鲜，分布式系统似乎仍然没有完全取代分库分表方案。许多企业认为，分库分表在原有的 MySQL 技术栈上进行改造，可以充分利用成熟的技术经验，在短期内足以解决业务增长带来的问题。而在分库分表可以应对当前业务规模的情况下，还有必要进行分布式升级吗？

程序员界有一条“真理”——“过早优化是万恶之源”。这是由计算机科学先驱 Donald Knuth 在《计算机程序设计艺术》中提出的一项优化原则，他认为在为时尚早的时候过度关注效率提升和软件性能优化，往往会适得其反，带来大量的资源浪费，提醒人们在进行程序设计时需要优先考虑业务的真实需求，减少不必要的优化投入。分库分表似乎是对这一原则的践行：面对业务需求扩张时，采用最自然的思路，在已有系统的基础上进行过渡式改造，避免根本性的替换。

同样地，在通过分库分表就可以解决眼下问题时，似乎没有进行分布式升级的必要。

然而事实却与期望背道而驰。回顾分库分表的出现，表面是因为企业在业务体量扩大时需要有效处理大规模数据的分布式方案，其本质却是随着企业发展，业务的快速变化带来的需求变更，强调的是底层资源应当具备灵活支撑上层业务发展迭代的能力。

分库分表因为业务快速发展的需求而生，却恰恰无法灵活地支撑上层业务变化迭代：

分库分表对业务侵入性强，在底层数据库发生扩展、变更时，上层业务也需要进行相应的改造，将数据库本身的压力转嫁到业务层，无法满足企业忽略底层设计、专注上层业务开发、快速迭代的需求。
分库分表系统架构复杂，不仅增加运维负担，当业务需求发生变化时，还需要重新设计合理的分库分表方案以保障系统性能。而企业在各个阶段遇到的业务需求不同，不可能在分库分表的基础上不断缝缝补补来支撑全生命周期的发展。

在企业的初始阶段，业务量比较小，一台小规格 MySQL 即可承载数据库业务；随着业务体量增大，企业可以选择提升机器规格，或者进行分库分表。但随着业务继续扩张，需要更高扩展性时怎么办？核心业务可用性需求提升，要求主备容灾时怎么办？业务缩水或出现变化，系统需要瘦身时怎么办？随着每一个阶段业务需求的变化，每次系统改造都会带来翻天覆地的变化。因此，分库分表只是对企业规模扩张短时间内有效的“止痛药”，既无法根治企业追求分布式事务性能的“标”，也无法解决企业在不同发展阶段业务需求持续变化、需要数据库系统灵活应对的“本”。

《汇编语言的编程艺术》的作者、资深软件专家 Randall Hyde 在一篇博客中分享道，“不要过早优化”并不等同于“不要优化”，其原意是指在拘泥于微观优化之前，更应当关注会影响全局性能的系统性问题。他还提到，“设计软件时，应该从一开始就考虑性能问题。一个好的软件开发人员会自动做到这一点，他们大概知道性能问题会在哪里出现。没有经验的开发人员不会关注这个点，错误地认为在后期进行一些微调可以解决任何性能问题”。

那么，在系统设计的一开始，从根源真正解决分库分表难题，需要怎样的一款数据库解决方案？

OceanBase 给出的答案是：通过原生分布式 + 单机分布式一体化架构。不仅要将所有的分布式工作封装在数据库内实现，使业务无需关心底层架构即可实现快速迭代，还要关注企业在各个发展阶段会面临的不同业务需求，帮助企业摆脱频繁的系统改造，集中于上层业务拓展，打造伴随企业全生命周期的发展的数据库解决方案。

02 治“标”：原生分布式屏蔽底层复杂性
灵活扩展，助力业务快速迭代

回顾分库分表方案的缺陷，首先，在分库分表系统中跨库跨表的事务处理难度高，难以保障数据的完整性和一致性。其次，分库分表的数据库性能强依赖于分区策略的设计，导致架构复杂性增加与运维难度增加，如果没有合理的设计、某些表集中了大量的读写操作，则会引发严重影响性能的热点问题。

同时，跨库跨表查询、数据聚合和报表生成等操作复杂度高，性能受制于多种因素，往往需要额外的优化技术和中间件支持。在容量规划、扩展、迁移时，都需要重新进行规划设计，对系统稳定性和数据完整性带来巨大考验。另外，分库分表方案要求业务代码需要直接或者间接感知到分库分表的逻辑，增加了业务代码与数据库之间的耦合度，导致了维护和扩展困难。

这些缺陷都是由于分库分表使用中间件在集中式数据库的基础上构建分布式系统，其内核仍然是集中式设计，并非为处理分布式事务而生，难以适配分布式架构的需求。

OceanBase 原生分布式摒弃了分库分表方案利用中间件处理分布式事务的思路，在系统架构设计和分布式事务实现等层面原生融入分布式基因，打造真正为分布式而生的数据库。

在系统架构设计方面， OceanBase 采用分区表（Partition Table）的设计思想，实现了在原生分布式架构下的水平扩展和数据管理，从根源上解决了传统分库分表强依赖于中间件和分区策略设计带来的复杂问题。OceanBase 的底层架构支持数据在多个计算节点（OBServer）之间进行水平扩展。分区的多个副本可以分布在不同的 Zone（可用区）中，通过 Paxos 协议保障副本间跨节点的数据一致性，并确保分布式事务的 ACID 特性，同时支持多副本和跨数据中心容灾，提供金融级别的高可用保障。此外， OceanBase 直接通过数据库内部的分区机制进行水平扩展和灵活调整，无需用户自行设计和维护复杂的分库分表策略，减轻了分布式数据库设计和运维的复杂度。

OceanBase 引入路由机制，帮助上层业务屏蔽底层逻辑，应用程序无需关注数据具体分布在哪一台服务器上，能够像操作单体数据库一样处理分布式数据。当客户端发起 SQL 查询时，OBProxy 会根据分区键的值确定数据所在的分区，并将请求路由到合适的 OBServer 上执行。OceanBase 在底层对 SQL 的分布式执行和分布式事务进行了封装，这种透明路由机制使得应用程序无需关心具体的分库分表细节，对上层业务完全透明。系统支持在线扩容、缩容和迁移，从而支撑上层业务的灵活变化与迭代。

图 1: 分库分表与 OceanBase 原生分布式架构对比

此外，OceanBase 原生分布式还通过多种架构设计，相比分库分表做到了成本的降低和性能的提升。一方面， OceanBase 基于无共享架构，使用普通 PC 服务器构建集群，对比传统分库分表所需的高端存储设备和 License 费用，大幅降低了硬件和软件成本，提高资源利用率。另一方面，OceanBase 的分布式查询优化器在分布式环境下智能调度执行计划，减少跨节点数据传输和处理，保障高查询性能，同时通过分区表和本地索引等功能有效地处理分布式查询，降低操作延迟。

03 治“本”：单机分布式一体化支撑企业全生命周期发展

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

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

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

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

OceanBase 的“单机分布式一体化”架构在部署形态方面有两层含义。第一层含义是指同一个 OBServer 既可以单机部署，也可以分布式部署。第二层含义是在 OceanBase 分布式集群中，可以存在单机形态的租户。并且，无论在租户层面还是集群层面，单机和分布式的形态可以灵活调整切换。

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

如上图所示，OceanBase 的单机分布式一体化允许企业在业务发展各阶段灵活调整数据库架构，选择最适合当前需求的部署模式。

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

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

第一，如何提升数据库在小规模和单机模式下的性能，使其与单机数据库相当？

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

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

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

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

通过对日志流的改造，OceanBase 实现了在单机模式和小规模分布式部署模式下，性能与单机数据库相当。

图 4: 4C16G 规格 Sysbench 性能测试对比

OceanBase 社区版 4.0 v.s RDS for MySQL 8.0

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

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

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

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

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

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

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

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

04 原生分布式 + 单机分布式一体化
助力现代化数据架构升级

OceanBase 原生分布式+单机分布式一体化能力已经被应用在多种场景中，替代分库分表方案，助力企业实现现代化数据架构升级。

💡 快手：应对流量洪峰，OceanBase 替换 MySQL 分库分表，单集群稳定支撑超百 TB 海量数据

快手（Kwai）是中国北京快手科技有限公司开发的短视频移动应用程序。前身为 2011 年面世的一款制作、分享 GIF 图片的应用“GIF 快手”，2012 年转型为短视频社区，2014 年改名为快手。2021 年，快手科技在香港联交所主板挂牌上市，截止 2021 年年底，快手平均日活跃用户为 3.08 亿，平均月活跃用户 5.44 亿，为中国头部短视频平台。

快手过往使用 MySQL 作为其数据库解决方案。随着订单业务量的增加，业务数据迅猛增长，单机集中式数据库性能遇到瓶颈。于是引入分库分表方案来暂时应对存储和性能问题。随着业务进一步增长，底层数据库分片数不断增加，快手线上 MySQL 分片数达到 300+。此时，不仅运维成本和复杂度有所增加，而且需要不断对应用进行改造和适配以解决不断分库分表带来的问题。快手意识到，当前的方案只能短时间缓解业务遇到的问题，而无法从根本上解决。因此，快手亟需能在满足性能要求的同时降低使用、运维复杂度的数据库解决方案。

通过对多种分布式数据库的考察，快手最终选择 OceanBase 原生分布式数据库，并在核心业务场景实践应用。

以交易核对场景为例。一般情况下电商的日均流量 QPS 稳定在 8-9w。进行大型直播时，用户流量剧烈增长，QPS 能达到平时的十倍甚至百倍，达到百万级别，即使数据量压缩也会达到百余 TB。且直播期间业务对延迟和系统稳定性高度敏感。在使用 OceanBase 之前，交易核对场景读写使用 MySQL 分库分表方案，将大表拆成多个小表，把业务读写流量拆分到多个 MySQL 实例。由于分库分表方案的跨库数据一致性和跨库事务原子性，在复杂和异常情况下容易出现数据不一致问题，导致数据核对时出现不正确的结果，如没有退款、扣款金额不准确，出现资损问题。

使用 OceanBase 后，上游业务直接写入 MySQL 集群中，同时每一条数据写入上游 MySQL 分片时会通过 Binglog 实时写入 OceanBase 中。数据核对查询时，在查询上游 MySQL 集群时会同时触发向下游 OceanBase 进行相同的查询，并对上下游的查询结果进行比对，从而保证整个账务系统中订单状态的正确性。

下图是交易核对业务线上 QPS 的表现，左侧为日常 QPS，数据量 9 万左右，右侧为响应时间，平均时延不超过 10ms，峰值显示 1 万毫秒（由于每晚凌晨全量合并后业务额外启动一个特定线程去删除一些对应历史数据，删除的数据量很高导致此时时延偏高，业务方可以接受）。图的下方是写入量，按事务统计的日均 1 万 TPS 左右，响应时间为 5-10 毫秒，OceanBase 响应时间满足业务对延迟的要求，同时系统稳定性得到保障。

图 6: 快手交易核对业务场景 OceanBase 线上表现情况

目前，快手已落地 8 个 OceanBase 集群，机器规模超过 200 台物理机，数据量超 800T，最大集群数据量超 400T。借助 OceanBase，快手在实现资源灵活扩展的同时，数据同步延迟减少 3/4，存储成本有效降低（例如减小 50 台机器的硬件成本），容灾能力达到 RPO =0、RTO<8s ，单集群即可替换 300+ 套 MySQL 环境，显著降低运维成本。

💡 科大讯飞：灵活扩展+原生分布式，OceanBase 有效支撑业务快速迭代

科大讯飞是亚太地区知名的智能语音和人工智能上市企业（股票代码：002230）。自成立以来，一直从事智能语音、自然语言理解、计算机视觉等核心技术研究并保持了国际前沿技术水平。

科大讯飞以往采用 MySQL 作为其业务数据库。2023 年，在一次非常重要的业务上线时，初上线的整体业务量很小，但后续呈现爆发式增长，数据量和磁盘占用几乎直线攀升，同时该业务的报表有多维度、实时性的分析需求，以供业务决策。科大讯飞很快发现 MySQL 已经无法满足业务需求，亟需提升系统扩展能力。

在选择数据库升级方案时，科大讯飞对比了 MySQL 分库分表方案和原生分布式数据库方案。虽然科大讯飞历史使用 MySQL 的业务较多，运维架构也非常成熟，然而，MySQL 对业务有侵入，需要改造业务，分库分表也给整体运维增加了工作量。由于新业务更新迭代快速，频繁有大表上线和更新操作，以及业务处于关键阶段，希望尽可能减少改造代价，如果继续使用分库分表方案，需要去做相应适配改造工作，增加了许多额外的工作量。

经过大量考察，科大讯飞最终选择了 OceanBase 对原有数据库进行升级，充分发挥 OceanBase 原生分布式数据库的可扩展性、可维护性、HTAP 能力、高度协议兼容和快速迁移能力，有效支撑新业务快速迭代上线。

在 tpmC 性能测试中，科大讯飞在生产环境分别对 OceanBase 三节点集群、MySQL 单实例、MySQL 分库分表进行压测（压测配置：硬盘 SSD/96C/384G）。结果显示：在并发数小于 64 时，OceanBase 性能略低于 MySQL 方案；超过 128 并发后，OceanBase 性能优势显著。且随着并发的不断增长，OceanBase 集群性能可以持续提升，而 MySQL 性能在 256 并发时达到顶峰，随后出现拐点，无法继续提升。