OB Cloud：如何为用户提供可持续的降本增效？

易鸿伟

OceanBase资深研发总监

2014年加入蚂蚁集团，深度参与了蚂蚁全站单元化架构、云架构、大促、网商银行的等几乎所有重点架构的升级与建设，主导集团内第四代微服务框架的重构，第五代数据访问层的重构，目前主要负责云数据库相关的产品与技术方向，主要技术关注在分布式数据库、高性能服务器、数据库高可用、云原生技术等。

后疫情时代经济如何复苏？如何应对日益增加的外部压力？对于大部分企业而言，当下的首要诉求一定是生存。借助数字化转型实现降本增效与业务创新，也不应再是形式与表面工夫，而是企业必须认真思考和实践的道路。选择云数据库，正是迈向降本增效和业务创新的关键一步。

OceanBase 认为，云数据库作为数字化的核心基础设施，必须为企业用户提供极致的性价比，真正实现降本增效，才能长期稳定地支撑业务的创新与发展。本文将分享 OB Cloud（OceanBase Cloud）对云数据库实现可持续降本增效的思考，介绍我们在数据库云化架构下的技术创新思路和方案：

OB Cloud（OceanBase Cloud）降本增效的思考；
如何实现可持续的降本增效？

在开始前，我们首先要厘清“降本增效”中的“本”和“效”是什么含义。下文我们主要讨论计算与存储两类成本，降低这两类成本可以立竿见影地看到效果。而提高开发、DBA 等岗位的工作效率，提高企业在数据库开发、管理、运维过程的效率则会因为更为隐性而容易被忽略。OceanBase 认为 “降本”解决生存问题，“增效”解决发展问题，这两者同等重要。

一、降低计算成本：用更少的计算资源，带来更强的性能

▋ 原生分布式：所有计算节点均能提供读写服务，无 Standby 节点

根据部署方式的不同，数据库产品分为集中式和分布式。云上典型的集中式数据库，一般采用主备部署架构。默认两个节点：主节点提供读写服务、备节点默认 Standby。这种情况会造成一半的资源无法提供服务，造成资源利用率不高。如果期望备节点提供服务，一般采用读写分离的方案，需要业务对于一致性级别进行权衡，弱一致性需要业务上能够容忍，强一致性则会导致查询性能下降。集中式数据库如果需要做扩展，主要采用垂直扩容的方式，实例性能上限即物理机的硬件上限，如果需要做水平扩展，只能扩展读的能力，而且读节点也会受限于集群规模，数据库实例的规模一般在个位数量级。

与集中式数据库不同，OceanBase 分布式数据库可以为用户提供多节点多写的能力，业务系统能够充分利用 OceanBase 集群所有节点的计算资源，并随着集群规模增长呈水平线性扩展。在 TPC-C 性能测试中，OceanBase 的集群规模可以达到 1,554 个节点；在蚂蚁集团生产环境中，OceanBase 最大的集群规模超过 500 节点，数据达数 PB，单集群规模也是现有分布式数据库中最大的一个。

▋ 单机分布式一体化：更少的计算资源与更强的计算性能

OceanBase 在 4.0 版本推出前已经有了亮眼的成绩。OceanBase 诞生于 2009 年淘宝收藏夹海量数据场景，并在支付宝高并发交易中不断打磨，稳定支撑“天猫双十一”秒级百万级的订单创建峰值。2019 年，OceanBase 打破 Oracle 长达 9 年的“垄断”，以 6088 万 tpmC 在线事务处理性能登顶 TPC-C 榜首，并在 2020 年以 7.07 亿 tpmC 的结果再次登顶，打破自己的 TPC-C 世界纪录。

2022 年 8 月，OceanBase 在年度发布会上提出单机分布式一体化架构，通过动态日志流实现单台服务器具有固定数量的日志流，降低分布式的 overhead 和性能开销，同时也能支持日志流的动态迁移，实现动态的水平扩展。

