近日，2023 inclusion·外滩大会在上海黄浦世博园区举办。由赛迪顾问与 OceanBase 联合主办的外滩大会“分布式数据库助力数实融合”见解论坛圆满落幕。

会上，OceanBase CEO 杨冰发表了《分布式数据库助力企业数实融合，跨越数字化转型深水区》的主题演讲。向大家介绍了数字化时代，分布式数据库在助力企业数实融合方面的优势以及 OceanBase 的一些典型实践。

以下为演讲实录：

非常欢迎各位来到 2023 inclusion·外滩大会“分布式数据库助力数实融合”见解论坛。相比三年前，OceanBase 只有 18 家客户，到现在已经突破 1000 家，这期间发生了非常巨大的变化，而这样数量级的变化意味着我们会遇到更多复杂的场景，也意味着在同一个行业、同一个场景中我们会遇到更加深层次的问题。

今天，我的分享主要围绕《分布式数据库助力企业数实融合，跨越数字化转型深水区》。这里先给大家分享一组公开数据，我国数字经济规模，从 2005 年只有 2.6 万亿元，到 2022 年上升到 50.2 万亿，预计到 2025 年将上升至 60 万亿，占 GDP 比例将超过 50%。高速增长背后产生的数据，需要用 EB 作为单位来计算，截止 2022 年底我国数据存储量已达 724.5EB，同比增长 21.1%，全球占比 14.4%。

这些数据的背后，意味着什么？在 Oracle 诞生的 40 多年前，或者是 MySQL、PostgreSQL 流行的年代，那时候数据库设计者和使用者脑海中，数据量很 “大”和今天的“大”量数据已经不是一个数量级。

这就意味着，需要新的假设，新的架构来解决新阶段的问题，我们认为随着数字经济的发展，必须要有一套新的数据架构来作支撑。其实在所有的技术领域，大部分的问题都是可以找到解法的，关键看是设定在什么条件下，这样才能以最佳性价比解决问题，我相信今天中国面临的许多技术突破都是有解的，包括近期比较热门的光刻机。

站在技术体系的发展角度，从宏观上看，海量数据的爆发来自于互联网的发展，业务的线上化以及企业信息化和数字化的转型，爆点是先从应用层开始的，很快就触碰到了底层计算网络等基础设施的瓶颈，从而推动云计算和大数据平台的发展，当 IaaS 和 SaaS 都发展起来后，PaaS 层这种中间层的技术开始慢慢收敛、标准化，形成云原生、流/批计算平台、分布式数据库等配套的标准件。然后随着应用层的第二波的AI、WEB3 的革命的到来，又往下开始推动新的 IaaS 的突破，比如算力、带宽、存储，进而形成新的 PaaS。

从微观上看，也是更偏技术架构的角度看。近年来，不论是在互联网平台上的讨论，还是我们在和众多客户交流的过程中，会发现其实都符合一个趋势——架构的演进过程基本都是从最容易的、相对无状态的应用层开始做起。因为瓶颈出现以后，应用层是最容易改造的，面对更多的需求，更多的数据，更快的迭代速度，应用层的解题思路就是从单体应用走向服务化拆分，再慢慢向云原生化演进，由于应用大部分是无状态的，整个演进的风险是相对可控的。

业务和架构的压力很快从应用层传导到了 IaaS 层，涉及到芯片、存储、服务器等，这些最底层 IaaS 虽然是有状态的，存储着关键的数据，但都离业务比较远，跟 PaaS 相比，跟应用间的关系更加弱耦合，基本都是通过标准接口进行交互，而且云和新的存储、芯片和网络层的发展并没有太多改变标准。所以，在数字化转型过程中，这一层基本能够在不影响上层业务的同时，相对“透明无感”升级到云底座，换上自主可控的芯片和服务器，为上层提供更强大的弹性算力和更高资源利用率的虚拟化能力。

