11 月 16 日，OceanBase 在北京顺利举办 2023 年度发布会，正式宣布：将持续践行“一体化”产品战略，为关键业务负载打造一体化数据库。OceanBase 产品总经理杨志丰发表了《助力企业应对数据库转型深水区挑战》主题演讲。

以下为演讲全文：

大家好，我今天的分享正好处于承上启下的位置，主要包括几方面内容：企业数字化转型进入深水区的挑战、OceanBase 如何助力企业应对挑战以及如何用产品助力客户真正解决实践中的问题。我想通过今天的演讲，从产品角度向大家分享 OceanBase 过去几年在核心系统升级的赛道上，我的感受以及 OceanBase 为了在核心系统升级深水区，帮助客户走得更快、更远所做的一些工作。

分享伊始，我先给大家介绍一下核心系统升级进入深水区阶段后，企业所面临的一些挑战，关于这部分的内容我想首先分享一下赛迪顾问《2023 核心数据库升级选型参考》报告的几个信息。

今年上半年，赛迪顾问对 160 家企业做了深入访谈，在访谈里面有几个结论可以分享。第一，目前中国企业当前部署的数据库产品中，OceanBase在中国本土数据库品牌中排名第一；第二，在核心系统升级领域，被调研企业客户阐明了自己所关注的一些场景，比如稳定性、兼容性以及代码的自主可控等，基于大家所关注的几个核心因素，赛迪顾问对市场上一些数据库品牌做了匹配，OceanBase 以 36.5 最高分的匹配度，在未来核心系统升级选型中排名第一；第三，通过采访这些企业“未来数据库选型的时候考虑什么样的品牌”，OceanBase在未来数据库部署产品预期中排名第一。

OceanBase 为什么能在核心系统选型场景下成为客户首选？我们诞生于核心系统场景，2014 年，OceanBase 开始应用于支付宝核心交易库，这种大规模金融场景对高并发和高可用要求非常高，可以说 OceanBase 是从非常严苛的场景起步，然后一步步走到外围。

众多领域的客户正在选择把 OceanBase 应用于核心系统，我们总结了一下他们在使用 OceanBase 过程中的几条技术路线，特别是在核心系统的升级场景里。

路线 1：应用不动，Oracle 平滑迁移

“应用不动，Oracle 平滑迁移”的升级路线是数据库平滑升级最具代表性的一种方式。以某大型保险集团为例，该集团用短短一年的时间，把 300 多套 Oracle 数据库全部升级到了 OceanBase，在一年多的升级过程中，几乎每周都有新系统在上线，我们非常敬佩客户的技术团队，和我们一起完成了几乎不可能完成的任务。在这个过程中，得力于 OceanBase 平滑迁移、兼容 Oracle 等能力，我们很好地保护了企业既有软件投资，比如原有数千万行业务应用系统的代码几乎没有做改造，这种替换比起同时改应用、同时改数据库这样的方式更加稳妥、更加可控，这也是该案例之所以能够快速完成的一个关键因素。

路线2：DB2 迁移到 Oracle 兼容，微改动实现“单核异构”

“DB2 迁移到 Oracle 兼容，微改动实现单核异构”的路线是针对使用 DB2 的一些中小银行为代表的客户所推出的。市场上提供 DB2 平滑升级的产品不多，而Oracle与 DB2 这样的商业数据库能力是互相匹配的，比起开源数据库它们的能力也强很多，所以在 OceanBase 之前，很多客户会把 DB2 替换成 Oracle，当OceanBase 具备了 Oracle 兼容能力以后，以常熟农商银行为代表的客户，他们把 DB2 小机应用做微小的改动，基本所有的能力都能在 OceanBase 的 Oracle 兼容性能力里找到对应的功能去替换。而且 DB2 有一个 Oracle 兼容的功能，模式打开以后会使得这个替换更加平滑。

在升级之后，OceanBase 实现了和 DB2 双向长期的同步和过渡，所以 DB2 还可以作为一个备库进行长时间的运行。同时，OceanBase 可以在同一个库里去支持不同的 CPU，也可以同时支持国产化硬件，我们称之为“一库多芯”。

路线3：云 + OceanBase + 单元化

“云 + OceanBase + 单元化”的第三条路线，适用于企业期望在做核心系统升级的同时，愿意对整个应用做比较大的单元化改造场景。如果企业愿意投入重新写应用的成本，单元化的改造会大大降低应用的故障率，对于整个应用的高可用能力也会有质的提升，在数据库领域之外，实现综合效益的提升。

