机器之心报道

机器之心编辑部

登顶 TPC-C 不是靠数据库数量的堆叠，而是一系列技术的创新。

近年来中国数据库蓬勃发展，各种排行榜单不一而足，云原生、Sharding、混合负载等新名词层出不穷。

但盛景之下，各家数据库的技术实力究竟如何？

日前，OceanBase 研究成果论文《OceanBase: A 707 Million tpmC Distributed Relational Database System》，被数据库国际顶会 VLDB 2022 接收。VLDB 与SIGMOD、ICDE 并称为全球数据库三大学术顶会，收录研究机构以及工业界在数据库领域最前沿、最顶级的研究成果。

论文链接：

论文介绍了 OceanBase 的设计目标、设计标准、基础设施和关键组件，以及在 1500 多台服务器（分布于 3 个区域）的分布式集群中通过 TPC-C 基准测试并取得全球最高成绩背后的技术细节。

VLDB 评审专家也对 OceanBase 给予了高度评价：「作为创造 TPC-C 基准测试世界纪录的大规模分布式关系数据库系统，其架构和重要组件在论文中得到了非常全面的概述。OceanBase 设计并实现了一个分布式数据库，并在 OLTP 工作负载上实现了前所未有的性能和可扩展性。」

OceanBase 无疑是中国数据库的代表，而这篇论文则为我们提供了一个深入中国数据库技术的很好的通道。让我们研读论文，看看 OceanBase 为何能创下超过 7.07 亿 tpmC 世界纪录。

OceanBase 的「一体化架构」是什么？

先从 OceanBase 的设计思路讲起，作为一个分布式关系型数据库系统和可扩展的多租户系统，它基于 Share Nothing 架构，具备跨地域容错能力。

下图 1 为 OceanBase 的整体架构概览。从上到下看，应用层发送请求至代理层（OBProxy），经代理服务路由后发送至实际服务数据的数据库节点（OBServer），最后执行结果沿逆向路径返回至应用层。

每个节点都有自己的 SQL 引擎、事务处理引擎和存储引擎，运行在普通 PC 服务器组成的集群之上，各个节点之间完全对等。这些节点分属于若干个可用区（Zone），每个节点属于一个可用区。图示 OceanBase 数据库集群中的数据有三个副本，每个 Zone 存放一份。这三个 Zone 构成一个整体的数据库集群，为用户提供服务。

通过这种方式，OceanBase 用计算机网络将物理上分散的多个数据库单元连接起来，构成了一个在逻辑上统一的单一数据库，其中不同的组件以不同的方式实现了高可用性。

虽然拥有与其他分布式数据库系统（DBMS）相似的目标，如水平可扩展性和容错性等，但鉴于 MySQL 及 Oracle 等数据库的盛行，以及经典关系型数据库经受住了时间考验的关键技术和特性，OceanBase 在设计时考虑到了典型的 RDBMS 兼容性需求，尤其注重业务的迁移成本和用户的学习成本。

由此，OceanBase 数据库在经典关系型数据库的基础之上引入了分布式，实现了高可用和可扩展。研究人员指出 OceanBase 数据库具有以下 6 大特性：

高性能：存储上采用读写分离架构，对计算引擎进行全面的性能优化，实现准内存数据库性能；低成本：使用 PC 服务器，用高存储压缩比降低存储成本，进而有效降低计算成本，并利用多租户部署充分利用系统资源；高可用性：数据多副本存储，少量副本的故障不会影响数据可用性。通过「三地五中心」方式的部署，实现了城市级的故障自动无损容灾；强一致性：Paxos 保证强一致性。默认情况下在主副本中执行读写操作，以确保强一致性；可扩展性：集群节点都是点对点，每个节点具备计算和存储能力，且没有单点瓶颈。支持线性、在线扩缩容；兼容性：除后台协议外，兼容常见的 MySQL 函数和 MySQL 前端，只需零修改或少量修改，事务便可以从 MySQL 迁移到 OceanBase。

实现这些的背后，主要归功于两个核心关键技术——分布式高效存储引擎和分布式事务处理引擎。

高压缩比的分布式存储引擎

OceanBase 具有一个类似于 Google Bigtable 的日志结构合并树（Log-Structured Merge-tree，LSM-tree）存储系统，并基于 LSM-tree 架构形成了自己的存储引擎。该存储引擎设计并实现了非对称读写数据块存储系统以及每日增量主要压缩，其性能接近于内存数据库。

在设计思路上，OceanBase意识到要借鉴经典数据库的优势，例如存储计算分离、一体化设计（即采用同一套引擎实现事务处理 OLTP 和事务分析 OLAP，基于资源组的逻辑隔离），以及采用本地化处理以实现极致性能。

那么，如何在分布式数据库上实现这些特性？

