迎双 11 十周年，OceanBase 2.0 挑战新巅峰

小蚂蚁说：

2018 年是“双 11”十周年。2009 年 11 月 11 日，当时的淘宝商城（天猫的前身）举办了首届网络促销活动，当天销售额为 0.5 亿元；2017 年的双 11，天猫、淘宝总成交额 1682 亿元，创造了 25.6 万笔/秒的新支付峰值，数据库处理峰值达 4200 万次/秒。2017 双 11 开始后的 7 分 23 秒，支付宝的支付笔数突破 1 亿笔，相当于 5 年前双 11 全天支付总笔数！

对于阿里来说，每年的双 11 就是一个超级工程，而下一年的双 11 又会突破前一年的纪录，因此双 11 其实是一个不停“膨胀”的无限工程。支撑双 11 的核心数据库，就是自 2010 年开始立项的金融级分布式数据库 OceanBase。

OceanBase 的目标是成为新一代商用关系型数据库，其差异化优势在于底层的分布式技术。此前的 OceanBase 1.0 成功支持了 2017 年双 11 的支付峰值，如今 OceanBase 2.0 已正式上线，迎接即将到来的 2018 支付新峰值。

OceanBase 2.0 有何新功能？对 1.0 版本进行了哪些优化？能否支撑今后双 11 的无限扩展？ OceanBase 团队的两位专家杨传辉和韩富晟解读了 2.0 版本的特点，两位专家均强调 OceanBase 2.0 的设计可支撑百万支付峰值甚至无上限，2018 年还将在不增加服务器的基础上“顶住”新的峰值。此外，在完全兼容 MySQL 后，OceanBase 2.0 加强了对 Oracle 数据库的兼容。OceanBase 还在以极致精神打磨软件，挑战世界级基础软件。

进一步提升分布式架构

今年以来，国内云服务商陆续推出了各自的分布式数据库，杨传辉强调 OceanBase 是唯一一个走通用数据库路线的产品，其特色在于分布式架构对用户透明，不需要修改业务。OceanBase 的技术定位为通用的金融级分布式商业数据库，从支持金融行业起步，再逐步拓展到支持各个行业。

蚂蚁金服研究员 杨传辉

相对 1.0 版本而言，OceanBase2.0 在分布式架构方面更上一层楼。OceanBase 1.0 已经实现了用户对机器故障的无感知，也就是多台机器部署数据库，无论哪台机器宕机都可以 30 秒内无损切换，即所谓高可用。OceanBase 2.0 进一步实现了多台机器部署数据库的时候，用户对数据分布的无感知，这就是数据库层面的自动分片和自动负载均衡。OceanBase 2.0 支持在线数据分片，当某个数据分片数据量或者访问量太大时，在线分裂成多个分片，整个过程对服务没有任何影响。

分布式数据库的数据分片，即把数据集切分成若干子集再分布到不同机器上，达到分布均匀、负载均衡、扩缩容时数据迁移少等目的。杨传辉强调，一台服务器上的数据分片数量，说明了数据库底层的技术能力，因为分片越多则意味着系统开销越大，数据分片要能做到足够小，才能实现整个集群负载的精细化控制和快速数据恢复。外界基于 MySQL 方案的分片数能达到单机几十个，而 OceanBase 2.0 则可支持的单机分片数达到 10 万到 100 万个，从而实现了无限的可扩展能力。

在实现用户对机器故障无感知和数据分布无感知后，OceanBase 2.0 还对分布式事务进行了改进。OceanBase 1.0 已经支持了分布式事务，2.0 版本则进一步实现了全局快照和全局索引。所谓全局快照，即当一条 SQL 语句涉及到多台机器时，通过全局快照保证各台机器的强一致读取。在全局快照读的基础上，OceanBase2.0 实现了全局索引，就真正做到了用户对多机环境的无感知。此外，由于出现了全局快照，为了提高局部的租户级数据一致性，OceanBase 2.0 在全局时钟的基础上又引入了租户级时钟，从而保证单个租户的数据一致性，而无须频繁引用全局时钟，这样就避免了全局时钟成为整个系统的瓶颈。

强化对 Oracle 数据库的兼容

除了日益强大的分布式架构，OceanBase 2.0 相比 OceanBase 1.0 在功能上最大的亮点是为用户提供了一个全新的 Oracle 兼容模式。众所周知，MySQL 是互联网场景中最为流行的数据库，但从市场规模、功能完备等方面看，Oracle 依然是商业数据库的绝对领导者。OceanBase 的 Oracle 兼容模式使得传统企业的应用可以平滑迁移到 OceanBase，在不改变业务代码的前提下充分享受分布式数据库在扩展性、可用性和系统成本等各个方面带来的收益。