单机分布式一体化架构让 OceanBase 引擎实现了两个飞跃：一是更少的计算资源，OceanBase 4.x 能支持更小的部署规格，满足中小规模企业的需求。OceanBase 4.0 最小部署规格为 4C16G，且未来还将进一步降低。二是更强的性能，OceanBase 4.0 单机性能媲美甚至超越传统集中式数据库，同等硬件环境下，OceanBase 社区版 4.0 的 OLTP 性能是 MySQL 企业版 8.0 的 1.9 倍（Sysbench 基准测试结果），OLAP 性能是 Greenplum 6.22.1 的 5 至 6 倍（TPC-H 100GB 基准测试）。

▋ HTAP：一份数据同时支持高性能的 TP 与 AP 混合负载

OceanBase 认为，真正的 HTAP 要求先有高性能的 OLTP，然后在 OLTP 的基础上支持实时分析。上文中我们已经介绍了 OceanBase 高性能 TP 的实现，那我们来介绍下 HTAP 中的 Hybrid（混合）与 AP。

传统的在线 AP 分析架构一般是 TP 负载在集中式数据库或者分布式数据库中，采用 ETL 的方式将数据定期或者实时同步到另外一个异构存储中，按照业务分析的维度进行聚合。这种方式会带来三个问题：成本、延迟、复杂度，需要有一个额外的 AP 计算与存储成本，而在实际生产系统中经常出现数据同步延迟或者同步出错导致的线上故障。基于这三个问题，一种很自然的想法就是基于同一份数据同时做好事务处理和实时分析，减少 AP 数据库的物理成本，降低数据同步带来架构复杂度，从而让应用变得简单。

要解决这个问题，OceanBase 的底层采用了一个基于 LSM-Tree 的行列混合式存储方案，能够在 OLTP 和 OLAP 二者性能取得很好的平衡。

图1 行列混合的存储结构

同时，OceanBase 也支持 OLTP 和 OLAP 的资源隔离，这里面既涉及多个副本之间的物理隔离，也涉及副本内的 CPU、网络、磁盘、内存的逻辑隔离。OceanBase 提供了智能的负载引擎与资源控制引擎，前者能够预判 SQL 的执行 Cost，让 TP 类业务优先处理，后者能让业务灵活进行选择，根据不同维度来对 CPU 等进行隔离，实现更可靠的负载管控。

图2 智能负载引擎与资源控制引擎

OceanBase 3.x 版本中，OceanBase 已经实现了相对完善的优化器引擎、单机执行引擎、并行执行引擎和向量化执行引擎，并在 2021 年 5 月打榜 TPC-H，在数据分析型基准测试榜单的 30000GB 结果一栏，OceanBase 占据性能排行首位，其中代表着数据库核心性能的每小时执行请求数综合指标达到了 1526 万 QphH@30,000GB。

这次打榜充分证明了 OceanBase 的分布式查询能力性能，而且具备线性可扩展。在 OceanBase 4.x 中，我们更是重构了整个分布式查询优化方法，从原先的二阶段变成了一阶段的分布式查询优化方法，并且实现自适应与极致并行下压的执行引擎，TPC-DS 100GB 的 99 个查询执行时间综合从 918s 下降到了 270s。

图3 TPCDS 100GB 不同版本性能对比

▋ 原生内置的多租户机制：提升数据库资源利用率与管理效率

以下是某业务场景下 MySQL 实例的运行状态，多个不同规格的 MySQL 实例，每个 MySQL 实例的 CPU 利用率处于较低水位，存储的磁盘空间也会预留一定的水位。这种情况会存在以下几个问题：

资源无法复用：各实例均是独占资源，资源利用率与资源密度较低；
存储成本高：各实例各自独占固定存储空间，存储无法复用；
抗突发能力弱：突发流量需要快速扩展实例，垂直扩容往往耗时较长；
多实例管控复杂：实例数量增多，运维成本也会提升，如主备库、备份恢复、问题定位等。

图4 传统多 MySQL 实例管理

OceanBase 内置多租户机制，可以将多个 MySQL 实例合并到一个集群中。以蚂蚁集团实践为例，一个典型场景是将有波峰、波谷的业务放入一个集群，比如白天跑业务、晚上跑批和分析，混合部署能够充分利用整个集群的资源和存储空间。主要有以下优势：