当 SaaS 层或者说应用层改变了，IaaS 层也升级了，剩下最难啃的骨头就在 PaaS 了，这一层的基础设施既与业务相关，又是有状态的，往上需要承接应用层分拆后的分布式化的数据通讯和运维管控，往下有云底座后需要适配云原生方向发展。

而 PaaS 层中最难升级就是数据库，无论是与应用的耦合度还是状态数据的重要性，都给架构升级带来了巨大挑战。举个例子，随着互联网的发展，现代应用处理的数据量更大，也会经常面对脉冲业务的冲击，应用架构通过服务化架构和容器技术具备了更大的数据处理能力和弹性伸缩能力，从而间接要求数据库具备海量数据处理能力和弹性伸缩能力，同时业务的分布式和垂直拆分会要求数据库也是分布式的，但分布式有状态数据如何保证一致性，又如何应对大量数据库实例管理的复杂度，这在传统集中式数据库的架构上是极大的挑战。

再比如，海量数据和请求既有分而治之并发处理的场景，又有需要“百川入海”汇聚分析的场景，这个时候如何低成本存储，如何更实时的分析“在线热数据”，对传统数据架构用分而治之的思路应对大数据时代的 OLTP 和 OLAP 的负载的模式而言又是一大颠覆性挑战。

另外，在分布式架构下 PC Server 的可靠性降低但数量变多，这“一降一多”极大的放大故障概率，而现代应用需要提供在线服务，对业务连续的要求只会变得更高，传统数据库依赖特定的高可用硬件来应对可靠性要求的方案已经难以为继。

所有这些新的问题表明，我们已经无法用传统的数据架构和思路来解决这些新问题了。如果还是治标不治本，通过外挂或者各种外部软件和数据库软件拼装组合的方式来应对这些复杂问题，只会让复杂度和风险变得更高。

我们认为现代应用架构和底层 IaaS 架构的变革一定需要数据架构层的根本改变，才能解决深层次的矛盾，才能应对现代业务场景的挑战。要构建现代应用架构的摩天大厦必须彻底重构数据架构的地基。

自关系模型有了完善的理论支撑后，从 Oracle、DB2 到 SQL Server，商业数据库迎来了第一波高速发展。当关系数据足够流行，上下游生态软件和应用软件的适配足够完善，以及在全球有足够广泛的开发者群体时。MySQL、PostgreSQL 等数据库以开源、免费和简化版的形态推动了数据库历史上第二波更加广泛而影响深远的发展，但直到 1996 年后，OLTP 领域再也没有新的主流数据库出现。

这是什么原因呢？因为在使用场景上并没有形成代际跃迁的变化，也就没法对现有数据库的能力和架构产生太大的推动力。直到以中国、美国为代表的区域迎来了第一波 PC 互联网到移动互联网的高速爆发，也就是在这之后，数据库领域慢慢开始有了新的变化，而比较有意思的是，这波移动互联网的变革，中国比美国跑得更快、更彻底，也更快地推动了大量技术的发展甚至是变革。

2000 年左右，基础架构还没有反应过来，从应用层到中间件层开始解决集中式解决不了的问题，以 Cobar，MyCAT 为代表的中间件方案的分布式架构出现。一直到 2010 年左右，以 Google Spanner、 OceanBase 等为代表的原生分布式架构出现，陪伴互联网高速发展的十余年，产品逐渐打磨成熟并开始商业化。

到今天，OceanBase 逐步从企业核心系统走向千行百业，我们发现分布式数据库架构还远没有到头，我们认为分布式和集中式的需求不应该是割裂的，对用户而言应该是无感知的，甚至是不关心的。而在架构上也不是互斥的，是可以融合的。

于是，我们创新性地提出了单机分布式一体化架构，用一套架构提供线性的读写 scale 能力和线性的硬件 cost。单机分布式一体化架构的研究成果论文还在今年入选了国际顶级数据库学术会议 VLDB 2023，业界权威机构都非常认同这是分布式数据库架构的未来。

刚刚我们从技术视角回顾了分布式数据库架构的发展历程。如上图，我们再从 OceanBase 自身发展的视角出发来回答这个问题。