从 MySQL 到 Oracle 的兼容，不仅仅是 SQL 语法、数据类型、功能等方面的改变，更重要的是从专用数据库到商用数据库的全面功能升级，而这一切都是基于 OceanBase 对于自有内核的全面掌握。 例如，迁移传统数据库应用中，存储过程的支持是绕不过去的一道难题。OceanBase 2.0 在兼容 Oracle 存储过程各种复杂、灵活的语法与功能的同时，还进一步通过编译执行（Just-in-Time Compilation）等技术，大大提升了其执行效率和具体场景中的实用性。与此同时，OceanBase 2.0 还提供自定义函数、窗口函数、层次查询、dblink、临时表、sequence 等一系列丰富的数据库功能。

Oracle 兼容模式的另外一个体现是数据库内核能力方面的增强。例如，为了更好的处理复杂查询的处理能力，OceanBase 2.0 全面升级了分布式查询的优化和执行引擎，增强了对复杂业务的支持能力；为了实现更精确的查询优化，OceanBase 2.0 实现了直方图以及实时统计信息更新的机制；同时， OceanBase2.0 实现了基于用户参数的计划选择机制，增强了系统对大小查询混合场景的支持。诸如此类，OceanBase 2.0 在 SQL 引擎中引入了大大小小数十种内核优化手段，向成熟的商用数据库又迈进了一大步。

数据库应用与数据的平滑迁移是升级过程中的重要考虑因素。OceanBase 2.0 数据迁移平台支持 Oracle 业务到 OceanBase 2.0 的一键平滑迁移，为用户系统的升级铺平了道路。

OceanBase 2.0 刚刚转向 Oracle 兼容，任重而道远。杨传辉表示，相信随着整个团队的不断努力，OceanBase 会持续降低用户使用数据库的门槛，实现对用户生产力的充分解放与赋能。

挑战百万支付新峰值

2017 年双 11 的支付峰值为 25.6 万笔/秒，那么 2018 年及以后的支付峰值目标就上看百万笔/秒甚至更高。这么高的目标能否实现？这就是 OceanBase 2.0 问世的目的：今年双 11 交易支付，全部升级到 OceanBase 2.0，从而挑战百万支付新峰值。

在支撑更高的支付峰值方面，OceanBase 1.0 已经无法对数据进一步的拆分而不影响上层的业务，OceanBase 2.0 的目标就是在用户无感知的前提下可以把数据拆分到无限多的机器里，无需上层的业务改造就可以支撑百万甚至更高的支付峰值。

OceanBase 作为基础软件，是整个支付业务性能的基石。OceanBase 一直以来也把性能作为核心功能对待，一直为业务提供性价比最高的数据库服务。OceanBase 2.0 版本继续发力，在性能上获得了跨越式提升，在线事务处理能力（也就是处理 OLTP 类型业务的能力）提升了 50%，为完成 2018 年双 11 不添加一台服务器支持新的业务峰值的目标提供了坚实的基础。

负责性能优化工作的韩富晟具体介绍了 OceanBase 2.0 的各项改进。OceanBase 2.0 主要从三个层面下了大功夫。第一，是数据库架构层面的革新；第二，是系统实现层面的精雕细琢；第三，是数据库运行环境的整体调优。

蚂蚁金服资深技术专家 韩富晟

OceanBase 2.0 对事务提交流程进行了大重构，大幅度减少事务提交流程的开销。支付业务是典型的在线事务处理类，以短小事务为主，事务的提交执行的频率特别高。事务的提交也通常是数据库内部最耗时的一部分。OceanBase 2.0 打通日志服务与事务服务，将原先分布式事务两阶段提交的多条日志优化到每个分区只有一条日志，依然保证很好的支持事务的原子性和一致性的功能。日志条目数的减少简化了提交流程，不仅提升了系统处理能力，还显著减少了事务提交的耗时。

OceanBase 2.0 还在哪些地方精打细算了呢？实际上，OceanBase 2.0 的整个请求处理路径都进行了细致的优化。以内存分配器为例，OceanBase 数据写入 Memtable 过程中，会在数据存储和索引更新过程多次分配内存，内存分配器很容易成为系统的瓶颈。通常解决这个问题的方法是让分配器预分配很多内存，但是在 OceanBase 分布式多分区的架构下，给大量空闲分区预分配意味着大量闲置的内存无法有效利用。OceanBase 2.0 启用了自适应的内存分配器算法，只对写入量大的分区进行内存的预分配，有效平衡了空间占用和系统性能。