资源充分复用：多租户之间可以业务混部、削峰填谷。OceanBase 3.2.x 及之后的版本，CPU 利用 cgroup 进行隔离。不同租户的 Worker 线程放到不同的 Cgroup 目录内。当一个 OBServer 上只有一个租户负载很高，其余租户空闲时，负载高的租户的 CPU 可以超出限制，但内存的使用范围依然会被严格限制；
抗突发流量：租户可以通过超卖机制抢占资源，同时租户内也支持秒级扩展；
存储复用与隔离：租户 SSTable 使用的的 IOPS 及存储空间上限能够被控制，不同租户之间复用同一部分存储空间；
单集群管理：从过去 n 个数据库实例到一个单集群的运维与管理，成本大幅下降。

图5 OceanBase 多租户管理机制

二、降低存储成本：在高性能的前提下，实现更高效的压缩

▋ 自适应数据压缩特性：超高数据压缩机制，节省 70~90% 客户存储成本

我们先回顾下 OceanBase 在单机存储引擎的技术路线。OceanBase 的存储引擎基于 LSM-Tree 存储管理机制，增量数据写内存的 MemTable，之后数据会定期转储与合并，将数据合并到基线 SSTable 中。

图6 OceanBase 单机存储引擎

OceanBase 也利用上述优势实现了一个全新的数据压缩特性，已在蚂蚁及外部客户的业务中经过较长时间实践。该设计包括行列混合存储以及高效的数据编码技术，可以大幅减少业务的存储空间。通过自适应编码压缩技术，OceanBase 可以根据数据内容（按列）自动选择最合适的编码算法，OceanBase 数据库提供了多种按列进行压缩的编码格式，根据实际数据定义进行选择，包括列存数据库中常见的字典编码、游程编码 (Run-Length Encoding)、整形差值编码(Delta Encoding)，以及常量编码、字符串前缀编码、Hex编码、列间等值编码、列间子串编码等。

从客户业务场景的实践效果来看，业务系统迁移过程中，数据压缩能够让存储空间降低到 1/3，也有场景能够直接下降 90% 的存储空间。更为重要的是，在压缩目标实现的同时，OceanBase 的查询性能不会下降，相反，写入（合并）性能反而会有一定程度的提升。

▋ Paxos 多副本机制优化，计算/存储/网络成本均下降 67%

数据库经典的三副本部署结构，需要将数据存在三个副本，每个副本上均有全量的日志文件与数据文件。这类副本结构在 OceanBase 称之为全功能（Full）副本，进一步地，如果一个节点上所有副本均是全功能副本，我们称呼这个节点是一个全功能节点。在大多数场景中，业务均采用三个全功能节点部署的方案。

假设我们以这个三副本结构为基准，计算和存储都需要 100% 的成本。OceanBase 4.0 版本之前提供日志（Log）副本的机制，日志副本仅参与 Paxos 的投票与日志复制的日志，日志副本并不会存基线数据，所有节点上所有副本均是日志副本，称之为日志节点。这个日志节点上只有日志文件、无数据文件，存储成本约下降 33%，同时因为日志节点只需要参与投票与日志复制，对节点的性能要求较低，计算成本下降 20%，这种即是 OceanBase 的 F-F-L（2F1L）结构。

从 OceanBase 4.0 开始，我们将日志节点变成仲裁（Arbitration）节点，仲裁节点仅参与 Paxos 的投票无需日志复制，这样的方式可以让仲裁节点变得非常轻量，无需日志节点与数据文件，存储成本会下降 33%，对性能要求极小所以计算成本也可以下降 33%，也因为无日志复制，能够减少额外的网络带宽成本，同时支持跨城的轻量部署。

图7 Paxos 多副本优化路径

▋ 灵活的云存储介质：提供最合适的云存储介质与云存储成本