• 第一阶段，OceanBase 更多是用在阿里巴巴及蚂蚁集团内部的互联网场景上，从非金融到金融核心场景，慢慢把数据量很大但 SQL 并不复杂的简单 OLTP 场景完成了分布式改造，而且严格做到了集中数据库的 ACID 特性。

• 第二阶段，在简单的 OLTP 之上增加大量传统的 OLTP，数据量比较小，但 SQL 很复杂，有存储过程，大量复杂的函数和嵌套查询，有很多大事务，长事务，海量分区甚至各种外表的关联读写。同时，传统场景在数据量没有那么大时， OLTP 和 OLAP 的边界没有太明确的区分，所以开始增加简单的 OLAP 能力，提供在线数据上的复杂查询能力。

• 第三阶段，开始承载更多通用场景、通用业务，更多中长尾的应用开始使用  OceanBase。各种场景的打磨下，OceanBase 由此进化到 4.x 版本，也是业内首个单机分布式一体化数据库产品，适用于更广阔的场景。

需要说明的是，并不是说第一个阶段适用于互联网场景，第二个阶段适用于传统场景，第三个阶段适用于通用场景，而是相互叠加的，1.x 版本的能力是基础，2.x 和 3.x 之上再构架了 4.x 版本，层层叠加，能力不断增强，适用边界不断拓宽。

新一代分布式数据库需要哪些关键能力来应对挑战？一是支撑核心系统升级的稳定可靠；二是应对海量数据挑战的弹性，靠纯堆机器的手段一定会遇到上限，解决不了根本问题；三是低成本的极致性能，高性能处理海量数据的同时，也需要是低成本的；四是洞察驱动的融合分析，海量数据下除了要承载交易型应用，还需要实时洞察数据的融合分析能力。

（一）深度强化稳定性和安全性，支持更苛刻条件下的业务连续性和合规性

分布式架构，一方面是通过分布式的多副本来解决扩展性问题，另一方面是通过多副本架构的冗余性来解决稳定性问题，这是分布式架构核心价值的一体两面，也是这个架构最本质的特点。

数据库软件最重要的是稳定性和安全性，我们先从这个方面讲起。OceanBase 一直在引领行业的发展，OceanBase 是最早提出并完整实现 RTO<30s 的数据库，今天我们发现这已经成为行业标准，但有很多场景对业务连续性提出了更高的要求，目前我们在 4.x 版本上实现了 RTO<8s 的更高要求，让故障恢复更加丝滑，业务更加稳定。

对于互联网企业、大型企业和机构而言，网络带宽不是问题。但对于大部分中型和小型企业，如果要在不同城市的机房之间拉一根大带宽的专线，是一件成本比较高的事情。分布式架构为了保证可用性，需要大量机房间网络的同步。为了解决这一问题，适用更多场景，OceanBase 在单机分布式一体化架构当中，大量压缩网络带宽的传输，典型工作负载下日志写入量降低 30%~40%，能很好地适用于更多普通机房带宽的配置。

架构层面，OceanBase 首创“三地五中心”城市级故障自动无损容灾新标准。这是最高标准，回到更加普适的部署架构，比如在金融行业比较常用的“两地三中心”或者“同城双机房”架构，我们也做的更扎实更可靠， OceanBase 可以通过仲裁机制在三中心或者两中心下都实现数据一致的真正双活，在多租户的使用场景下，也让容灾颗粒度更细，新增支持租户级主备库和备份恢复，实现更灵活的容灾部署。同时，也在数据安全合规方面做了大量工作，符合国内和国际的合规要求。

（二）深度完善平滑迁移方案，上下层兼容降低迁移风险，上下游适配融入原有架构

今天大量的数据库升级是存量替换的过程，除了数据库本身稳定可靠，如何保证迁移过程的平稳也极为关键。OceanBase 经过多年商业化打磨，形成向上向下兼容、向上游向下游适配的整套迁移部署方案，在这一年发展中也有了深度的完善。