以某国有大型银行贷记卡项目为例，通过把原来整个 DB2 大机的应用切换到 OceanBase 之上，然后在 OceanBase 里创建 100 多个租户，单个租户是独立的单元，应用也一样进行切分成多个单元，整体减少故障率。但是这种演进方式下，由于它是 DB2 的大机，所以无法做平滑升级，但在此过程中，该银行得到了单元化的收益，OceanBase 在这个过程里，进一步支撑了该银行在数据库层面应该有的能力。

路线4：MySQL 平滑迁移

“MySQL 平滑迁移”的路线适用于以互联网、新零售为代表的企业。这些企业的核心系统切换到 OceanBase 之上，其主要看中的功能是“集约化降本”能力。以 GCash 为例，原来使用的是 240 多套的 MySQL 数据库，迁移到 OceanBase 以后，使用 OceanBase 的 16 个集群就可以承接原来 DBA 要维护的 200 多套数据库，现在只需要维护 16 套，大大简化了运维工作。与此同时，迁移之前，GCash 的数据有 5TB，迁移到 OceanBase 之后仅 500GB，数据量降至原来的 1/10，总体成本也降低了 35%。我们做了一个测算，企业如果 MySQL 规模在 32 核以上，切换到 OceanBase 之后都会有超过 30% 的成本节约。

在当前的市场背景下，不论是大型企业还是中小型企业，包括今天谈的中小型银行，现在都已经逐步进入到数字化转型深水区。我们和很多的客户进行了沟通，深水区基本上都要经过三个阶段：

第一阶段是边缘业务试点应用；第二阶段会找一个核心但不是最核心的业务去做替换升级，从简单的边缘业务到稍微复杂的；如果第二个阶段顺利，第三阶段即希望做规模化推广，这个阶段无论是小企业、中小型机构还是大型机构都会面临几个问题：

第一， 从边缘系统进入核心系统，会发现这二者所要求的数据库能力是不一样的，核心系统往往会要求数据库分析性能力比较强，不能只是单一 KV 型的访问。

第二， 进入大规模复制阶段以后，中小型企业会比较在意总体成本，大型机构虽然对成本不会特别敏感，但是也会关注快速复制过程中是否迅速，以及在此过程中最关键的性能、稳定性这方面，是否有确定性的可控收益。

在过去一年当中，OceanBase 的很多客户已经进入到第三阶段，为了满足这些客户的需求，我们在两方面做了持续、深入的产品迭代，它们也是 OceanBase 产品两个关键的演进方向。

方向1：更兼容

• 不断完善兼容性，持续降低应用改造代价

回到 OceanBase 产品的具体特性，OceanBase 在同一个集群里面同时支撑 MySQL 和 Oracle 两种兼容能力。到目前这个阶段，OceanBase 已经不是三年前了，在功能兼容性迭代的方向上，已经开始深入细节，做了很多大家可能不怎么关注得到的特性。比如，在 MySQL、Oracle 兼容性方面都同时支持了 GB18030-2022，这是国家最新的强制标准，OceanBase 比 Oracle 更早做出了在 Oracle 兼容能力下的 2022 标准。

与此同时，OceanBase 4.0 有一个比较大的突破——可以支持更多的 DDL。到目前为止，可以说所有的 DDL 类型，OceanBase 都可以去支持，这个得益于我们OFFLINE DDL 框架能力，完整支持全量 DDL。以前 DBA 如果把组件建错了，只能采取「重新导数据」的方式，而现在一个 DDL 就可以轻松将表结构的分区键做比较大的调整。

未来，OceanBase 也将会在 MySQL 兼容能力方面持续迭代，做更好的 MySQL。以这里面的特性为例，客户在选择用什么样的兼容模式的时候，使用 OceanBase 是比较自由的。有些客户喜欢 MySQL 兼容模式，那也没有问题，我们会把一些 Oracle 模式下和 OceanBase 这么多年迭代的能力同时在 MySQL 下提供，所以可以把它理解为是「更好的 MySQL」。比如在 MySQL 模式下支持了 DBLink 能力，使用 Oracle 的很多用户都了解 DBLink，但现在 OceanBase 在 MySQL 模式下，也已经提供了这个能力。

另一方面，类似像 SQL 执行计划的管理，我们叫 SPM 能力，也在 MySQL 模式进行提供。OceanBase 之前做的很多性能的视图，现在全部在 MySQL 下面提供，包括其他更多的能力都会在两个模式下同时提供，对我们来说这件事情很自然，做这件事的目的是让进入深水区之后的客户，都可以完成应用的平滑迁移。当越来越多应用迁移上来的时候，就不需要每一个应用都做那么深入的适配和改造，做一个还可以，做多了就会很困难。