OB Cloud（OceanBase Cloud）部署在云上之后首先需要考虑云存储的选择，云厂商给各种不同的业务场景提供丰富的云存储选择，但也存在不少限制。以阿里云为例：本地 SSD 盘、本地 HDD 盘、高效云盘、SSD 云盘、ESSD 云盘（PL0、PL1、PL2、PL3），其中本地盘性能（延迟、IOPS、抖动等）都是数据库的最佳选择，但是其最的缺陷即盘的空间大小和机型规格绑定。以 ecs.i2.2xlarge 为例，只能选择 2 * 1788GiB 的本地盘，ecs.i2.4xlarge 则是 4 * 1788GiB 的本地盘，也受限于机型，仅有部分本地盘机型可以选择本地盘。云盘则有按需使用的优势，但是它存在的问题也比较明显，比如说因为云盘的访问需要走网络，所以延迟比本地盘高，各种网络抖动比较明显，IOPS 也受限于 ECS 的规格。

OB Cloud（OceanBase Cloud）针对云盘做了非常多的优化，主要几点优化如下：

延迟：得益于 OceanBase 的存储引擎设计，OceanBase 写操作主要写到 MemTable 中，读则有多级缓存设计，除了用于缓存 SSTable 数据的 Block Cache（类似于 Oracle 和 MySQL 的 Buffer Cache）之外，还有 Row Cache / Fuse Row Cache（缓存数据行）、Bloom Filter Cache（缓存静态数据的 bloomfilter，加速对空查询的过滤）、Clog Cache、Schema Cache（缓存表的 Schema 信息）等等，使得 P99 场景下的云盘 RT 仅比本地盘增加 5% 以内；
网络抖动：分布式错误探测技术，OBServer 内核快速感知磁盘抖动和 IO 失败，并且将异常信息反馈给 OBProxy，配合一起进行节点的快速切换以减少业务感知；
IOPS：OceanBase 仅在合并阶段需要大量占用磁盘 IOPS，通过 IO 校准机制来精准控制云盘的 IOPS；
磁盘类型选择：云上的云盘选择非常，上面提到阿里云的就有高效云盘、SSD 云盘、ESSD 云盘（PL0、PL1、PL2、PL3），其他云厂商（如 AWS）提供的云盘规格也非常多，OceanBase Cloud 在不会影响性能和稳定性的前提了，提供了最高效以及最经济的云盘类型。

图8 云存储部署结构

经过以上的机制优化后，OceanBase Cloud 也特别针对历史库归档场景进行优化，支持将业务的历史“冷”数据归档到 OceanBase 数据库低成本存储（如 HDD、ESSD PL0 中），后续会支持自动冷热数据分离，可自动将“冷”数据归档到成本更低的对象存储（如阿里云的 OSS、AWS 的 S3 等）中。

三、提升开发与运维效率：更全面的兼容性，降低企业管理成本

▋ 完整兼容 MySQL、Oracle，极低的数据迁移成本

OceanBase 数据库对外提供两种数据库的兼容性选择，分别是 MySQL 兼容与 Oracle 兼容，用户可以在同一个集群内同时运行 MySQL / Oracle 两种不同类型的租户，这样可以进一步降低用户的使用成本，可灵活的提供给不同场景的业务选择。我们认为完整的兼容能力包括三个方面，分别是：

应用兼容：应用只需要很小的改动甚至无需改动，便可迁移至 OceanBase，为企业节约大量的人力和时间成本；
数据库语法兼容：同时兼容 Oracle 和 MySQL 两种语法，并支持过程语言，开发工具等高级能力；
迁移工具：提供可靠的工具平台对迁移全流程进行管理，包括迁移前评估、迁移中验证、迁移后可回退等。

OceanBase 数据库 MySQL 兼容性模式支持 MySQL 5.7 的协议兼容，使用 MySQL 的业务可以以非常小的代价迁移到 OceanBase 数据库来。Oracle 兼容性模式则在数据和功能层实现了绝大多数的兼容，我们支持了绝大多数 Oracle 的原生数据类型，支持了 Oracle 的所有 SQL 功能、语法、PL/SQL、错误码等，同时也支持了完整的 Oracle 驱动兼容，如 JDBC、ODBC、OCI、OCCI、Pro*C 等，开发者可以以极小的成本将业务系统平滑迁移到 OceanBase 数据库上。

除了针对业务系统，我们针对 DBA 在数据库运维管理层，支持大量的 Oracle 原生字典视图、运维命令等，DBA 可以很低的成本来理解新的 OceanBase 数据库，外围工具的兼容性适配难度也大大减少，更重要的是 OceanBase 的核心能力，如性能、稳定性、企业级特性等体验也能够让客户安心的将业务切流到 OceanBase 数据库上。

