共计 7727 个字符，预计需要花费 20 分钟才能阅读完成。
* 本文转载自微信公众号“机器之心（ID:almosthuman2014），原文《破世界纪录的国产数据库 OceanBase，现在入选了国内顶会 VLDB 2022》”
近年来中国数据库蓬勃发展，各种排行榜单不一而足，云原生、Sharding、混合负载等新名词层出不穷。
但盛景之下，各家数据库的技术实力到底如何？
日前，OceanBase 研究成果论文《OceanBase: A 707 Million tpmC Distributed Relational Database System》，被数据库国内顶会 VLDB 2022 接管。VLDB 与 SIGMOD、ICDE 并称为寰球数据库三大学术顶会，收录钻研机构以及工业界在数据库畛域最前沿、最顶级的研究成果。
论文链接：https://vldb.org/pvldb/vol15/…
论文介绍了 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 等同规模的一体化数据库产品和社区。
