作为一个分布式数据库，在 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 同等规模的一体化数据库产品和社区。
