黄东旭解析 TiDB 的核心优势
670
2024-04-02
申请***TiDB地址:https://market.aliyun.com/isv-pingcap 的过程,申请和部署过程非常简单直观,按提示一步步来即可,这里就忽略了。
本次实验,主要对该云TiDB集群进行性能测试,使用测试工具有 sysbench,tpcc, CH-benCHmark
参考文档:
如何用 Sysbench 测试 TiDB
如何对 TiDB 进行 TPC-C 测试
如何对 TiDB 进行 CH-benCHmark 测试
TiDB 参数配置
log.level: "error" prepared-plan-cache.enabled: true tikv-client.max-batch-wait-time: 2000000TiKV 参数配置
storage.scheduler-worker-pool-size: 5 raftstore.store-pool-size: 3 raftstore.apply-pool-size: 3 rocksdb.max-background-jobs: 8 server.grpc-concurrency: 6 readpool.unified.max-thread-count: 10TiDB 全局变量配置
set global tidb_hashagg_final_concurrency=1; set global tidb_hashagg_partial_concurrency=1; set global tidb_enable_async_commit = 1; set global tidb_enable_1pc = 1; set global tidb_guarantee_linearizability = 0; set global tidb_enable_clustered_index = 1; set global tidb_prepared_plan_cache_size=1000;sysbench主要对集群做基准测试,主要关注qps 和 延迟
选择Control Server,远程连接进入shell环境, 安装sysbench
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ su - root Password: [root@iZuf69qre7ea5dnxxcfnd1Z ~]# yum install sysbench[root@iZuf69qre7ea5dnxxcfnd1Z ~]# sysbench --version sysbench 1.0.17建库 sbtest,用于sysbench压测
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ mysql -h192.168.44.197 -P4000 -uroot -p Enter password: MySQL [(none)]> create database sbtest;初始化压测数据,建16张表,每张表 1千万 数据量
[ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z ~]$ cd /usr/share/sysbench [ecs-assist-user@iZuf69qre7ea5dnxxcfnd1Z sysbench]$ sysbench oltp_common \ --threads=16 \ --rand-type=uniform \ --db-driver=mysql \ --mysql-db=sbtest \ --mysql-host=192.168.44.197 \ --mysql-port=4000 \ --mysql-user=root \ --mysql-password=admin@123456 \ prepare --tables=16 --table-size=10000000预热数据
sysbench oltp_common \ --threads=16 \ --rand-type=uniform \ --db-driver=mysql \ --mysql-db=sbtest \ --mysql-host=192.168.44.197 \ --mysql-port=4000 \ --mysql-user=root \ --mysql-password=admin@123456 \ --time=600 \ --report-interval=10 \ --tables=16 \ --table-size=10000000 \ prewarm执行压测命令
sysbench $testname \ --threads=16 \ --rand-type=uniform \ --db-driver=mysql \ --mysql-db=sbtest \ --mysql-host=192.168.44.197 \ --mysql-port=4000 \ --mysql-user=root \ --mysql-password=admin@123456 \ --time=600 \ --report-interval=10 \ --tables=16 \ --table-size=10000000 \ run其中$testname 表示测试case,包括oltp_point_select, oltp_update_index, oltp_update_non_index, oltp_read_write几种,可以调整并发数(threads),每次压测执行10分钟
TPC-C 是一个对 OLTP(联机交易处理)系统进行测试的规范,使用一个商品销售模型对 OLTP 系统进行测试。
TPC-C 使用 tpmC 值 (Transactions per Minute) 来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput),其中 Transactions 以 NewOrder Transaction 为准,即最终衡量单位为每分钟处理的新订单数。
这里使用go-bench工具,支持 tpcc、ch 压测。
通过tiup 安装 go-bench
tiup install bench导入数据,数据库为tpcc,使用1000个 warehouse
tiup bench tpcc -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 --threads 20 prepare执行压测命令
tiup bench tpcc -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 --threads 50 --time 600s run测试10分钟,可以调整并发数( threads)
CH-benCHmark 是包含 TPC-C 和 TPC-H 的混合负载,也是用于测试 HTAP 系统的最常见负载。
这里同样使用go-bench工具。
注:安装go-bench工具包 和 导入 tpcc数据部分,在上面的tpcc测试部分已经做了,这里两步可以省略
通过tiup 安装 go-bench
tiup install bench导入TPC-C数据
tiup bench tpcc -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 --threads 20 prepare导入 TPC-H 所需额外的表和视图
tiup bench ch -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc prepare创建TiFlash副本 默认情况下,TiFlash不会自动同步TiKV的数据,需要执行下面的命令来创建TiFlash副本。创建TiFlash副本后,系统自动实现同步最新数据到TiFlash组件
MySQL [(none)]> alter database tpcc set tiflash replica 2;通过下面的SQL语句,来观测副本创建状态
MySQL [tpcc]> SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = tpcc; +--------------+------------+----------+---------------+-----------------+-----------+----------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS | +--------------+------------+----------+---------------+-----------------+-----------+----------+ | tpcc | nation | 353 | 2 | | 1 | 1 | | tpcc | supplier | 357 | 2 | | 1 | 1 | | tpcc | region | 355 | 2 | | 1 | 1 | | tpcc | item | 351 | 2 | | 1 | 1 | | tpcc | warehouse | 335 | 2 | | 1 | 1 | | tpcc | new_order | 343 | 2 | | 1 | 1 | | tpcc | history | 341 | 2 | | 1 | 1 | | tpcc | stock | 349 | 2 | | 1 | 1 | | tpcc | orders | 345 | 2 | | 1 | 1 | | tpcc | district | 337 | 2 | | 1 | 1 | | tpcc | order_line | 347 | 2 | | 1 | 1 | | tpcc | customer | 339 | 2 | | 1 | 1 | +--------------+------------+----------+---------------+-----------------+-----------+----------+ 12 rows in set (0.00 sec)当看到所有表的AVAILABLE=1 , PROGRESS=1,表示tpcc库上所有表的TiFlash副本同步完成
搜集统计信息
analyze table customer; analyze table district; analyze table history; analyze table item; analyze table new_order; analyze table order_line; analyze table orders; analyze table stock; analyze table warehouse; analyze table nation; analyze table region; analyze table supplier;执行压测命令
tiup bench ch -H 192.168.44.197 -P 4000 -U root -p admin@123456 -D tpcc --warehouses 1000 -T 50 -t 1 --time 30m run这里压测跑 50 TP 并发,1 AP 并发,跑30分钟
Point Select
ThreadsQPS95% latency15056024.444.6530058633.859.3960058821.172090058236.1929.72100057678.533.72600个并发时QPS最高
Update Index
ThreadsQPS95% latency15012163.2523.5230012748.1946.6360014646.5873.1390015417.34104.84100015311.59123.28900个并发时QPS最高
Update Non Index
ThreadsQPS95% latency15022690.3910.4630024344.7919.6560024843.8241.190024574.5564.47100024372.971.83600个并发时,QPS最高
Read Write
ThreadsQPS95% latency15025796.17186.5430024781.79390.360022372.15861.9590021946.181327.91100021932.331479.41200个并发时,tpmc最高
Q10以后的查询报错,没有跑成功
***提供的试用版本的TiDB,基本能够完成常规的OLTP,OLAP操作。
但是由于刚接触TiDB集群,对集群的性能优化这块不太数据,对测试结果比较疑惑
Sysbench在各种查询下,并发在600左右下,QPS最高
TPC-C在200个并发下最高,后面成下降趋势
CH-benCHmark 中的查询SQL,Q10出错,后续的Q11-Q22都没跑
这里只是先做个简单记录,后续有机会的话再深入研究一下TiDB的性能优化部分
PS:通过跟TiDB老师反馈,了解到上面压测不理想的原因在于Control Server机器的配置比较低,只有2c ,在压测中他成为了瓶颈,导致压测数据不理想,以后测试的时候需要注意,同时也谢谢老师的反馈。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。