• 核心系统要求交易数据库兼具复杂分析能力

为什么把上面的问题看作是兼容性的问题？比如很多的语法在一个开源数据库上做语法兼容是比较容易的，但真正做核心系统替换的时候，会发现换上去以后招数都有了，但是内力不足，这里的关键就是以 Oracle 为代表的这样一些数据库或者 DB2，早期并不会区分什么是 TP、什么是 AP，所以在这些数据库上搭建起来的应用，在核心系统层面都要求兼具 TP 和 AP 的能力。

OceanBase 从 4.0 版本开始，AP 能力较之前 3.0 版本有了极大的提升，展示几个数据：以 TPC-DS 为代表的复杂分析性能提升 3.4 倍、以 TPC-H 为代表的性能提升了 6 倍，在 AP 场景、核心系统场景里的导入性能也提升了 6 倍。

此外，OceanBase 在 MySQL 和 Oracle 两种模式下，都提供了很好的数据集成能力。数据集成有两种方式：第一种是在引擎里查询另外一个数据库，即 DBLink 的能力；第二种如果查询一个文件的数据，即外表的能力，以此快速集成外部数据，这些能力 OceanBase 在新版本全面支持。

在 TP 和 AP 混合负载的隔离能力方面，新版本有两方面提升：第一资源隔离能力增强（cgroup + CPU/MEM/IOPS...），第二资源隔离粒度变细（基于 SQL 语句）。 

如果在同一个数据库里可以识别出来一些应用，那么它就是跑批的；另外一些是交互式的，可以给这些跑批的应用设置专门的资源隔离组，我们称之为资源组能力，OceanBase不光可以将资源组以用户作区分，最新的版本里还支持绑定特定 SQL，利用这些 SQL 去限定 CPU 和 IOPS 的上限。可以说 OceanBase 在混合负载方面做了非常多的工作，去应对核心系统的诸多挑战。

• 持续完善迁移方案，从数据迁移到架构融合

关于产品内核功能方面的增强，实践者大概 50% 的时间都会关注同一个问题：在数据库升级过程中，怎么才能够平滑完成迁移？OceanBase 打磨了 10 余年的核心场景，所有的功能都体现在产品和服务里，在众多客户场景和实践中，OceanBase 沉淀出了一整套方法。

客户在做数据迁移之前，即使没有引入 OceanBase，也可以利用 OceanBase 迁移评估工具 OMA 在自己的环境里面跑一下，就可以拿到一个完整的评估报告。包括兼容度是多少、哪些 SQL 需要重写、智能化诊断建议等，包括什么表要去做分区？怎么做效果最好？这类问题的诊断建议，在第一个不需要引入 OceanBase 的阶段就可以完成评估。

当客户进入平滑迁移阶段时，OceanBase 数据迁移工具 OMS 可以帮您专门从旧的系统往新的系统迁移，当前OceanBase已经支持Oracle、MySQL、PostgreSQL、DB2、HBase 等数据库迁往 OceanBase。例如上文提到的某保险集团就利用 OMS 完成了 300 多个系统、好几百 T 数据的迁移，可以说 OMS 的迁移能力是久经考验的。

运行起来以后，一旦完成了应用的切换，OMS 会创建一条往原有数据库回迁的链路，这样一来两个系统可以并跑比较长的时间。如果是核心系统，一般作为中间数据的节点，它还要把它的数据往下游“吐”，所以 OMS 也支持数据订阅的功能。

目前来说 OceanBase 支持 ADB、Hologres 、MaxCompute 等云上服务的订阅，并且已经集成到内部了，还可以通过 Kafka 自己写程序、从 Kafka 上订阅消息同步到下游的数仓。不同于 Oracle，对于 MySQL 用户来说，MySQL的生态非常丰富，所以 OceanBase不再为每一个下游产品去做专门的对接，由于 OceanBase 原生的支持了 MySQL 的 Binlog 的服务，这样一来，所有为 MySQL 的数据订阅同步所做的那些工具，都可以无缝和 OceanBase 的 Binlog 相集成，这也是我们融入 MySQL 生态的一个动作。

方向2：更稳定

稳定可靠总是用户最关心的方面，过去一年，OceanBase 在强化稳定性方面做了很多的事情，比如，我们不再简单讲 RTO、RPO 这样的概念，而是进一步强调在更多严苛场景下，如何保证数据库、应用的连续性。说起来很简单，但是技术上每一个点都需要实际的去打磨。