OceanBase 比较特殊的点是可以用一个引擎支持两个数据库。过去，Oracle 兼容性我们提得比较多，因为 OceanBase 基本覆盖了 Oracle 95% 以上的常见功能，高度兼容 Oracle。但在很多行业，MySQL 也非常流行，OceanBase 在 MySQL 的兼容性也极大提升，基本全兼容 MySQL 5.x 系列，MySQL 8.0 也接近全兼容状态。之前针对 OLTP 的兼容功能基本比较完善了，近一年在升级一些 HTAP 场景的过程中，我们也兼容了 OLAP 场景下常见的复杂数据类型 NCHAR、NVARCHAR 等，还有大量的复杂函数，还有一些半结构化数据类型，像 JSON、GIS、XML、LOB 等。

在完善 OMS 迁移工具的过程中，企业有大量数据需要迁移，所以 OceanBase 扩展了多数据源的支持，比较全面的支持了 MySQL 和 Oracle 的不同版本，以及 IBM 和 HBase 等数据库。在迁移过程中，也会遇到跨云厂商或者跨 IDC 和 Cloud 的混合架构，数据传输往往要走公网，针对这种场景下的网络带宽限制，安全性的要求，甚至还有跨境的数据传输中合规的要求，OMS 提供了压缩、安全加密、数据过滤等丰富的功能。比如，在跨境业务场景下，用户可以通过配置的方式来管理数据出国境时，哪些数据能出去哪些不能。

当分布式数据库被替换到原架构时，除了完成替换外，还要与很多原有上下游体系架构做适配。所以 OceanBase 除了上下兼容，还增加了上下游适配以融入老的架构体系。上游适配是指对原有数据库的对接解析能力，下游适配可能是像数仓、数据湖、离线计算平台等 OLAP 体系的对接能力，目前 OMS 支持很多流行的计算平台，如 MaxCompute、Hologres 和一些主流工具如 Kafka、Datahub 等。下游也可能是订阅日志的应用，OceanBase 也提供 MySQL Binlog Service，使所有消费 MySQL Binlog 的下游都能无缝对接 OceanBase。

正是利用了这套体系，西安银行用了 3 个月时间就完成了互金核心从 Oracle 到 OceanBase 的升级。青海银行的柜面系统，耗时 1 个月即从 DB2 平滑升级至 OceanBase。中国人寿全栈核心系统，仅用 1 年时间即完成整体升级，迁移规模和速度破金融行业纪录，全程无一例回切。

（三）深度创新单机分布式一体化架构，多元化场景

性能一直是 OceanBase 的强项，以前我们更多强调分布式的扩展性，并且用 TPC-C 7.07 亿 tpmC 这样极端的场景，验证了 OceanBase 无限的扩展能力。

以常熟农商为例，新一代核心系统主集群采用“两地三中心五副本”的 OceanBase  部署架构方案，批量代发代扣场景下，性能提升 651 倍,日终批量场景处理能力提升 41 倍，每秒交易处理能力提升 46 倍，同时可通过横向扩展的方式继续增加。案例中也展示了像交行的贷记卡中心、人寿的理赔核心、太平保险的财险核心的性能提升数据，都在升级到 OceanBase 后提到了极大的提升。

当然，在业务逻辑更加复杂的金融场景中会遇到数据量大，事务也比较大的情况，而这对分布式数据库而言是个非常挑战的问题。但经过深度的重构和优化，目前我们完全打破了事务大小的限制，从百兆事务限制到现在可以像扩展性一样完全没有限制，从支持简单业务的大并发大数据量处理，到复杂业务逻辑的大吞吐量处理，在分布式的性能优化上进一步精进、蜕变。

另一方面，自从去年发布了单机一体化架构后，OceanBase 还在不断优化小规模、小场景下性能。过去在单机场景下，为了获得较高的性能，一般推荐大家部署 36~64core 的高配机器，目前不但能在 4core 这种的低配机器上跑，还能在 Sysbench 测试成绩上超越 MySQL 8.0。

