OceanBase数据库实践入门——性能测试建议

阿里云云栖号

于 2019-06-19 12:27:41 发布

阅读量5.5k

点赞数

CC 4.0 BY-SA版权

文章标签： Oceanbase 分布式数据库数据库

本文链接：https://blog.youkuaiyun.com/yunqiinsight/article/details/92811208

概述

本文主要分享针对想压测OceanBase时需要了解的一些技术原理。这些建议可以帮助用户对OceanBase做一些调优，再结合测试程序快速找到适合业务的最佳性能。由于OceanBase自身参数很多、部署形态也比较灵活，这里并没有给出具体步骤。

数据库读写特点

压测的本质就是对一个会话的逻辑设计很高的并发。首先需要了解单个会话在数据库内部的读写逻辑。比如说，业务会话1对数据库发起一个DML SQL，第一次修改某笔记录，数据库会怎么做呢？

为了便于理解OB的行为，我们先看看ORACLE是怎么做的。后面有对比才可以加深理解。

ORACLE 读写特点

ORACLE会话第一次修改一行记录，如果该记录所在块(8K大小)不在内存(Buffer Cache)里时会先从磁盘文件里读入到内存里。这个称为一次物理读，为了性能考虑，ORACLE一次会连续读取相邻的多个块。然后就直接在该块上修改，修改之前会先记录REDO和UNDO(包括UNDO的REDO)。然后这个数据块就是脏块(Dirty Block)。假设事务没有提交，其他会话又来读取这个记录，由于隔离级别是读已提交(READ COMMITTED),ORACLE会在内存里克隆当前数据块到新的位置，新块包含了最新的未提交数据。然后ORACLE在新块上逆向应用UNDO链表中的记录，将数据块回滚到读需要的那个版本(SCN)，然后才能读。这个也称为一次一致性读(Consistency Read)，这个新块也称为CR块。

即使是修改一条记录一个字段的几个字节，整个块(8K大小)都会是脏块。随着业务持续写入，大量脏块会消耗数据库内存。所以ORACLE会有多重机制刷脏块到磁盘数据文件上。在事务日志切换的时候也会触发刷脏块操作。如果业务压力测试ORACLE，大量的写导致事务日志切换很频繁，对应的刷脏操作可能相对慢了，就会阻塞日志切换，也就阻塞了业务写入。这就是ORACLE的特点。解决办法就是加大事务日志文件，增加事务日志成员或者用更快的磁盘存放事务日志和数据文件。

ORACLE里一个表就是一个Segment(如果有大对象列还会有独立的Segment，这个先忽略)，Segment由多个不一定连续的extent组成，extent由连续的Block(每个大小默认8K)组成，extent缺点是可能会在后期由于频繁删除和插入产生空间碎片。

OceanBase 读写特点

OceanBase会话第一次修改一行记录，如果该记录所在块(64K大小)不在内存(Block Cache)里时也会先从磁盘文件里读入到内存里。这个称为一次物理读。然后要修改时跟ORACLE做法不同的是，OceanBase会新申请一小块内存用于存放修改的内容，并且链接到前面Block Cache里该行记录所在块的那笔记录下。如果修改多次，每次修改都跟前面修改以链表形式关联。同样在修改之前也要先在内存里记录REDO。每次修改都会记录一个内部版本号，记录的每个版本就是一个增量。其他会话读取的时候会先从Block Cache中该记录最早读入的那个版本(称为基线版本)开始读，然后叠加应用后面的增量版本直到合适的版本(类似ORACLE中SCN概念)。(随着版本演进，这里细节逻辑可能会有变化。)

OB的这个读方式简单说就是从最早的版本读起，逐步应用增量(类似REDO，但跟REDO日志无关)。而ORACLE一致性读是从最新的版本读起，逐步回滚(应用UNDO)。在OB里，没有UNDO。当版本链路很长时，OB的读性能会略下降，所以OB也有个checkpoint线程定时将记录的多个版本合并为少数几个版本。这个合并称为小合并(minor compaction)。此外，OB在内存里针对行记录还有缓存，