OceanBase社区版4.x核心技术解密

数字化时代，各行各业的数据量呈现爆发式增长，对于海量数据价值的挖掘和应用，正成为推动创新的主要力量，与此同时，数据计算复杂度正在提升。在此背景下，对于数据处理的基石数据库而言，正面临市场变局。集中式数据库、分库分表等传统解决方案难以面对海量数据带来的挑战，性能瓶颈、分析能力不足、成本高昂等问题逐渐凸显。分布式数据库凭借数据自动分布在多个节点，连接任何一个节点均可以对集群数据进行读写的天然优势及事务强一致等特性，将成为新一代数据管理解决方案。

本文根据 GIAC 全球互联网架构大会数据库论坛《OceanBase 社区版 4.x 核心技术解密》整理，分享嘉宾为 OceanBase 技术部技术专家郑晓锋，现负责 OceanBase 华南区技术开源布道工作。本次分享以原生分布式数据库 OceanBase 为例，从架构及技术特性到社区版及生态工具，再到版本规划及未来展望，与大家探讨数据管理解决方案。

提到分布式数据库，大家自然会想到规模化场景应用。OceanBase 也是在这样的场景下诞生的：2010 年，淘宝收藏夹业务量庞大到传统关系型数据库难以支撑，进而开始做分布式存储方案， OceanBase 0.1 版本就此诞生，大家可以理解为就是一个分布式存储的架构。当时 NoSQL 比较火，很多人因此觉得数据库是不是应该把存储层做分离，我们做了之后，发现存在一些问题，比如在 TP 场景下对时延有要求的话，关系数据库用松耦合的设计在效率上有很大的开销。

为了解决这个问题，当迭代到 OceanBase 1.0 版本的时候，我们就改造成目前的一体化架构。从 1.0 到 2.0、3.0 包括现在 4.0 版本，其实都遵循了这个架构。OceanBase 整体架构很简单，只有一个 OBServer 节点，存储引擎、SQL 引擎、事务引擎都集成在里面。在 OceanBase 有更多的外部用户之后，我们发现用户使用的数据库通常不止一种，比如用户在使用 MySQL 的同时也在使用 Oracle 数据库。所以在 2.0 的版本，商业化时在多租户基础上，增加了 Oracle 兼容能力。在 3.0 版本里，我们进一步增强了兼容性和产品性能。

2021 年 6 月，OceanBase 开源了 3.1 版本，而企业版最新是 3.2 版本，所以在 3.x 版本下，如果去对比社区版和企业版，性能会有差别。到了 4.0 版本，我们现在称之为单机分布式一体化架构，社区版 MySQL 模式的内核能力跟企业版是完全一样的。

为什么我们称 4.x 的版本为单机分布式一体化架构呢？有两层含义：第一层含义是指单机分布式一体化架构既能做单机部署，又能做分布式部署；第二层含义是指在 OceanBase 集群里，即使部署分布式集群，如果租户只用了单机的资源，我们也认为该租户是单机形态。在这个过程中，单机和分布式的形态可以随意转化。

OceanBase 的灵活部署，除了单机形态与分布式形态外，还支持主备库部署。在 4.1 版本里面，OceanBase 主备库是基于 OSS 或者 NFS 归档日志传输做同步，类似 MySQL 主备库。相较于分布式数据库来说，主备库的形态还是会有 RPO≠0 的数据丢失，三副本部署可以更好地满足用户高可用和高扩展的需求。在更大规模的业务场景下，OceanBase 多租户能力帮助集群管理更轻松。举个例子，一个公司如果有上万台服务器，而 DBA 可能只有十几个，一个人如何管理上千个数据库实例，规模化运维场景下人力终有限。OceanBase 通过集群的多租户能力，可以将很多 MySQL 实例，集成到 OceanBase 集群里面，大大降低管理实例的数量。

在整个过程当中，我们看到 OceanBase 部署形态，都是适应企业业务发展的，不用为不需要的特性买单。

OceanBase 自研一体化架构兼容经典模式，实现了单机和分布式，TP 和 AP 的融合。得益于单机分布式一体化架构与原生分布式的特性，OceanBase 兼容经典模式，实现了 TP 和 AP 的融合，并通过全量数据校验真正实现了数据强一致、数据不丢失，高可用，平滑扩展无感知。