下图 3 为 OceanBase 分布式存储引擎的整体概览。从平衡成本与性能层面看，LSM-tree 架构更适合数据编码和压缩，部分额外 CPU 消耗换来的是存储成本的大幅降低，对 OLTP 服务的性能没有影响。在某些场景中使用编码特性来提高性能，如更高的缓存命中率、更快的查询和更低的 I/O 成本。因此 OceanBase 使用了基于 LSM-tree架构的存储引擎，平衡「性能」和「压缩比」。

OceanBase 还根据用户表（User Table）指定的方式对微块中的数据进行编码和压缩。在用户表中开启编码后，每个微块中的数据将按照列维度（column dimension）在列中进行编码，如此可以帮助用户压缩数据，同时通过提取列中的特征信息加快后续查询速度。经过编码和压缩后，支持进一步使用用户指定的通用压缩算法对微块数据进行无损压缩，以提高数据压缩率，比如支付宝的一个业务系统从 Oracle 迁移到 OceanBase，数据从 100TB 压缩到了 33TB。

针对集中式数据库无法实现存储层横向扩展、存储成本高昂的问题，OceanBase 将用户数据和日志数据分离，比如日志数据基于 Paxos 协议使用三副本（五副本）存储，而用户数据本身可以使用两副本（三副本/四副本）进行存储，在保障相同可用性的前提下，数据日志分离可节省 20%-40% 的用户数据存储成本。

分布式事务处理引擎：Paxos + 2PC

在分布式事务处理引擎设计方面，传统二阶段提交（2PC）协议常被用来实现分布式事务，但在 Share Nothing 架构中，如果一个节点在二阶段事务执行过程中出现故障，则该节点在账户上的操作状态不可访问。此外，该节点可能会很快恢复，也可能长时间无法恢复或永久损坏，无法评估其状态，导致分布式事务的执行结果也无法确定。

针对分布式场景下的故障恢复和并发控制难题，OceanBase 数据库将 Paxos 分布式一致性协议引入 2PC，提出了名为「OceanBase 2PC」的创新性二阶段提交协议，使得分布式事务具备了自动容错能力，首次在金融核心系统做到 RPO=0，也正是凭借这项技术，OceanBase 成为支付宝的最终选择。

下图 5 为 Paxos + 2PC 概览，二阶段提交的每个参与者（participant）都包含了多个副本，并且它们可以通过 Paxos 协议轻松获得。当一个参与者节点出现故障时，Paxos 可以快速选出另一个副本来替代原先参与者以继续提供服务，并恢复原先参与者的状态，进而可以确定分布式事务的执行，并继续推进二阶段提交协议的完成。

为了提升分布式事务处理的性能并降低延迟，OceanBase 选择通过优化参与者和协调者（Coordinator）的操作，进一步改进传统的二阶段提交协议。

下图 6 展示了传统 2PC 与 OceanBase 2PC 的架构比较。与传统的 2PC 相比，OceanBase 2PC 中 Coordinator 不需要持久化状态，而是在故障恢复时由参与者共同协商。基于这种实现方案，prepare 成功即可应答用户，不需要等到第二轮 commit 成功再应答用户，从而将 Paxos 同步的次数从 3 个减少到 2 个，并将事务延迟进一步缩短为仅 1 个 Paxos 同步。当然，这种方案也增加了故障处理的复杂度。

自我刷新，两度创下 TPC-C 性能世界纪录

有了上述积累，OceanBase 团队向国际数据库权威测试 TPC-C 发起了挑战。

TPC 是一系列事务处理和数据库基准测试的规范。其中，TPC-C（Transaction Processing Performance Council）是针对在线事务处理（OLTP）的基准测试模型，使用一个商品销售模型对 OLTP 系统进行测试，可以比较好地观察出数据库服务的稳定性、性能以及容灾等特性。

TPC-C 测试中包含以下五类事务，包括：NewOrder 新订单的生成，Payment 订单付款，OrderStatus 最近订单查询，Delivery 交付配送，StockLevel 库存缺货状态分析。测试开始前，TPC-C Benchmark 会规定被试数据库的初始状态，并使用 tpmC 值（Transactions per Minute）衡量系统最大有效吞吐量（MQTh，Max Qualified Throughput）。

2019 年 10 月，OceanBase 成功通过 TPC-C 测试，并以 6088 万 tpmC 的在线事务处理性能，创下了当时的世界纪录。2020年 6 月，OceanBase 再次参与测试并二度登顶 TPC-C 榜单，以超过 7.07 亿 tpmC 的成绩，刷新了自己之前的纪录。

同样值得关注的，还有 OceanBase 在测试中所展现出的各项服务的稳定性，这个我们稍后看论文。

严苛的 TPC-C 基准测试

就像任何合格的产品在销售前要经过有关部门与行业协会的审批与认准一样，通过国际事务委员会（TPC）的 TPC-C 测试，说明了一个数据库系统通过了国际认证，可以与全世界的数据库产品同台竞技。