（四）深度优化多租户和高压缩，充分利用每一份资源

分布式的强项是解决扩展性问题、容灾稳定性问题，但其冗余的多副本设计，带来最大的副作用就是成本比较高。

今天，OceanBase 的架构已经可以在成本及伸缩性上达到很好的平衡。可以看到我们在交通银行贷记卡核心系统、常熟农商存贷核心系统、中国人寿理赔核心系统、太平洋保险财险核心客服系统等上，均做到了大幅的数据压缩，并且系统性能还比之前更好。尤其在一些数据重复性比较高，容易压缩的场景下效果更加明显，比如国寿理赔核心就从近 500T 压缩到 68T。

随着所覆盖行业的不断拓展，我们的多租户、高级压缩技术开始碰到一些新场景：有些客户希望通过多租户把很多单实例合并到一个大集群。有些客户希望租户的隔离性不要那么强，这样可以实现超卖。有些客户则把它用在各个省份的业务单元或者多法人机构，希望运维上是同一套集群，但在隔离性上希望和物理机、虚拟机做的一样。

为满足客户多样化的需求，OceanBase 在原架构下进一步提升隔离能力，比如在内存、CPU、IOPS 中用 Linux cgroup 技术做到硬隔离的水平，并且在功能层面也把原先不太完善的备份恢复、主备库、连接数、日志、数据盘的隔离性进一步提升，包括 OceanBase 非常经典的压缩轮转合并，也可以做到租户级的隔离，真正把虚拟化的实例演进到与物理隔离的实例一样的能力，应对不同的场景。在年底发布的列存版本中，在压缩能力上也有进一步的提升。
 

（五）深度拓宽交易引擎边界，打造更强劲复杂查询分析能力

最近这些年和客户交流后发现，尤其在传统场景，HTAP 并不是什么新需求，而是非常刚性的需求。无论是在银行的交易跑批、保险的精算，还是通用行业的营销风控场景，当 OLTP 数据落下来后会有非常实时的数据分析和处理场景，在 OLTP 之上提供强劲的复杂查询分析能力是刚需。其实在数据量没这么大的年代，Oracle、DB2、SQL Serever 都有这方面的能力，只是到了更加轻量的开源数据库，这部分能力被极大弱化，或者说是刻意的简化了。另外，在如今真正的大数据量下，基于集中式架构的 HTAP 引擎的适用场景显然遇到了极大的瓶颈，既存不下也算不出来。

我们回归到需求的本质，也向经典企业级数据库学习，在一套引擎里支持 OLAP 和 OLTP 负载，而 OceanBase 最大的创新在于，我们是在解决了一致性问题的“分布式”OLTP 引擎上增加了天然就需要“分布式”的 OLAP 能力。随着 cgroup 技术的使用和隔离颗粒度的细化，目前 OceanBase 可以在 HTAP 场景中提供基于 SQL 粒度的隔离性，让两种工作负载互不干扰。

OLTP 性能层面，TPC-DS 性能提升 3.4 倍、TPC-H 提升 6 倍，这背后并不是我们单独做了 OLAP 引擎，而是真正扎扎实实地在 OLTP 引擎上，从 SQL 层存储层做优化达到的效果。在年底列存版本中，向量引擎升级和列存引擎的结合，OceanBase 的 OLAP 能力将有进一步的提升。

在 OLAP 场景中，还需要解决如何快速地将海量数据导入具有 OLAP 能力的OceanBase 中进行处理？这是除引擎能力之外的又一关键门槛。经过今年的深度优化，OceanBase 的 4.x 版本在导入性能上提升了 6 倍。同时，客户要做轻量化数仓实时分析，除了本库数据外，可能也会涉及到大量外部存储或者数据库的读写，比如 OSS 的读写，老的 Oracle 库的读写或外部数据的集成，我们在外部表、DBLink 等功能方面也有了突破，以满足 OLAP 场景下的深度应用场景。经过这一年 HTAP 场景的深度打磨，OceanBase 引擎的 OLAP 能力得到了极大提升，年底的版本将会是真正“分布式 HTAP 引擎”的起点，我相信这套工程实现在全球也会是非常领先的。