从架构层面来讲，OceanBase 使用普通服务器和数据中心网络组成的 Shared-Nothing 集群部署，无需基于专用网络环境的 SAN 存储设备。集群原生自动管理计算资源和存储资源的分配和动态资源均衡。支持弹性水平或垂直扩缩容，读写性能可线性扩展。所有服务节点都支持 SQL 计算和数据存储，每个节点自主管理所服务的分区数据。整个集群只有一种数据库服务进程，无外部服务依赖，运维管理简单。对外提供统一的数据库服务，支持 ACID 事务和全局索引，对应用开发来说与单机无异。OceanBase 可以灵活的基于用户基础设施，支持同城三中心、两地三中心、三地五中心等多种架构。

从特性层面而言，下面分别从原生分布式、扩缩容、单机性能、HTAP、低成本、多租户介绍技术原理。

原生分布式。众所周知，分布式数据库最基本的能力包括高扩展性、高可用性。对于高扩展性，OceanBase 分布式协议采用 Paxos，利用 OceanBase 集群原生的能力可以很方便地做横向、纵向扩容，提升资源利用率，节省成本；高可用方面，除了我们常说的多副本强一致，OceanBase 集群内部还会做数据副本之间的一致性校验、事务提交的一致性校验、数据落盘的校验等来保证数据的高可靠。
扩缩容无感知。在增加 OBServer 机器后，集群会自动把旧节点的数据自动迁移到新的 OBServer 中，整个过程对应用是透明的。在蚂蚁内部，最大的归档库已经达到 PB 级别，利用多机拷贝，500M/S 的速度去迁移 TB 级别的节点只需几个小时。或许大家对此没什么感觉，那么以双十一为例，历年双十一，蚂蚁都会提前半个月在云上申请一批新的服务器，把不同用户的数据打散到更多可用区的机房里，承担双十一流量高峰。迁移过程中，先拷贝只读副本，最后再做 leader 秒级切换，等双十一高峰过后再回收资源，这就是 OceanBase 极致弹性的扩缩容能力。
单机性能相当于单机数据库。一般来说，分布式数据库在保证水平扩展能力时，往往会牺牲单机性能。然而，在 OLTP 业务中，单个事务的处理时延增加往往是不可接受的。这导致在许多场景下，单机数据库替换为某些分布式数据库后，即使业务性能指标不增加，也需要许多台分布式数据库节点才能支撑原有业务规模，导致成本不降反升。

OceanBase 的单机分布式一体化架构，在单机部署时，性能与单机数据库相当，甚至比某些流行的开源单机数据库的性能更好。

当三机三副本部署时，相同的性能同时提供比传统主备库更好的高可用能力。
当节点机器规格提升时，提供了线性的垂直扩展性。
当每个 Zone 部署多节点时，提供了线性的水平扩展性。

特别在以下三种情况，OceanBase 的查询和事务处理没有多机访问的开销：

当 SQL 语句只涉及单机内的分区时，数据读写无需通过网络。
当事务只涉及单机内的分区时，事务提交没有分布式提交协议的开销。
当事务只涉及单机内的分区时，基于多版本并发控制的一致性快照读取无需远程访问全局时间戳服务。

单机分布式一体化架构，让 OceanBase 数据库能够适应从个人小站点到银行核心系统和巨型电商网站等各种规模的业务，用一个数据库产品伴随客户业务的成长。

具体而言，在分布式数据库 OLTP 应用场景下，单机读写能占到 80%，跨机读写约占到 20%。我们做单机分布式一体化的目标是把原来 80% 单机事务的性能支撑好，再针对另外 20% 跨机事务做性能优化。OceanBase 3.x 版本会对数据做预分区，每个分区一个日志流，日志流个数越多，消耗的 CPU 和内存也会更多。在分布式场景下，事务的原子性、持久性会靠多条日志流来共同保障，比如分布式事务的两阶段提交、Paxos 一致性协议等，系统开销相对单机的单条日志流会增多。

而在 OceanBase 4.x 版本，我们把多条日志流合并为一条日志流，极大降低了系统负载。虽然我们做了日志流的合并，但扩缩容的时候，集群会自动把数据迁移到另一个日志流里面，做数据的负载均衡，整个迁移动作都由底层自动完成，对应用透明。

除了我刚刚提到的合并日志流以外，也有一些其他方式来优化 OceanBase 的单机性能，比如说减少系统租户的开销，提供单机内并行的能力，内存中按需来加载元数据等等。我们对比了 OceanBase 和 MySQL 的单机性能，可以看到在 32C 的规格下，OceanBase 表现明显优于 MySQL。

另一个测试体现 OceanBase 良好的垂直扩展性，可以看到在 CPU 资源翻倍的情况下，OceanBase 单机性能 Sysbench 压测的 QPS 基本上也是成倍增长的，能充分利用上添加的硬件资源。

