OceanBase和TiDB  Sysbench测试对比

1. 环境准备

主机	CPU	E5-2430 0 @ 2.20GHz	*24
	内存	8G	*12
	DISK	SATA 2T	*11	用LVM管理
	网卡	千兆

TiDB  7台机器：  PD（3台）+ TiKV（3台）+ TiDB（1台）
OB     7台机器： OBServer（6台）+ OBProxy(1台）

Sysbench 1.0
准备了 16个表，每个表1亿左右数据。 TiKV是自动把leader分散到三个机器上。OB通过设置将16个表打散到六台机器上。

数据初始化	./sysbench --test=./oltp_read_only.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser"  --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=32 --time=300 --report-interval=5 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016 prepare
纯读场景	./sysbench --test=./oltp_read_only.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser"  --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=96 --time=600  --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016 --secondary=on run
读写混合场景	./sysbench --test=./oltp_read_write.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser"  --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=32 --time=600 --report-interval=5 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 run
纯写场景	./sysbench --test=./oltp_write_only.lua --mysql-host=***.***.82.173 --mysql-port=4001 --mysql-db=test --mysql-user="sbuser"  --mysql-password=sbtest --tables=16 --table_size=100000000 --threads=32 --time=600 --report-interval=5 --db-driver=mysql --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 run

TiDB 集群安装详情 参见其他帖子 TiDB集群手动安装
OB集群安装详情参见其他帖子 OceanBase集群手动安装


2. 纯读场景


报告 见图
[attachment=145361]


备注：
1. 前期初始化1亿*16表数据跑了近8个小时。OB的写特点是写增量在内存里不落盘，待内存使用达到某个阀值后触发冻结、转储和大合并事件。因此OB初始化过程中发生多次冻结事件有部分数据写入失败回滚。
2. 纯读场景刚开始，多跑几次性能会逐步变好。TiKV内部使用rocksdb引擎，数据IO都是buffer io，主机的pagecache达到43G左右不再增长，8-16个并发的时候，推测数据在pagecache命中率很高，所以tikv节点的io压力比observer的IO压力小（OB都是direct io），rt更好，qps更高。而OB主机随着并发增加，运行时间变成，block cache的命中率从80%提升到97%后，OB的rt 逐渐下降，observer节点的io压力从早期的100%回落到80%左右。
3. 观察tikv 和observer机器的io特点。tikv 节点磁盘的平均每个读io的大小在30K左右，observer节点磁盘的平均每个读io大小在12K左右。observer的block cache hit 大小对observer性能影响比较大。磁盘的性能对tikv影响比较大。
4. 最早的时候ob租户只选了3台机器，且只有一台机器提供服务。后来误判性能跟不上，就直接将租户扩容到6台机器全部使用。


3. 读写混合场景


报告见图
[attachment=145365]






4. 纯写场景


报告见图
[attachment=145366]


备注：
1. 在128并发的时候，OB的QPS反而下降了，分析发现是此时 数据报错（主要是主键冲突）增多导致。




5. 总结


a. 对TiDB了解很浅，配置文件主要是参考网友方法搭建，可能存在某些参数不是最优。而这个机器的配置是为OceanBase做过定制。这方面对二者性能可能有些影响。如果有人有好的经验，欢迎指出来。
b. 机器的磁盘是SATA盘，属于生产环境下线的老机器。最新的机器都是普通ssd做raid 5.  这个SATA盘对TiDB的性能可能影响比较大，不过对OB影响不大。后面我会再换ssd机器做对比测试。
c. 早期做过16个表*1kw数据的测试，结论也是这样。这里每个表1亿的数据量，对OB的影响还是有一点，因为没有用分区表，所以对表的随机读取会触发很多磁盘io。当OB的block cache 命中率达到97%后，这部分影响基本消失。
d. TiDB的架构特点是计算与存储分离，OB的架构里没有做分离。6个observer节点作用一样，都承担sql运算和数据存储功能。从细节上来说这个对比很难做到公平，但从客户角度，同样提供7台机器，看总的性能输出还是有说服力的。