为什么采用数据编码和压缩可以提升性能呢？
由图可知，编码不影响增删改查，主要有2点依据：
1.数据编码作用对象是列，编码后的数据不需要解码，直接支持查询
2. 同时一个数据块在编码后可以容纳更多的数据，同样磁盘吞吐量的情况下，可以加载更多的数据，OceanBase 的 IO 性能也随之提升了。
所以，OceanBase 数据编码只在集群合并时有开销，对业务增删改性能无损，对部分场景查询性能有提升。
OceanBase 实现了多种数据编码方法，并会自动根据数据特征为每一列选择最合适的数据编码。编码的压缩比受列的数据特征和微块大小影响比较大，一般来说微块长度越大，数据的压缩比会高一些，但相应的一次 IO 读的代价也会越大；微块长度越小，数据的压缩比会越低，但相应的一次 IO 读的代价会更小。微块的默认大小为 16KB，蚂蚁线上 OLTP 使用的也是默认配置，但面对 OLAP 场景，我们可以根据自身业务的测试结果，适当调整一下微块的大小，选择更合适的微块大小。
数据压缩对比数据编码，不光在合并时有开销，在查询被压缩数据前，OceanBase 还需要对数据块进行解压。根据测试，我们从 OceanBase 支持的众多压缩算法里选出了2个能均衡好压缩比和压缩解压速率的算法 lz4 和 zstd，这两个压缩算法是我们线上 OLTP 业务在大范围使用的2种算法。
再来看上图，该图展现了关于这两个压缩算法的性能。这是蚂蚁内部结合业务数据做的一次压测结果，压测数据是一个 2G 的业务表，微块是 16k 情况下，压缩比和压缩解压速率的表现，实际业务上线前，我们也可以多做一些相关的测试，平衡好压缩比和压缩解压速度，根据压测结果选择更适合的压缩算法，这样既能做到高压缩比降低存储成本，又不影响查询性能甚至达到优化查询性能的目的。
二、为高性能 OceanBase 提供的部署环境
很多同学入门数据库是从安装开始。安装数据库软件前，我们有必要检查一下部署环境是否是对数据库友好。硬件配置上，可以参照官方文档对硬件配置上做的推荐。如果想最大化发挥 OceanBase 的性能，我们还可以考虑在硬件上做一些升级。好的硬件可以让 OceanBase 发挥更优的性能。
除了硬件升级以外，我们的部署环境也可以做一些经过测试的调整，以发挥硬件的最大性能。比如说：
在 CPU 访问内存上，CPU 访问本地内存的延迟会小于访问远程内存的延迟，这个是物理层面的限制，而且现在一般厂商推出的服务器都是双核或者多核，那开启 numa 将带来比较可观的性能提升。
有一些企业部署数据库时会因为 numa 的历史 bug 而倾向于选择关闭 numa，但是 numa 的严重 kernel 层低级 bug 已经在2014年提交修复了，新的内核版本也经过验证没有问题。经过内部测试，开启 numaNPS1 模式，将 OceanBase 进程绑核，同时将网卡软中断绑定到和该网卡更亲近的 numa node，测试下来性能约有一倍以上的提升。
存储上一般不需要考虑做 raid，考虑到单盘故障，做 raid5 就可以了，可以不用考虑做 raid1，这是因为 OceanBase 正常最少是三副本部署，相当于数据已经做了冗余了，没有必要在单机再冗余一份，同时 OceanBase 内部拥有比较完善的 checksum 机制，所以如果是因为硬件导致数据写错，OceanBase 都能识别到。
网络上因为 OceanBase 的 clog 同步、rpc 等对网络开销较大。在高并发场景下，网卡的软中断占比还是比较多，如果不将网卡软中断打散，可能会出现网卡软中断集中在第一个 CPU 上的情况，这里建议所有类型的软中断以 round robin 方式全部打散到所有 core 上面，或者把网卡软中断列表绑定到和该网卡更亲近的 numa node cpu 上。其他操作系统层的配置，大家可以关注一下官方文档里列出的需要关注的系统配置项，下表记录的是蚂蚁生产环境使用的标准优化配置。
三、初始化参数调优
OceanBase 有很多参数和配置项，绝大多数跟性能相关的参数都可以在 OceanBase 官方文档中找到最佳实践。我们以蚂蚁实际工作为例，抽取出部分调优后对性能影响体感较明显的参数，来做一下重点关注。
cpu_quota_concurrency 租户的每个 CPU 配额所允许的最大并发数
首先是影响租户 CPU 使用的系统参数，这个参数限制了租户的每个 CPU 配额所允许的最大并发数，比方说设置为4，那 2c 的租户最大允许 8个并发，可以认为调整这个参数就是调整租户级的 CPU 线程超卖，对于本身配置规格比较大的租户，不建议再调大这个参数，建议设置为2，保留一定的租户线程隔离能力，降低租户间的 CPU 抢占而产生的相互影响。
转储系统级参数
什么情况下需要关注转储系统级参数呢？当租户的写入压力较大，转储释放的内存赶不上业务写入消耗的内存时，就可以考虑调整这个参数。比如我们可以通过将转储触发阈值 freeze_trigger_percentage 改小，将转储工作线程数 minor_merge_concurrency 和 L0 转储工作线程数 _mini_merge_concurrency 适当调大。这里要说明一下 OceanBase 的转储分 2 层，memtable 冻结后将数据 dump 到磁盘上，生成 L0 级转储 SSTable，我们称之为 mini merge，多个 L0 级转储 SSTable 在后台又会合并成一个 L0 转储 SSTable,称之为 mini minor merge。当到达触发条件时，多个 L0 转储 SSTable和一个 L1 转储 SSTable 又会合并成一个 L1 级转储 SSTable，称之为 minor merge。
转储租户级参数
_enable_parallel_minor_merge 开启单分区并行转储：
比如说如果一个租户写入量很大，但是这个租户比较极端，只有一个表一个分区，那如果租户转储是单线程的，那就会出现转储释放内存不及时的风险，租户内存可能会被打爆。对于一张用户表，可以通过表级参数 tablet_size 来调整并行合并的粒度，当 SSTable 的大小超过表的 tablet_size 时，就会按照 tablet_size 对数据进行拆分，开启并行合并；但一般来说，并行合并的并行度不会超过配置的合并线程数。
_ob_queuing_fast_freeze_min_countqueuing 表删除达到指定行数时开始触发冻结：
首先介绍一下 queuing/buffer 表概念，这个是 OceanBase 的一个 badcase，当用户在某张表上频繁的执行插入并且同时进行频繁离散删除或更新时，可能会遇到一种现象：表中的数据行数并多，但是范围查询性能出现明显下降。这种现象在 OceanBase 中称为 Queuing 表（业务上有时又称 buffer 表）效应，_ob_queuing_fast_freeze_min_count_queuing 这个参数和 queue 表有关，通过调低这个值触发 queuing 表的频繁冻结转储，实现绕开 queuing 表查询性能下降的问题，其原理是这样的：
OceanBase 做数据删除和更新时，同其他数据库一样也是做的标记删除，在转储时，OceanBase 会将连续删除的数据做一下 purge，对不连续的离散的删除是没有做 purge 的 ，这就导致在做索引范围查询时，可能会有大量的逻辑读，OceanBase 目前引入了 buffer minor merge 设计，可以做到规避 queuing 表的这个问题，可以指定表的 mode为 queuing，然后调整表删除达到指定行数时开始触发冻结的阈值，当触发阈值时，会触发 queue 表转储，即可消除掉增量数据里的所有 Delete 标记。
四、部署优化
从部署的角度我们将分享三个例子，看下蚂蚁如何通过部署提升整体性能。
首先说明下图上带颜色的小方块是不同的副本类型，图中红色小方块代表是全功能主副本；蓝色代表全功能备副本，绿色代表只读副本，黄色代表 log 副本。图中展现了三种部署模式：主主备部署模式、弱读就近访问的部署模式、三地五中心降低事务耗时的部署模式。
主主备部署模式：该模式指的是通过调整租户 primaryzone 将集群里所有租户的压力均衡到各 zone 的一种部署模式。这种模式的特点是使资源充分利用，同时宕机切主的情况下容量也不受损。
弱读就近访问的部署模式：该模式充分利用了业务某些场景的读请求对实性要求不高，容忍一定延迟，通过使用弱读，将全功能备副本和只读副本的资源充分利用起来。弱读的就近访问可以通过 OBproxy 支持。
三地五中心场景如何降低事务耗时：通过降低多数派之间的网络耗时优化三地五中心提交耗时。如图所示，s h 是上海机房，h z 是杭州机房，然后 h y 是河源机房，s z 是深圳机房。假如一个租户在上海有两个全功能副本，同时主也在上海，那可以将第三个副本放在离上海比较近的城市杭州来降低事务提交耗时。这是因为上海跟杭州的网络延迟是五毫秒，而深圳到河源耗时是二十六毫秒。通过在杭州放一个只读副本，事务提交耗时将减少到五毫秒。
同样河源到深圳的耗时是五毫秒，河源到上海的耗时是二十六毫秒。那如果租户的全功能主副本是在河源的话，我们就会就近选择离河源比较近的一个城市，比如说深圳部署一个 log 副本，那这样他事务提交的延迟也同样会降下来。归纳起来，多数派之间的网络耗时降下来之后，整体的事务吞吐量就可以提上来，从而达到性能优化的目的。
五、使用 Partition group 提高事务性能
Partition Group 简称 PG， 是 OceanBase 在 2.2 版本之后开始的一个重要的性能优化。该功能也是2019年淘宝双11所强依赖的功能。使用 Partition Group 可以有效提高事务提交性能，经测试，其性能可以提升 35%以上。
首先，我们先通过建表语句，对 Partition Group 名词做一个解释。Table Group 是一组表的集合，通过定义 Table Group，用户可以控制一组表在物理存储上的临近关系。特别地，对于包含分区表的 Table Group，它由若干个 Partition Group 组成，每一个 Partition Group 包含每个分区表的一个分区。一般情况下，属于同一个 Partition Group 的所有 Partition，系统会通过自动调度使得他们位于同一台 OBserver 服务器上，且这些分区副本的 Leader 也位于一台 OBserver上。
为什么使用 Partition Group 可以提升速度性能呢？其内部原理在于，该功能将单机多分区事务转化成单 PG 的事务，事务提交由原来的一阶段提交优化成单 PG 提交，由写多条日志，变成写一条日志，从而提高事务提交的性能，同时减少网络及磁盘的开销。
总结一下 Partition Group 的使用场景。首先是需要使用分区表，同时业务没有跨 Partition Group 的事务，或强一致性 SQL。
接下来我们做一下 PG 事务跟其他事务类型的对比，加深一下对 PG 的了解。OceanBase 的事务按照类型可以划分成多机分布式事务、单机多分区事务、单机单分区事务以及 PG 事务。这里只对多分区的事务做比较。OceanBase 多机分布式事务采用的是两阶段提交，根据自身特点做出一些优化。相比于传统二阶段提交，它采用了参与者及协调者。然后事务里面第一个分区，它是默认作为协调者。协调者是一个无状态设计，不需要协调者写额外的日志。
多机分布式事务提交过程中，有网络 rpc 开销，以及写多条日志的开销。单机多分区事务仍然是走分布式事务的流程。每一个分区都需要作为参与者，需要写单独的日志。但是 OceanBase 内部对单机多分区事务也做了优化的，将两阶段提交优化成一阶段提交，网络的 rpc 也优化成不走网络的内部调用，单机多分区事务内多个分区的日志做了合并落盘。
我们再看下 PG 事务，PG 内的分区，他们切主这些动作是在一起的，所以 PG 类型的单机多分区事务可以优化成单 PG 提交，单 PG 提交只需要写一条日志，PG 事务的提交性能接近于单机单分区事务。
六、使用 PS 、PL/SQL 优化性能
讲完事务层的优化，我们再来看下客户端和 server之间的通信上可以有哪些优化，首先我们看下 Prepared Statement, PS 市面上很多数据库都是支持这个协议的，通过使用 PS 主要可以带来以下好处：
1.通过 PS 可以避免每次执行均去解析SQL，进而提升SQL的执行效率
2.PS 中 client 与 server 通信采用 binary protocol，普通的 SQL 使用的是文本协议，用二进制协议可以减少网络的开销
3.使用 PS 可以有效的防止 SQL 注入
OceanBase 的 java client 和 OBProxy 对 PS 的支持相对其他数据库做了特殊的优化，我们都知道到 PS PRPARE 是有代价的，相对于传统 MySQL 中的 Prepared Statement，OceanBase 的 Java client & proxy 在 session 级别对 PS 进行缓存，业务代码代码调用 close 逻辑时时，Java client & proxy 只会在 cache 中打标记，并不会向 Server 发送发送 销毁 PS 的请求,这样下次业务在 PS prepare 时，可以复用 cache 中的 PS 缓存，从而达到减少 prepare 代价，提升性能。
然后我们再看下 OceanBase 的 pl/sql，OceanBase 既支持匿名块也支持存储过程，pl/sql 在蚂蚁内部也有着比较多的使用场景，比如蚂蚁交易支付场景，预算扣减场景均使用 PS 、pl/sql 获取极致性能，pl/sql 提升性能主要是通过通过预编译和减少客户端与服务器之间的网络交互来实现的，OceanBase pl/sql 使用上是兼容传统数据库 MySQL/Oracle 的，性能提升的原理是一样的