HTAP，TP 与 AP 融合。企业级应用的业务场景通常可以分为两个类别：联机交易和实时分析，我们通常称为 OLTP 和 OLAP 的业务应用。大型企业往往会选择多款数据库产品分别支持 OLTP 和 OLAP 类的应用场景。这种组合式的解决方案需要数据在不同系统间进行流转，数据同步过程带来时间延迟和数据不一致的风险，多个不同的系统产生冗余数据，推高成本开销，往往会限制企业在激烈的市场竞争中快速调整业务。

针对轻量级实时分析的场景，我们希望 OceanBase 能同时支撑 TP 和 AP 业务需求。OceanBase 集群通常有三个副本，默认读写强一致性在主副本中操作，TP、AP 的需求实际上都在一份数据里完成。另外，在单机分布式一体化架构下，用户也可以做些灵活的设置以应对实际业务场景，比如读写分离配置。有个用户的实际案例，从 MySQL 分库分表的方案迁移到 OceanBase 集群，在 TCO（数据库总拥有成本）降低 35% 的情况下，AP 能力反而提升了 30%，这足以证明目前 OceanBase HTAP 的能力还是可以的。

低成本，高压缩率。数据压缩是降低海量数据存储空间占用的关键手段。OceanBase 高压缩比的分布式存储引擎，摒弃了传统数据库的定长数据块存储，采用基于 LSM-Tree 的存储架构和自适应压缩技术，创造性地解决了传统数据库无法平衡“性能”和“压缩比”的难题，并基于数据日志分离方法的分布式存储技术，进一步降低存储成本，实现了高性能和低存储成本。基于 LSM-Tree 的存储引擎，利用编码压缩极大降低存储成本。

OceanBase 如何做到低成本？从节省机器资源与存储资源开始。基于以往的用户实践经验来看，在规模化场景下，比如从 MySQL 迁移到 OceanBase 中，同等规格的机器数据能减少；另外，基于 OceanBase 的存储引擎架构，底层使用行列混存方式组织数据，从 MySQL 迁移到 OceanBase 4.x 版本单副本的存储数据量对比一般在 1 : 5，当然，根据实际用户数据的特征，这个存储的比例会有所增减。

多租户，资源隔离。数据库池化管理是云时代实现资源精细化管理的重要手段。OceanBase天然是多租户架构，在一个集群中同时运行多个数据库租户，每个租户可以视为一个独立的数据库服务，租户间数据和资源互相隔离，并且在集群内统一调度。支持在创建租户时选择不同的兼容模式，每个租户可单独配置数据副本数量、副本类型、存储位置及计算资源等。数据库集群整合平台化，多租户整合应用数据库，可在线扩展，在线调整配置，更好地帮助业务实现运维工作自动化。

两个月前，我们发布了OceanBase 4.1 的版本，这个版本提供了很多新的能力。

第一个是功能性的需求，新增旁路导入功能，提升我们大数据批量的导入速度；开放了 OBKV，多模数据类型，如 GIS，以及 MySQL 8.0 兼容的强化。
第二个是稳定性，主要是主备库的功能。4.1 的主备库是基于 OSS、NFS 来做的，未来我们也会做基于网络传输的主备库模式。
第三个是易用性，4.1 我们集成了白屏化安装的工具，可以去部署轻量级的 OCP express，包括一键安装 OceanBase 集群。
第四个是性能提升，4.1 版本相对于 4.0 版本，TP 性能在4C场景下提升 40%，AP 性能提升 15%。

此外，OceanBase 会与更多生态上下游伙伴合作，为用户从数据库替换前、迁移中和使用后的不同阶段提供全方位产品化提供便捷服务。在 OceanBase 社区生态工具中，大家使用最多的主要是 ODC（开发者工具）、OMS（数据迁移工具）、OCP（运维管理工具）。我们还做了轻量级的社区版 OCP express，在今年年初已经开源，开放了 API 接口。部署服务后，可以通过开放的 API 接口对接已经在使用的数据管理平台，提高运维效率，助力业务稳定增长。

OceanBase 社区版开源以后，4.x 版本 MySQL 模式社区版跟企业版能力完全拉齐。虽然 4.x 版本相对于 3.x 版本性能提升非常明显，但是在内核方面我们还是希望持续去优化。TP 场景下，我们会继续向小规格发力，希望给用户的体感就是，用单机的 OceanBase 实例比 MySQL 单机明显跑得更快，希望 OceanBase 能够为用户从小规格到大集群保驾护航。AP 的场景下，我们也会持续去补足功能性的需求，比如冷热分离、只读外表的能力，适应用户更多业务场景。

希望 OceanBase 数据库能够助力更多企业突破业务瓶颈，也希望越来越多的用户可以参与到OceanBase 社区共建中来，与 OceanBase 一起成长。