基于阿里云数据库 TiDB 的性能压测初体验
作者: arron 原文来源:https://tidb.net/blog/3be2792c
基于阿里云数据库 TiDB 的性能压测初体验
申请阿里云 TiDB 地址:https://market.aliyun.com/isv-pingcap
的过程,申请和部署过程非常简单直观,按提示一步步来即可,这里就忽略了。
本次实验,主要对该云 TiDB 集群进行性能测试,使用测试工具有 sysbench,tpcc, CH-benCHmark
参考文档:
1. 集群环境
1.1 硬件配置
| 服务类型 | ECS 类型 | 实例数 | CPU | 内存 | 备注 || ————– | ———- | — | ——- | — | – || PD | c6.large | 3 | 2 vCore | 4G | || TiKV | i3.2xlarge | 3 | 8 vCore | 64G | || TiDB | c6.xlarge | 2 | 4 vCore | 8G | || TiFlash | i3.2xlarge | 2 | 8 vCore | 64G | || Control Server | c6.large | 1 | 2 vCore | 4G | |
1.2 软件版本
1.3 参数配置
TiDB 参数配置
TiKV 参数配置
TiDB 全局变量配置
2. 压测步骤
2.1 Sysbench 测试
sysbench 主要对集群做基准测试,主要关注 qps 和 延迟
选择 Control Server,远程连接进入 shell 环境, 安装 sysbench
建库 sbtest,用于 sysbench 压测
初始化压测数据,建 16 张表,每张表 1 千万 数据量
预热数据
执行压测命令
其中$testname
表示测试 case,包括oltp_point_select
, oltp_update_index
, oltp_update_non_index
, oltp_read_write
几种,可以调整并发数 (threads),每次压测执行 10 分钟
2.2 TPC-C 测试
TPC-C 是一个对 OLTP(联机交易处理)系统进行测试的规范,使用一个商品销售模型对 OLTP 系统进行测试。
TPC-C 使用 tpmC 值 (Transactions per Minute) 来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput),其中 Transactions 以 NewOrder Transaction 为准,即最终衡量单位为每分钟处理的新订单数。
这里使用 go-bench 工具,支持 tpcc、ch 压测。
通过 tiup 安装 go-bench
导入数据,数据库为 tpcc,使用 1000 个 warehouse
执行压测命令
测试 10 分钟,可以调整并发数 ( threads)
2.3 CH-benCHmark 测试
CH-benCHmark 是包含 TPC-C 和 TPC-H 的混合负载,也是用于测试 HTAP 系统的最常见负载。
这里同样使用 go-bench 工具。
注:安装 go-bench 工具包 和 导入 tpcc 数据部分,在上面的 tpcc 测试部分已经做了,这里两步可以省略
通过 tiup 安装 go-bench
导入 TPC-C 数据
导入 TPC-H 所需额外的表和视图
创建 TiFlash 副本默认情况下,TiFlash 不会自动同步 TiKV 的数据,需要执行下面的命令来创建 TiFlash 副本。创建 TiFlash 副本后,系统自动实现同步最新数据到 TiFlash 组件
通过下面的 SQL 语句,来观测副本创建状态
当看到所有表的AVAILABLE
=1 , PROGRESS
=1,表示 tpcc 库上所有表的 TiFlash 副本同步完成
搜集统计信息
执行压测命令
这里压测跑 50 TP 并发,1 AP 并发,跑 30 分钟
3. 压测结果
3.1 sysbench 压测结果
Point Select

600 个并发时 QPS 最高
Update Index

900 个并发时 QPS 最高
Update Non Index

600 个并发时,QPS 最高
Read Write

3.2 TPC-C 压测结果

200 个并发时,tpmc 最高
3.3 CH-benCHmark 压测结果
Q10 以后的查询报错,没有跑成功
4. 总结
阿里云提供的试用版本的 TiDB,基本能够完成常规的 OLTP,OLAP 操作。
但是由于刚接触 TiDB 集群,对集群的性能优化这块不太数据,对测试结果比较疑惑
Sysbench 在各种查询下,并发在 600 左右下,QPS 最高
TPC-C 在 200 个并发下最高,后面成下降趋势
CH-benCHmark 中的查询 SQL,Q10 出错,后续的 Q11-Q22 都没跑
这里只是先做个简单记录,后续有机会的话再深入研究一下 TiDB 的性能优化部分
PS:通过跟 TiDB 老师反馈,了解到上面压测不理想的原因在于 Control Server 机器的配置比较低,只有 2c ,在压测中他成为了瓶颈,导致压测数据不理想,以后测试的时候需要注意,同时也谢谢老师的反馈。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/e7f34a5df9760fff2e6e460ec】。文章转载请联系作者。
评论