这个方法适用于所有关系数据库(包括分布式的)。

测试方法。

在前文《分布式数据库选型测试(一)——测试需求》里已经就数据库性能对比测试的方法做过总结，这里再补充一些内容。

测试OceanBase集群性能的方法有很多，如sysbench、benchmarksql。不过如果想对比OceanBase数据库跟传统数据库、其他友商分布式数据库产品的性能差异，还需要找到一个能适用彼此的测试方案。sysbench的功能太弱，且只有0.4 支持ORACLE，不同版本的sql还不完全一样。benchmarksql倒是很合适，有一定业务模型，内部复杂但是评测标准简单，容易统一比较。不过如果客户还想测试一点点业务sql，那就只能自己写程序了。如果嫌写程序麻烦，还有个简单的办法就是使用JMeter。

数据库驱动

使用JMeter测试OceanBase性能的时候也需要加载OceanBase的Java驱动。文件可以从官网的下载文件中获取，或者从这个途径：
https://github.com/obpilot/benchmarksql-5.0/blob/master/lib/oracle/oceanbase-client-1.0.9.jar

下载的oceanbase-client-1.0.9.jar需要放到Jmeter的lib文件夹夹中。

业务场景定义

建表语句

请在OB-ORACLE租户下业务账户执行下面SQL 。

$obclient -h127.1 -utpcc@obbmsql#obdemo -P2883 -p123456 -c -A tpcc

CREATE TABLE account(id number NOT NULL PRIMARY KEY
    , name varchar2(50) NOT NULL UNIQUE 
    , value number NOT NULL
    , gmt_create date DEFAULT sysdate NOT NULL 
    , gmt_modified date DEFAULT sysdate NOT NULL  );
    
CREATE SEQUENCE seq_account START WITH 1 INCREMENT BY 1 nocycle;

delimiter /
CREATE OR REPLACE TRIGGER trg_before_ins_account
BEFORE INSERT 
ON account
FOR EACH ROW  
BEGIN 
    select seq_account.nextval INTO :NEW.id FROM DUAL ;
END;
/
delimiter ; 

示例中的触发器和序列不是必须的。这只是一种常用的用法。ORACLE租户的序列能保证值递增(序列属性是NOCYCLE),但不一定保证连续(事务回滚时会浪费序列值)。这里的测试案例期望产生的测试数据是连续的。

造连续自增的测试数据的方法就不说了。

场景SQL

此次测试模拟一个分布式事务，SQL类似如下：

-- session A
begin ;
select value from account where id = 174 for update ;
update account set  value = value - 7 , gmt_modified = sysdate where id = 174 ;
update account set  value = value + 7 , gmt_modified = sysdate where id = 165 ;
-- commit or rollback;
commit;

新建JMeter测试计划

JMeter能在命令行下运行，也可以以图形界面运行。这里我简单点直接用图形界面这种方式。

新建测试计划

测试计划属性

新建 Thread-Group

这里有很多跟多线程运行有关的JMeter参数，具体说明可以查看JMeter官网文档。
注意这里的Number of Threads是指压测的客户端线程数。

JDBC连接属性

这里面属性很多，都是一个连接池常具备的参数。有兴趣的可以看看网上关于Java连接池配置的经验。

这里面也有几个参数强调一下：

事务参数(变量)

在这个测试里，有三个变量：账户A，账户B，转账金额，所以需要设置参数。

账户参数和金额采取随机数，随机数的值不要超出测试数据实际范围。

事务控制器

这里面是维护每个事务的逻辑。事务由一组JDBC请求组成。

开启事务

选择 Autocommit(false)，开启显式事务。

查询账户A的余额

这里查询账户A的记录会同时锁住这笔记录，即常用的悲观锁技术。这一步看测试需要，不是必需的。

select value from account where id = ? for update ;

注意所有参数都使用 Prepared Statement，以下同。

这一步后面按业务设计应该检查一下返回值是否大于要转账的值，如果不满足就是“转账余额不足”。这里我没有去研究JMeter如果根据查询返回值进行逻辑判断。有兴趣的朋友可以自己研究。

扣减账户A的余额

SQL很简单。

update account set  value = value - ? , gmt_modified = sysdate where id = ? ;

多个绑定参数使用逗号(，)分隔。

然后要新增一个Post处理逻辑，获取更新返回值

增加账户B的余额

SQL很简单。

update account set  value = value + ? , gmt_modified = sysdate where id = ? ;

同样，需要增加一个Post处理器

判断逻辑——成功流程

如果上面两笔账户的更新成功，则提交事务。

新增判断控制 IF

新增动作 

判断逻辑——失败流程

如果上面两笔账户的更新有一笔失败，则回滚事务。

新增判断控制 IF

新增动作

查看结果细节

可以查看成功、失败的结果

查看汇总报告

数据库SQL审计

在业务租户下的sys用户下，利用OceanBase的SQL审计功能可以查看JMeter发出的测试SQL细节。在这个里面可以看到SQL的执行细节(错误码、耗时、等待事件之类)，对分析性能结果非常有帮助。

select /*+ read_consistency(weak) query_timeout(1000000000) */ TO_CHAR(request_time / (1000000 * 60 * 60 * 24) + TO_DATE('1970-01-01 08:00:00', 'YYYY-MM-DD HH:MI:SS'), 'HH24:MI:SS')  request_time_,  sid ,query_sql, affected_rows,return_rows, ret_code, event, state, plan_type,is_hit_plan, elapsed_time, execute_time, queue_time, decode_time, get_plan_time, block_cache_hit, bloom_filter_cache_Hit, block_index_cache_hit, disk_reads,retry_cnt,table_scan, memstore_read_row_count, ssstore_read_row_count, round(request_memory_used/1024/1024) req_mem_mb
from gv$sql_audit
where 1=1 AND user_name='TPCC' AND DB_NAME='TPCC' AND query_sql NOT LIKE '%SHOW%'
order by request_time desc ;

其他

这个测试场景和方法虽然简单，但实际测试中可能会遇到一些问题。分析这些问题也可以了解OceanBase的特点。

如果测试数据记录数很少，使用一定的并发压测，很容易就出现锁等待和阻塞现象。这个时候看报告会发现update的延时会增加，甚至rollback的事件会增加。如果默认的锁等待时间和事务超时时间很长，可能发现update都堵在那里，会有很多死锁事件。详情请参见《

从ORACLE/MySQL到OceanBase：数据库超时机制

参考