以上我们也简单列举了几个客户的场景。在金融场景方面，西安银行的互联网存款、电子渠道、西银惠付等关键业务系统基于 OceanBase 进行分布式架构升级，批量任务处理时间从 1～2 小时，缩短至 10 余分钟。在通用行业，海底捞核心会员系统、进销存系统是非常典型的 HTAP 场景，原 TP 和 AP 依赖数据同步工具和两套异构数据库来支撑，采用 OBCloud（OceanBase 的云版本）后，用 OceanBase 的一套 HTAP 引擎统一处理两种工作负载，极大简化了业务架构，实时分析算力也提升了 45%。

三年前，OceanBase 只有 18 个客户，三年后，我们在两个层面上发生了深刻的变化：

• 第一个层面，客户数量上，OceanBase 从 18 个变成上千个客户，其中有一半是社区版用户，这里指的是将社区版应用到实际的业务生产系统中去的，简单的开发者下载和 POC 场景下使用不算在里面，另一半则是企业级客户，从使用 OceanBase 的客户的绝对数量上发生了巨大的变化。OceanBase 开源比商业化要晚了一年多，在短短不到两年左右的时间累积了大量用户，有很多是在核心生产系统上使用，这是第一个进入到深水区后从量变到质变的维度。

• 第二个层面，每一个行业，尤其我们进入时间最长的金融行业，全国超过 1/4 的头部金融机构，包括 1/3 城农商行、证券、基金、保险等机构已经选择在核心系统上使用 OceanBase。从仅仅是上一个试点系统到敢于在核心系统上使用，再到 All in OceanBase，这是第二个 OceanBase 在客户使用深度上量变到质变的维度。这也证明 OceanBase 在核心场景的表现得到了大量客户的认可和信任。

以下我也举几个行业的实际落地案例和这些行业中关注的产品特性。

（一）为金融行业不同核心场景提供数字化转型保障

在金融行业，大型机构、小型机构的需求、关注点是不太一样的。大型机构基础设施比较好，在 TPS、响应时间等各方面要求会比较高，所以关注点不仅是分布式，还要有完整的单元化分布式整体解决方案和在分布式架构下如何构建高可用的技术风险体系。OceanBase 结合蚂蚁集团在支付宝、网商银行等十余年实践，已经形成一套完整的分布式解决方案。

其次，大型机构整体升级的系统比较多，迁移的数据量也比较大，有些客户甚至会选择 All in OceanBase，所以非常关注整套迁移方案的安全性和改造的成本，OceanBase 针对 MySQL 和 Oracle 的高度兼容以及完整的迁移工具是大机构最关心的能力之一。

最后，一般大型机构的基础设施也比较多样化和复杂，比如同时跑在不同的芯片和云上面，OceanBase 可以兼容所有国内主流的国产芯片，同时可以多芯片混部，服务器上也是一样，可以在不同的云厂商中部署 OceanBase 服务器，进行跨云协同。这是大机构比较普遍的需求。

而中小型金融机构，首先需要数据库的分布式的能力，但在使用上根本不希望对此有感知，而是希望像集中式数据库一样使用数据库。所以原生的分布式能力尤为重要，这种架构避免了分布式的复杂性侵入应用，避免了分库分表的改造和后期使用和运维上的限制。

其次，中小型金融机构更关注分布式数据库与应用厂商的适配，希望有应用厂商的兜底和大量案例，避免为升级底座而付出不必要的风险。经过这些年的积累，我们已经与神码、长亮、中电金信等核心系统 ISV，以及宇信、天阳、赞同、易成互动等主流银行应用 ISV 完成适配，并且每一个适配都有大量投产案例，涵盖大型银行和中小银行。

再次，中小型金融机构非常关心 OceanBase 的服务和培训，以确保有足够的服务人员可以 Cover 后续的日常服务，目前我们积累了覆盖全国的服务伙伴，并有上百人参与到金融行业的交付运维服务中，我们培训认证体系也迭代了三个版本升级到 3.0，已经有近三万人通过了认证。

