机器之心报道
机器之心编辑部
登顶 TPC-C 不是靠数据库数量的堆叠，而是一系列技术的创新。
近年来中国数据库蓬勃发展，各种排行榜单不一而足，云原生、Sharding、混合负载等新名词层出不穷。
但盛景之下，各家数据库的技术实力究竟如何？
日前，OceanBase 研究成果论文《OceanBase: A 707 Million tpmC Distributed Relational Database System》，被数据库国际顶会 VLDB 2022 接收。VLDB 与SIGMOD、ICDE 并称为全球数据库三大学术顶会，收录研究机构以及工业界在数据库领域最前沿、最顶级的研究成果。
论文链接：https://vldb.org/pvldb/vol15/p3385-xu.pdf
论文介绍了 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 可以快速选出另一个副本来替代原先参与者以继续提供服务，并恢复原先参与者的状态，进而可以确定分布式事务的执行，并继续推进二阶段提交协议的完成。