数据库一般都是操作系统压力最大的进程，也经常触碰操作系统的各种极限。OceanBase2.0 在实际生产环境大压力运行时，我们还发现了 Linux 内核的 bug。这个 bug 从 3.1 版本内核开始出现，目前 3.1 也是业界在生产环境普遍使用的一个版本。在内核专家的支持下，我们发现了 Linux 调度系统的缺陷，这个缺陷使得 CPU 无法充分利用。仅解决此 bug 一项，就给系统带来了 7%的性能提升。

为什么 OceanBase 要这么细抠系统性能呢？这是因为做软件有两大代价要应对，一个是开发代价，一个是运行代价，有些系统很侧重开发代价，特别是变化频繁的业务系统，好的开发效率是系统迭代的关键。但是数据库这样的底层系统在关注开发效率的同时，更关注运行代价或者说是运行效率，为什么要关注运行效率？对于一个商业数据库来说，运行在成千上万台机器上，点滴运行效率的提升可以带来计算资源的大量节省，比如 OceanBase 2.0 对于在线处理业务 50%的性能提升，如果原先是 1 万台机器上运行的话，通过性能提升就能节约出三分之一的机器。“越基础的软件性能越关键，一个微小的改变就会为业务节省大量的资源，持续的系统优化是必须要做的事情。”韩富晟表示。

安全、升级与迁移

OceanBase 2.0 还在更多方面进行了优化，这些包括数据安全与质量、软件系统与迁移等方面的优化。

在数据安全方面，OceanBase 2.0 实现了商业数据库一个重要功能，即数据闪回（Flashback）。数据闪回之所以特别有用，在于一旦发现操作有误，可以闪回到一段时间之前的数据状态。OceanBase 2.0 支持数据的多版本存储，即把内存中的数据存储到磁盘时，会把并发的多版本以及历史版本信息等根据用户需求存储到磁盘里。

如何实现 OceanBase 1.0 到 2.0 的平滑过渡？一方面，为了保障业务的平稳过渡，OceanBase 提供了灰度切换和业务双写，灰度切换指的是数据流量按一定百分比逐步切换到新系统中，一旦出现问题即可回滚。而业务双写，即业务系统同时使用 1.0 和 2.0 两个版本，两套数据库并行工作以及进行数据对比，在运行很长一段时间后确保切换没有问题，再一点一点按比例切换，切换的过程中仍然使用灰度控制，这样就保证了从 1.0 到 2.0 的平滑升级。

兼容性也是 OceanBase 团队提供的 1.0 到 2.0 版本升级中的重要保障机制。OceanBase 支持 1.0 版本与 2.0 版本同时运行在一个业务下，“在一个集群里，两个大版本的数据库同时运行，技术难度非常大”，杨传辉强调。首先是不同版本数据库之间的协议兼容，也就是当 1.0 版本给 2.0 版本发 1.0 的协议以及 2.0 版本给 1.0 版本发 2.0 的协议，二者之间都能兼容。此外，在数据格式方面，由于 2.0 版本对底层进行了比较大的改造，因此 2.0 在兼容 1.0 的数据格式方面也做了细致的工作。而更难的是功能兼容，在 2.0 版本中对不少功能都进行了较大的改动，因此每一个被改动功能的兼容性都需要逐一处理。

在迁移工具方面，OceanBase 支持阿里巴巴和蚂蚁金服体系内的数据迁移工具，例如阿里云平台上的数据传输服务 DTS。在蚂蚁金服内部开发了 MySQL 到 OceanBase 一键迁移平台，业务不需要修改一行代码，就可以将原来使用的 MySQL 切换为 OceanBase。

OceanBase 2.0 还在其它方面进行了更多的优化。在底层优化方面，OceanBase 2.0 将实现存储和计算的分离，这相当于在数据库底层形成了一个分布式存储系统。在自治数据库方面，OceanBase 整个的产品愿景一直在朝这个方向发展，尽可能减少人工干预。

OceanBase 2.0 的正式对外发布，代表了 OceanBase 产品化的又一个新里程碑，也是 OceanBase 在走向商业数据库产品之路上的一个重要节点。OceanBase 的持续开发和优化过程，反应了中国基础软件在基于云计算的分布式计算时代的新机遇，尽管要重走一遍传统 IOE 软件曾经走过的基础软件优化道路，但基于云计算的分布式环境给了中国基础软件一个划时代的机遇，抓住这个机遇就有可能成就来自中国的世界级基础软件，OceanBase 也有机会站在世界软件之巅！

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/HcDQm5XKQgG9cMQgI-GRgw