最后，中小型金融机构期望在硬件条件比较苛刻甚至受限的情况下，提供成本可控的高可用方案，OceanBase 也提供了对应的方案，这在介绍高可用能力时提到过，这里不再展开。

（二）支撑运营商行业 BOSS/CRM 核心系统整体平稳升级

运营商行业对数据库的使用非常深，而且一般系统之间的耦合度比较高，数据的集中度也比较高，一但涉及到数据库替换往往复杂度和风险要比金融机构还要高。部分运营商的机构应用的分布式改造和数据库基本在同一时期，很多应用在没完全改造好时，还会留有比较复杂的 SQL，比如大量依赖数据库的函数或者存储过程。

所以，运营商客户会更关注数据库的兼容性，以及数据迁移和评估等配套工具完善度和成熟度，以减少迁移时的风险。这正好是 OceanBase 耕耘和沉淀比较完善的地方，刚才也介绍了这几年我们在迁移方案上的进一步的升级。

另外，业务连续性也是运营商极为关注的，除了关心 OceanBase RTO 能力的提升，也非常关心非容灾情况下一些慢 SQL 或者故障的定位能力和运维可视化能力，在这块我们在新版本上也有了长足的进步。

最后是海量数据和复杂业务下的性能和成本平衡问题。例如我们在服务山东移动时，系统按省份按地市做划分。服务江苏移动时几个大地市放在一起，没有按地市做划分，数据量巨大，但 CRM 和 BOSS 做了拆分。服务广州移动时其 CRM 和 BOSS 核心系统和地市都是比较集中的，数据量和复杂度都比较高。几个省份结合自身发展过程中的特点和需求，在集中式架构上，在成本和复杂度上做了不同的平衡选择，分布式数据库如何在这些不同的架构上，让性能能超越 Oracle 或者持平，又在硬件成本、软件成本上低于 Oracle，这是运营商非常关注的问题。

OceanBase 用分布式集群应对大省业务高峰，支持快速扩容，同时利用多租户架构，做好大流量应用和普通管理应用的统筹管理提高资源利用率，高压缩比又能在保证性能不降的同时节省硬件，整体可以节省 30%～50% 的硬件资源。

目前，OceanBase 已经支撑山东移动、浙江移动、江苏移动、福建移动等移动运营商进行核心系统升级，覆盖 B/M/O 域近 20 个核心应用，300 多个实例。从各大运营商应用 OceanBase 的成效来看，我们在这方面都有不错的表现。

（三）支持政务和国计民生领域应对海量数据高频处理，实现信息系统整合升级

在政务行业，大量政务管理系统、大数据局、社保、医保等全国统一的国计民生平台，现在都有统一管理、集中管理的大趋势。但在业务处理和数据存储上又需要有一定的隔离性和分实例管理的能力。而 OceanBase 的多租户体系非常契合这个需求，同时可以用较低的成本存储海量集中数据，用统一高效大集群多租户管理模式，替代上千个独立集中式数据库的运维模式，统一高效。

海量数据处理和线性扩展能力也是国计民生领域所关注的，数据库需要具备灵活扩缩容的能力，支持民生业务高并发需求和突发扩容需求。随着数据成为第五大生产要素，数据的融合流通将在国计民生中发挥巨大作用，OceanBase 支持各地异构政务云底座和跨云混合部署，通过联邦查询和数据复制实现高效数据共享。

以江西省人力资源和社会保障厅为例，作为首个实现与人社部连通的省级大集中的系统，要求部省政策统一、多险合一、风控同策、数据同源、全国基金财务一本帐，对国产数据库的先进性、安全、高可用、高性能、高兼容和高稳定性等方面要求极为苛刻。其核心系统升级至 OceanBase 后，征缴计划生成缩短 107 倍，系统大集中后硬件及存储成本节省 70%。我们还在诸如河南医保、浙江政务一朵云上利用这些技术特点，非常好地满足了这些国计民生场景的需求，这里不一一展开了。