• 强化稳定性，满足更严苛条件下的业务连续性

首先，4.0 版本再造“ RPO=0, RTO＜8s”新标准。RTO 从 30 秒降到 8 秒，这个过程涉及到很多细节的改动，比如现在是通过在整个集群内部广播节点宕机事件，替代以前的轮循方式，通过广播可以及时告知前端的应用“这个数据库的主发生了切换”，类似这样一些工作是非常细致的。

第二，跨城部署，实现网络带宽大幅下降。对于支付宝这类非常严苛的金融场景，我作为支付宝“去O”全过程的亲历者，当时其实不怎么担心网络带宽，但是在很多外部客户场景中，带宽不是天经地义就是非常充足的，特别是跨城的网络带宽。OceanBase 过去两三年一直在做这件事，一方面，OceanBase 4.0 跨副本之间的网络带宽下降了 30%-40%，以 TPC-C 的负载为例，其存储的带宽降低了 30%。

第三，丰富的灵活的容灾模式和更全面的安全加固。关于稳定可靠，我还是想谈 Paxos，虽然这是一个老生常谈的话题，但是这次还是想强调一下，Paxos 的三副本高可用其实还有一个额外的收益——对抖动的容忍性。我们一般讲高可用的时候一定要讨论「故障类型」，如果是简单的机房级故障、断网、光线挖掉，这其实对于分布式系统来说是容易处理的故障类型，即对于系统设计者来说是非常“干净”的故障，因为在现实生活中，常见的故障是网络的抖动，当你观察的时候它已经停掉了，对于网络抖动故障，只有 OceanBase 这样基于 Paxos 多副本高可用的协议才能容忍这样的抖动。

• 仲裁服务：自动选主提升同城自动容灾能力

4.0 版本发布以来，我们都在谈新版本比较重要的升级特性——仲裁服务，借这个场合给大家分享一下怎么把这个功能用起来。OceanBase 认为有两个典型的场景，使得我们系统更加稳定。

上图最左边的部署场景，即原来主备库的部署模式，在该模式下，主备库存了两份数据，计算也是两份，所以要布两份的机器资源，然后主库、备库之间的网络带宽是一份，所有的事务写入要存一份数据，此时如果发生故障，会导致数据丢失，即 RPO＞0。

OceanBase 通过三节点的高可用能力提升了该部署场景下的容灾能力，OceanBase 以前的版本称其为日志型副本，通过在三个节点之间做多数派的投票，相比之前的主备最大的好处是当少数派发生故障的时候，数据不会丢失。这里的“丢失”不是大家以为的，这个事务还没有提交，丢掉就丢掉，而是告诉已经应用成功写进去的数据还是会丢，即在主备模式下还是会丢。OceanBase 在原来的版本里面有一个独创的设计，虽然日志存了三份，但是数据只需要存两份，就是中间的这个模式。

但是这个模式还有一个问题，大家仔细看，数据本身在网络的带宽上还是要占两份，网络带宽是有限的场景，带宽大了可能就会影响稳定性。

基于这样的问题我们引入了一个仲裁的服务，仲裁服务大家可以看作它还是图中绿色的日志副本的升级版，当事务提交的时候，OceanBase 不会把事务日志写到仲裁服务上，这意味着数据不会同步至仲裁副本。但 Paxos 的日志会同步到仲裁副本，仲裁服务会参与 Paxos 的分布式选举，这样可以在确保 RPO = 0 的数据强一致性前提下，通过仲裁副本实现更低的高可用成本，即在主和从之间只有一份带宽，这件事并不仅是经济的问题，而是影响稳定性。

• 仲裁服务：降低跨城带宽提升两地三中心稳定性

与此同时，仲裁服务还能通过降低跨城带宽提升两地三中心的稳定性。

将主备模式和仲裁模式进行比较：上图最左边就是传统两地三中心的部署，在这种部署场景下，当主城市发生故障的时候，备城市的备数据库被启用之后它会丢数据，且丢多少数据是未知的，这是一个痛点。

当 OceanBase 引入两地三中心五副本解决方案后，主 IDC 宕机时，备 IDC 会自动启用，且之后不需要再订正数据，也不会丢数据；但是当主 IDC 宕机的时候，剩下的三个副本加上异地副本，它会变成一个多数派，这时候虽然可以保证业务的连续性，但是会引起降级，因为此时每一笔数据的写入都需要走到备城市，这个问题也会影响稳定性。