MySQL 很早即推出了基于 BinLog 的逻辑复制的能力，使得 MySQL 具备了高可用、灾备、读可扩展等能力。多年积累下来，MySQL 生态也基于 BinLog 逻辑复制能力做出了一些比较成熟的增量解析系统并被广泛使用在数据集成中，比如 Canal 和 Debezium，互联网公司通常也有自己内部实现的一些 MySQL BinLog 日志解析系统。

OceanBase 兼容 MySQL 8.0，除了 SQL 层以及 MySQL 通信协议层，OB Cloud（OceanBase Cloud）4.0 给客户也提供了兼容 MySQL BinLog 的能力，能够快速接入 MySQL 成熟生态的 BinLog 增量解析系统，客户将 MySQL 替换为 OceanBase 时，OceanBase 的增量事务日志解析能够直接复用到现有的系统，无需额外改造。目前 BinLog 服务正在内测阶段，欢迎大家申请试用。

▋ 全场景全形态的企业级数据库解决方案，业务数据实现全生命周期管理

数据库作为企业最核心的基础设施，我们从业务数据开发、评估、迁移、运维、诊断等数据全生命周期管理都提供了完整的企业级产品。

图9 OceanBase 平台产品家族图

更平滑的迁移到 OB Cloud（OceanBase Cloud）：数据库迁移主要分为两个阶段：兼容性评估与数据库迁移。兼容性评估方面，OceanBase Cloud 提供了 OMA 数据库迁移评估平台，能够在数据迁移前对业务的 SQL、数据库对象、数据库性能等进行全面的分析预评估，避免迁移后的兼容性以及性能问题。数据库迁移方面，OceanBase Cloud 提供了 OMS 数据库传输平台，提供完整的数据库结构迁移、全量迁移、增量迁移、迁移校验、回流保护等能力。
更安心的运行在 OB Cloud（OceanBase Cloud）：数据库运行过程中的两个主要用户是开发者与运维人员，针对用户，OceanBase Cloud 提供了面向开发者的 ODC 平台，以及面向运维人员的 OCP 平台，可以完整覆盖业务系统从设计、开发到上线运行的全生命周期。
更全面的 OB Cloud（OceanBase Cloud）数据库上下游生态：云数据库不是孤立的系统，OceanBase Cloud 除了提供基于自身特性发展出来的生态产品，也全面适配了数据库的上下游生态，包括且不限于阿里云生态、多云生态、开源生态，也包括通用的数据库工具以及行业的软件支持等。

在上文中，我们通过降低计算成本、降低存储成本、提升研发运维效率三方面全面介绍了 OB Cloud（OceanBase Cloud）降本增效的核心技术。在此基础上，我们如何帮助进一步实现可持续的降本增效呢？

一、基于 Table 模型和 HBase 模型的 NoSQL 能力

OceanBase 作为关系数据库已经实现了一套完整可扩展的分布式 LSM-Tree 存储引擎，具备支持多模型的先天基因，在此基础上扩展支持 NoSQL，OceanBase 帮助用户直接拥有以下久经考验的架构与产品优势：

图10 OceanBase 分布式关系表架构图

首先回顾下 OceanBase 的架构，存储引擎层是 LSM-Tree结构，通过 SQL 层对客户暴露了 MySQL 和 Oracle 两种兼容性能力，能够有效的支持 TP 和 AP。这套底层的架构已经非常的完善，可以提供高可用、扩展性、分布式等能力，我们期望将这套架构能够复制到其他的类型的业务负载。通过将底层的 KV 的能力暴露出来，可以在键值以及宽表的场景分别提供 KV 和 HBase 的产品能力。简单介绍下 HBase 在 OceanBase 中对应的存储结构，HBase 模型在 OceanBase 中的存储结构也是一张四列的表，四列为 KQTV，分别对应了 HBase 的 Rowkey，Family Qulifier、Timestamp 和 Value。

通过 OceanBase 数据库多模的架构，我们可以实现以下特性：