（四）助力千行百业多场景数据整合与降本增效

最后，在更广泛的通用百业中，前面讲过的特性也都是关注的重点，但同样特性不再重复，这里提下最大差异点——多模与 HTAP。过去这些年，泛行业有更多灵活性，应用层更早地走向了云原生和微服务，对实时数仓和 NoSQL 的使用也会比较常见。

在早期，TP 数据库没有很好解决扩展性和一致性还有性能的平衡，所以AP数据库、NoSQL 发展的很快，但当分布式的 OLTP 数据库逐步发展成熟后，很多场景仅仅是需要简单的可扩展的 KV 存储或者是大数据量下的复杂查询，这时就完全没必要通过一套 NoSQL 库、一套 AP 库，再加一套分库分表的TP库，这样一个复杂的组合架构来解决问题。

OceanBase 提供了对 JSON、XML、GIS 等半结构化数据类型的支持，也提供了 HBase 兼容的 KV API 来解决 KV 型数据的存储，基本可以用一套引擎就可以解决大部分场景的问题。类似像理想汽车、海底捞等企业都在 TP、AP 甚至一些 KV 场景中使用 OceanBase 来作为存储解决方案。

最后我简单总结下 OceanBase 这几年的发展。首先在产品上，OceanBase 3.x 的架构是比较适合中大型机构的，其完善的功能和成熟的架构可以很好地支持这些企业的数字化转型和业务的高速发展。

但如今 4.x 架构基本可以从小到大支持企业全生命周期的发展。得益于其一体化的架构，4.x 最大的差异和增强在于，一是可以延伸到更小的场景，二是支持混合负载，以此助力不同规模、不同发展阶段的企业进行数字化转型升级。同时，OceanBase 也在不断地完善向下适配更多的基础设施的能力，以适应更广的应用场景。

在生态方面，我们持续投入，也做了大量工作，现在是商业化第三年，开源的第二年，以下这些数字也代表了我们从 0 到 1 构建生态的点点滴滴，其中我特别想提的是最长期的人才生态的培养，其中 OceanBase 与高校合作的数据库大赛在今年也坚持做到了第三年，去年共有 1180 支队伍参赛，今年第三届大赛已经全新升级为国赛——全国大学生计算机系统能力大赛，我们的坚持也得到了教育部的认可，我相信将会有更多学生参与其中。 

做数据库是非常难的一件事情，完成 0 到 1 的突破最核心是需要场景、需要资金以及足够长的时间，这三者才能构筑核心竞争力，而且是不容易被轻易超越的核心竞争力。过去十年互联网的发展给分布式数据库在技术上的创新和成熟营造了土壤，而近几年国产化升级和数字化转型浪潮创造的核心数据库升级机会，则是为分布式数据库在生态的完善和商业化的突围带来了绝好的发展机遇。我们相信，这些场景是时代赋予我们的发展机遇，也是帮助我们打造竞争核心力的关键要素。

如今在 1 到 N 的发展过程中我们又总结出一套公式：（自研+创新+开放)x长期主义→ 厚积薄发，跨越深水区。自研和创新本质上是在一起的，需要基于第一性原理从根本上解决问题，而不是在已有的架构上拼拼凑凑、修修补补。创新背后的根基是自研，要掌握所有核心代码，知其然知其所以然。要足够开放，持续培育生态。这一切都要持续投入足够长的时间，才能形成厚积薄发之势，跨过深水区，真正穿越周期。

这张胶片的背景中我也列举了几家非常值得敬佩的企业的产品，他们在这几年的技术突破和产品打造上都做出了举世瞩目的成绩，我相信他们走的这条路一定也是一条厚积薄发的技术创新之路。最后，我们相信这个穿越深水区的过程不会孤单，我们期望能与所有的客户、伙伴一起携手同行，破浪向前，一同跨越数字化转型深水区，真正完成核心系统的攻坚。谢谢大家！