OB君：本文是 “OceanBase 2.0 技术解析系列” 的终篇。在前面的系列文章中，我们从可运维性、分布式架构、数据可用性及兼容性四个方面对OceanBase 2.0的产品新特性及其背后的技术原理进行了系统性的深入解析。
今天的终篇我们来聊聊最重要的OceanBase 2.0在性能优化方面所展开的工作，以及OceanBase是如何实现极致性能的。本文整理自10月27日OceanBase TechTalk北京站活动中颜然的演讲《OceanBase 2.0的性能突破》。

Tips：你可以关注"OceanBase"公众号，回复“1027”一键下载PPT

今天的内容主要分为以下几个部分：首先为大家简单介绍一下OceanBase的架构和存储引擎，以及OceanBase的优化目标和围绕目标所展开的工作，最后还将分享一下我们未来在性能优化方面的规划。

OceanBase介绍

OceanBase是完全自主研发的金融级分布式关系数据库，从架构上可以通过扩展机器来解决集群服务能力的扩展需求。

OceanBase采用多副本复制的方案解决了可靠性和可用性的需求，而且构建在普通PC服务器上，不依赖于高端引擎。

我们的目标是在普通硬件上提供极限性能的数据库服务。那么，OceanBase的存储引擎有什么特点呢？

OceanBase的存储引擎类似于LSM Tree，所有新增的修改都会先记录在Memtable中，这些数据的变更并不会实时写到磁盘上，而会在后台定期写到硬盘上。

不管是磁盘还是SSD，当有大量写入的时候，它的读取性能都会受到很大影响。从一开始OceanBase的架构就是为了适应这种硬件的特性，所以没有随机写的操作，对于SSD和磁盘都很友好，可以将硬盘的吞吐量优势发挥出来，把硬件资源最好的性能压榨出来。

OceanBase从0.x版本到1.x版本，再到现在的2.0版本，一直在推动的一件事就是把硬件的性能做到极致，希望在同样的硬件条件下能给业务带来更多性能的空间。OceanBase的目标一直是有极致性能并且性价比最好的数据库。

OceanBase的性能目标

从用户使用角度来看，数据库有两个重要的指标，延迟（Latency）和吞吐量（Throughput）。这是两个非常不一样的指标。

根据排队论模型，这两者之间的关系如图中所示：随着吞吐量增加，延迟近似指数倍增长。

当整体系统的性能不是特别高的时候，可以保持延迟的稳定性。当系统性能压力很高的情况下，延迟会增加，我们要做的事情就是要在一个合理的延迟情况下，让吞吐量可以尽可能大。换句话说，其实就是把一个请求要做的事情尽可能的减少，然后让单位时间内能做的请求尽可能的多。性能优化的最终目标就是在延迟可以接受的场景下，尽可能提高系统的吞吐量。

性能优化工作

在刚刚过去的2018年天猫双11中，成交额2135亿再次创造了新纪录。那么在蚂蚁金服/支付宝这样的场景下，支付的压力会全部落在OceanBase 2.0版本上。在2.0版本里我们做了一个很重要的事情来进一步压榨硬件的性能——也就是在去年同样机器数量的情况下，来支撑今年的流量洪峰。

在同样的硬件环境，同样的机器规模数这些条件下，通过升级的服务器版本以及服务器的部署方式，来提供今年双11在0:00:00洪峰到来时的抗压能力。 双11的支付压力是典型的OLTP模型，有大量的增删改查操作。OceanBase的存储模型决定了操作主要在内存中进行，所以在满负荷运转下CPU是主要瓶颈。

CPU的资源如何压榨到极致，其实主要包含两方面的工作：

一是优化语句执行消耗指令数（Instructions / SQL），即每个请求需要执行的指令数，指令越少越好；

二是优化系统执行指令的效率（Cycles / Instruction），可以用CPI（Cycles per Instruction）表示。

系统性能由每一行代码决定

任何一段代码都可能导致bug，任何一行代码也都有性能优化的空间。针对不同的场景，我们需要深入到每行代码里去看可以做什么样的优化。

OceanBase 2.0版本进行了深度的优化获得了很好的性能提升。上图所列的只是其中一部分优化工作。性能优化是一个事无巨细的工作，有点类似于测试工作，本质上每一行代码都会影响系统的性能。

优化CPU开销

Commit异步化

在OceanBase已有的模型里，网络模块有单独的线程池负责和客户端通信，接受用户请求和返回请求结果。接收到的请求会发在任务队列中由工作线程处理。

相比较于每一个用户的连接使用一个独立的线程服务的模型，OceanBase的模型可以大大减少上下文切换的次数。

对于SQL语句的执行，这已经是一个很好的模型了。但是对于事务的提交操作，需要将日志在本地持久化和发送到其他副本持久化，提交操作又会使得工作线程出现等待的情况。

Commit异步化是在事务提交日志后不再等待日志持久化，工作线程可以直接去队列中取下一个任务执行。等日志持久化完成后，通过回调的方式出发事务提交完成的操作和给用户发送请求的结果。

优化系统扩展性

扩展性问题

我们做了很多事情让系统少做无谓的事情，多做有用的事情，也就是增加CPU做有效工作的时间占比。

机器的CPU核数越来越多，从原来的几十个核和现在的一百多个核，在英特尔的PC Server上都是很常见的场景。系统在服务器上运行，多核CPU的扩展性是一个很重要的方面。这里以计数器场景举例，单个线程和多个线程一起操作同一个计数器，后者因为多个核之间竞争同一个内存单元，性能会下降几百倍。其实有时候人多不一定力量大，人多也有可能导致大家一起抢赛道。

在系统中也大量存在类似的竞争场景，内存分配器是一个常见场景。多个线程在操作同一个memtable时，会从连续的内存块中分配内存，分配内存的操作就好似计数器的竞争。所以，要把memtable的内存分配操作做成分区的形式，减少多个核之间的竞争。

说到底性能优化其实就是在优化系统的各个细节，每个细节都要做到极致，最终性能才能压榨到最好的那个点，才能把硬件本身的性能发挥到最好。

性能无止尽

我们可以看到，蓝色块代表的是OceanBase 1.4版本，也就是我们现在使用的主力版本，绿色块代表了OceanBase 2.0版本。A场景是下单场景，也就是点提交订单时的操作，B场景是支付场景，就是登到支付宝里去最终付款的场景。

最后结果是：在下单场景下，OceanBase 2.0版本比1.4版本的性能提升了63%，在支付场景下，提升了58%。

未来工作

未来OceanBase会加强面向全栈的优化，同时会对工作负载进行优化，也会有面向新硬件方面的优化工作。

OceanBase会持续进行性能优化的工作，目的是持续为用户提供具有最高极限性能以及最好性价比的产品。这是OceanBase所一直秉承的理念。