OceanBase 论文披露了第二次 TPC-C 基准测试的技术细节。拓扑结构如下图 7 所示，共部署 2360 台阿里云 ECS 服务器，并使用 400 台远程终端模拟器（remote terminal emulator，RTE）来模拟 559,440,000 个用户。同时部署 400 台网络服务器，每个网络服务器接收来自数个 RTE 的请求，通过 OceanBase 的 SQL 引擎将 TPC-C 事务实现为 SQL 存储过程，并通过开放式数据库连接（ODBC）调用数据服务器。

再说 OceanBase 集群，它由 1557 台服务器组成，采用 Share Nothing 架构连接。每台服务器具有 84 个 vCPU（2.5GHz Intel Xeon Platinum 8163 Skylake 超线程处理器），712GB RAM 和 3.5TB*4 SSD。这些服务器平均分成 3 个可用区，每个区域部署 519 台服务器。

作为一个分布式数据库，在 TPC-C 这个原本为集中式数据库而设的基准上取得如此成绩，OceanBase 团队遇到并解决了以下四个挑战。

第一个挑战是基准规范的持久性要求。测试时，OceanBase 数据库系统在商用硬件上运行，选择了具有 3 个区域部署的单个 Region。每个 Paxos 组由 3 个副本组成，即全能型副本、数据型副本和日志型副本。相较于使用 3 个全能型副本，这种配置将 MemTable 使用的 RAM 减少 2/3，将基线数据使用的存储减少 1/3。此外，通过消除数据型副本和日志型副本上重做的 redo log，某些 CPU 周期也得以缩短。

第二个挑战是关于生成基准测试初始数据的耗时过程。考虑到每个仓库（TPC-C 的基本数据单元）的行数（499,000+）、每个 OceanBase 节点的仓库数（共计55,944,000 和 36,000）以及所需数据量，基础测试的初始数据生成任务非常繁重。

为了缩短初始数据生成时间，OceanBase 集群首先配置为 1 个副本，而不是 3 个副本和 no-logging。另外，在初始数据生成期间通过单个事务将数千个行批量插入数据库。所有初始数据插入后，OceanBase 被重新配置为 3 个副本，即全能型副本、数据型副本和日志型副本，然后分区得以自动重新复制和重新平衡。No-logging 也被关闭，并且系统在完成上述重新复制、重新平衡以及主要压缩后准备好进行测试。

第三个挑战是 ITEM 表。由于 ITEM 表在 TPC-C 基准上被事务频繁地访问，因此应该在每个 OceanBase 节点上进行复制，以避免远程访问并保证性能。此外，对于 ITEM 表上的任何事务而言，都必须满足 ACID 属性。因此，ITEM 表被配置为了一个同步复制表。

第四个挑战是根据 TPC-C 基准规范，基准测试测量间隔期间累积性能吞吐量的变化不应超过 2%。对于 OceanBase 而言，它有几个后台操作，比如次要压缩、 混合压缩 （将几个次要压缩合并为一个）以及将次要压缩从全能型副本复制到数据型副本。所有后台操作的 CPU 线性池得到保留以将性能吞吐量变化降至最低。

此外，MemTable 大小的上限应该选得足够小，以便在 RAM 被新事务耗尽之前完成次要压缩。它还必须足够大以利用每个节点 RAM 并产生最少的次要压缩。最后，8 小时基准测试测量间隔期间的性能吞吐量累积变化小于 1%。

详细性能结果

使用上述配置，TPC-C 基准测试分别在 3、9、27、81、243、510 和 1554 台服务器的 OceanBase 集群上运行，测试间隔为 8 小时。结果如下图 8 所示，tpmC 性能分数随着数据节点的增加呈线性上升，具有高度扩展性，在 1554 台服务器上运行时超过 7.07 亿，这一新的世界纪录相较 2019 年 10 月 OceanBase 自己创造的 6088 万 tpmC 提升了近 11 倍。

新订单（New-Order）响应时间如下图 10 所示。图 10(a) 报告了新订单事务类型的最大、90％、平均和最小响应时间曲线图，后三项数值基本重合。最小响应时间为 103 ms，平均和 90％ 响应时间接近，最小与最大差距分别为 5ms 和 33ms。图 10(b) 展示了新订单响应时间分布，其中绝大多数新订单事务在 20ms 内完成。

从新订单的角度，我们可以发现 OceanBase 具有很强的可扩展性。原因在于：1）无状态 OBProxy 的透明转发大大减少了分布式事务，并优化了本地事务；2）OceanBase 2PC 加速了分布式事务处理；3）存储过程加速了事务执行；4）优化的 LSM-tree 减少了事务写入操作；5）非常高效的快速 SQL 参数化有助于 OLTP 短查询场景。