而当我们引入仲裁服务后，OceanBase 会把异地的副本变成仲裁的节点，基于这样的设计，当主城市的 IDC 宕机以后，第二个 IDC 会在仲裁副本的参与下，将整个数据库副本数由五副本降成三副本，从而达到快速恢复并且性能不下降的效果。

（一）丰富的可管理手段，保证核心系统业务持续可用

除了上面谈到的几个特性，下面我们来谈谈对于 DBA 很关心的点——OceanBase 作为数据库产品提供了哪些可管理的手段，助力客户真正去解决实践中遇到的问题。

第一，计划运维操作。比如扩容缩容、滚动升级，一个机器有故障，OceanBase可以利用运维管理工具 OCP 一键替换，这类运维能力 OceanBase 很早就已经具备。

第二，故障自动处理。在 OceanBase 做分布式数据库之前，DBA 经常需要在晚上临时进行故障处理，比如主备库宕机以后，DBA 需要连夜进行处理，甚至要求在 10 分钟之内就得进行处理。在 OceanBase 有自动容灾处理功能以后，绝大多数故障场景下解放了 DBA，另外一些少数派的宕机，系统在 8 秒钟之内就可以自动恢复，不需要 DBA 做任何的介入。由此可见，分布式技术的引入大大提升了分布式的容灾处理能力。

相对于分库分表+分布式事务能力的数据库，OceanBase 原生分布式数据库有什么不同？举个例子：众所周知两阶段提交有个问题，当协调者故障的时候，分布式事务会被夯住，无法向前继续推进，这是协议层面定义的动作。但是 OceanBase 从一开始就解决了这个问题，因为 OceanBase 的参与者是高可用的，也就是说参与者不会丢掉自己的状态，因为 OceanBase 有三副本，所以在两阶段提交时少了一个阶段，OceanBase 利用这个特性提升了性能，并且解决了两阶段提交会产生悬挂事务的问题，这也使得在系统内部，DBA 要解决的异常较原来变少。

第三，应急处理。OceanBase 内置了很多应急处理操作。这个操作需要从数据库内核的角度进行人工发起，比如切主、SQL 限流，你可以限制单条 SQL 的 QPS 不超过多少，这些能力都是内核提供的。基于这些能力还是依赖于 DBA 的经验，什么时候做应急以及应急时的判断能力，由此 OceanBase 推出了一个新的产品工具——数据库自治服务 OAS，我们把过去在众多核心系统升级过程中的经验沉淀到了这个新产品里。

（二）数据库自治服务 OAS，为核心系统稳定性保驾护航

OAS 是 OceanBase 数据库提供的自治服务，其依赖于对数据的采集和分析以及对专家能力的沉淀。通过众多客户的核心系统场景打磨，OceanBase 将 DBA、客户在各种场景下面遇到的问题整理成文档，再沉淀到产品里。目前 OceanBase 产品有两个形态：

其一， 如果有些客户在使用运维管理工具 OCP 最新版，最新版本里面有一个诊断中心，可以看到对应资源管理、监控告警、备份恢复、会话诊断等功能已经进行了更新；其二，对于使用 OCP 老版本的客户，也无需因为想使用新特性去升级版本，OceanBase 针对这批用户提供了独立的产品包来体验这些特性。

在内部，OCP 会去监测一些异常的事件和规则，当发现异常事件和规则时，就会触发刚才说到的运维应急动作，并去做一些自愈的操作。与此同时，OceanBase在容量规划、实时的 SQL 诊断等方面也沉淀了很多新功能。

最后，“热爱可抵岁月漫长”是我们创始人阳老师非常喜欢的一句座右铭，我自己对这句话也非常有感触。13 年来，我们从一个非常小的内部项目做起，我们怀揣着非常朴素的理念，希望用技术让海量数据的管理和使用更简单。在上千家客户的帮助和支持下，OceanBase 从 1.x 到 4.x，从原生分布式到单机分布式一体化持续演进。未来，我们希望和更多的客户一起为关键业务负载打造真正实用、好用的产品，为核心系统升级打造坚实的数据库底座。

给大家分享一个小故事，OceanBase 在做 1.0 分布式版本的阶段，即使当时有很多业务在进行中，但在创始人阳老师的坚持下，我们整个项目团队仍然选择了停下来，花了一个多月时间把所有的代码重构了一遍，就是为了去检查所有 C++ 代码的返回值。现在 OceanBase 的代码是开源的，大家可以看一下 OceanBase 代码，如果您看到我们的代码里某一个返回值没有检查，都可以给我们提 BUG。这是 OceanBase 想走得更远、走得更长的责任，也是对客户的责任。谢谢大家！