支付（Payment）响应时间如下图 11 所示。图 11(a) 报告支付事务类型的最小、平均、90％ 和最大响应时间曲线图，前三项数值重合。最小平均响应时间为 110ms（3 个节点），最大平均响应时间为 123ms（1554个节点）；最小 90％ 响应时间为 114ms（3个节点），最大 90％响应时间为 154ms（1554个节点）。图 11(b) 展示了具有 1554 个节点的支付响应时间分布。

订单状态（Order-Status）响应时间如下图 12 所示。图 12(a) 报告了订单状态事务类型的最大、90％、平均和最小响应时间曲线图，后三项数值大致重合。最小和最大平均响应时间分别为 107ms 和 117ms，最小和最大 90％ 响应时间分别为 109ms 和 141ms。图 12(b) 展示了具有 1554 个节点的订单状态响应时间分布。

配送（Delivery）响应时间如下图 13 所示。图 13(a) 报告 事务类型的 90％、最大、最小和平均响应时间曲线图，其中 90％ 响应时间大于平均响应时间。对于第 3、9、27、81、243 和 510 个节点，最小和最大平均响应时间分别为 17ms 和 19ms，而最小和最大 90％ 响应时间分别为 22ms 和 27ms。图 13(b) 展示了具有 1554 个节点的交付响应时间分布。

存货水平（Stock-Level）响应时间如下图 14 所示。图 14(a) 报告存货水平事务类型的最大、90％、平均和最小响应时间曲线图，后三项数值基本重合。90％ 的响应时间大于平均响应时间。最小和最大平均响应时间分别为 109ms（3 个节点）和 120ms（1554 个节点），最小和最大 90％ 响应时间分别为 114ms（3 个节点）和 152ms（1554 个节点）。图 14(b) 展示了具有 1554 个节点的存货水平响应时间分布。

中国数据库未来：在不断突破中前行

在短短十余年的发展历程中，OceanBase 经历了多次产品定位和技术创新升级。

这一期间，OceanBase 成为全球唯一在 TPC-C 和 TPC-H 测试（用于评测数据库的分析型查询能力）上都刷新了世界纪录的分布式数据库。

从 OceanBase 的技术理念角度看，首先确保的是稳定可靠。例如，OceanBase 系统内部有一个数据校验机制，自动对多个副本之间进行实时的事务一致性校验和定期的基线数据一致性校验，为了实现该校验功能，会牺牲一些性能，且对存储格式的设计方案有一定约束，但 OceanBase 认为这是必须的，是数据库最基本最朴素的第一原则。

OceanBase 的分区技术使其非常重要的分布式能力之一，能够解决大表的容量问题和高并发访问时的性能问题。分区是指按照用户指定的一定规则，将表分成更小、更易于管理的部分，例如二级分区和基于虚拟列的分区。与分片相比，分区的好处有很多，比如访问 OceanBase 数据库的应用逻辑上只需访问一张表或一个索引、分区对应用程序完全透明且不会影响它们的业务逻辑、访问分区表不需要修改 SQL 语句等。

从分布式 NoSQL 存储系统到分布式 NewSQL 关系数据库系统，OceanBase 还总结了以下实践经验：1）应用层不应使用数据库系统作为键值存储系统，应依赖数据库的高级特性；2）存储过程对于OLTP应用还是有很大价值的；3）对于使用分布式数据库的应用程序，由于分布式系统网络和节点的故障率较高，每个事务和每个 SQL 都应该设置一个超时时间，如果应用程序设置了超时，数据库可能会在许多失败情况下重试以提高健壮性，无限超时时间在复杂情况下可能会导致逻辑死锁，不利于整体容灾。

从 2019 年 10 月首次荣登TPC-C性能榜首，到 2020 年 6 月再破世界纪录，OceanBase 让中国数据库拥有了挑战甚至战胜 Oracle、MySQL 等国外主流数据库的底气。

2021 年 6 月，OceanBase 宣布开源，开放 300 万行核心代码，允许所有社区参与者对代码进行自由修改、使用和引用。OceanBase 社区也同时上线。目前，开发者在开源社区能够完整使用 OceanBase 数据库内核。

当然，作为一个以通用数据库为定位的数据库产品，OceanBase 还有需要完善的地方，接下来也会遇到各种挑战，但在 TPC-C 性能这件事情上，OceanBase 已经不用试图证明什么。

本次通过论文的方式，将 OceanBase 的技术突破及创新向学界和工业界分享，成为 VLDB 2022 分布式数据库领域全球唯一获得可复现认可徽章（Artifact Available Badge）的工业论文，OceanBase 已经为数据库产业提供了有价值的新的思考。我们衷心期待 OceanBase 发展出一个与 MySQL、PostgreSQL 同等规模的一体化数据库产品和社区。