3.1 Sysbench 基准性能测试

TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和金融级高可用性，为 OLTP 和 OLAP 场景提供一站式的解决方案。但想要使用 TiDB 时，都会被要求做基准测试并与 MySQL 对比，本文基于 sysbench 工具进行基准测试做简要说明。

3.1.1 工具集方案

• sysbench 安装

  mkdir -p /tmp/sysbench
  cd /tmp/sysbench
  wget https://github.com/akopytov/sysbench/archive/1.0.14.tar.gz
  yum -y install make automake libtool pkgconfig libaio-devel
  yum -y install mariadb-devel
  ./autogen.sh
  ./configure
  make -j
  make install
  sysbench --version

• 硬件配置

• 环境说明

3.1.2 测试实操

1. 测试准备工作

• sysbench 配置

  mysql-host=192.168.xxx.xxx
  mysql-port=4000
  mysql-user=sysbench
  mysql-password=******
  mysql-db=test
  time=60
  threads=16
  report-interval=10
  db-driver=mysql

• sysbench 关键参数说明

  --threads=8 表示发起 8 个并发连接
  --report-interval=10 表示每 10 秒输出一次测试进度报告
  --rand-type=uniform 表示随机类型为固定模式，其他几个可选随机模式：uniform (固定)，gaussian (高斯)，special (特定的)，pareto (帕累托)
  --time=120 表示最大执行时长为 120 秒
  --events=0 表示总请求数为 0，因为上面已经定义了总执行时长，所以总请求数可以设定为 0；也可以只设定总请求数，不设定最大执行时长
  --percentile=99 表示设定采样比例，默认是 95%，即丢弃 1% 的长请求，在剩余的 99% 里取最大值

• sysbench 结果解读

sysbench 1.0.14 (using bundled LuaJIT 2.1.0-beta2)
Running the test with following options:
Number of threads: 16
Report intermediate results every 10 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
# 每 10 秒钟报告一次测试结果，tps、每秒读、每秒写、95% 以上的响应时长统计
[ 10s ] thds: 16 tps: 21532.38 qps: 21532.38 (r/w/o: 21532.38/0.00/0.00) lat (ms,95%): 1.04 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 16 tps: 21617.20 qps: 21617.20 (r/w/o: 21617.20/0.00/0.00) lat (ms,95%): 1.01 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 16 tps: 21550.98 qps: 21550.98 (r/w/o: 21550.98/0.00/0.00) lat (ms,95%): 1.03 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 16 tps: 21544.16 qps: 21544.16 (r/w/o: 21544.16/0.00/0.00) lat (ms,95%): 1.01 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 16 tps: 21639.76 qps: 21639.76 (r/w/o: 21639.76/0.00/0.00) lat (ms,95%): 0.99 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 16 tps: 21597.56 qps: 21597.56 (r/w/o: 21597.56/0.00/0.00) lat (ms,95%): 1.01 err/s: 0.00 reconn/s: 0.00
SQL statistics:
    queries performed:
        read:                            1294886                        # 读总数
        write:                           0                              # 写总数
        other:                           0                              # 其他操作总数 (COMMIT 等)
        total:                           1294886                        # 全部总数
    transactions:                        1294886 (21579.74 per sec.)    # 总事务数 ( 每秒事务数 )
    queries:                             1294886 (21579.74 per sec.)    # 读总数 ( 每秒读次数 )
    ignored errors:                      0      (0.00 per sec.)         # 忽略错误数 ( 每秒忽略错误数 )
    reconnects:                          0      (0.00 per sec.)         # 重连次数 ( 每秒重连次数 )
General statistics:
    total time:                          60.0029s                       # 总共耗时
    total number of events:              1294886                        # 总共发生多少事务数
Latency (ms):
         min:                                    0.36                   # 最小延时 
         avg:                                    0.74                   # 平均延时
         max:                                    8.90                   # 最大延时
         95th percentile:                        1.01                   # 超过 95% 平均耗时
         sum:                               959137.19 
Threads fairness:
    events (avg/stddev):           80930.3750/440.48                    # 平均每线程完成 80930.3750 次 event，标准差为 440.48
    execution time (avg/stddev):   59.9461/0.00                         # 每个线程平均耗时 59.9 秒，标准差为 0

• 准备数据

  sysbench --config-file=sysbench-thread-16.cfg oltp_point_select --tables=32 --table-size=10000000 prepare

• 数据预热与统计信息收集

数据预热可将磁盘中的数据载入内存的 block cache 中，预热后的数据对系统整体的性能有较大的改善，建议在每次重启集群后进行一次数据预热。以表 sbtest1 为例，执行如下 SQL 语句 进行数据预热，命令如下：

SELECT COUNT(pad) FROM sbtest1 USE INDEX(k_1);

统计信息收集有助于优化器选择更为准确的执行计划，可以通过 analyze 命令来收集系列表 sbtest* 的统计信息，每个表都需要收集统计信息，以表 sbtest1 为例，命令如下：

ANALYZE TABLE sbtest1;

2. 测试命令举例

• Point select 测试命令

  sysbench --config-file=sysbench-thread-16.cfg oltp_point_select --tables=32 --table-size=10000000 run

• Update index 测试命令

  sysbench --config-file=sysbench-thread-16.cfg oltp_update_index --tables=32 --table-size=10000000 run

• Read-only 测试命令

  sysbench --config-file=sysbench-thread-16.cfg oltp_read_only --tables=32 --table-size=10000000 run

• Write-only 测试命令

  sysbench --config-file=sysbench-thread-16.cfg oltp_write_only --tables=32 --table-size=10000000 run

• Read-Write 测试命令

  sysbench --config-file=sysbench-thread-16.cfg oltp_read_write --tables=32 --table-size=10000000 run

  3. 测试结果举例

  笔者测试数据 32 张表，每张表有 10MB 数据。对集群所有 tidb-server 都同时进行 sysbench 测试，将结果相加，得出最终结果：

• oltp_point_select

• read_only

• oltp_update_index

• write_only

• read_write

3.1.3 总结

由于 TiDB 与 MySQL 在体系架构上的差别非常大，很多方面都很难找到一个共同的基准点，所以大家不要消耗过多精力在这类基准测试上，应该更多关注 TiDB 和 MySQL 在应用程序使用场景上的区别。MySQL 读扩容可以通过添加从库进行扩展，但单节点写入不具备扩展能力只能通过分库分表，而分库分表会增加开发维护方面成本。TiDB 不管是读流量还是写流量都可以通过添加节点的方式进行快速方便的扩展。

TiDB 设计的目标就是针对 MySQL 单台容量限制而被迫做出分库分表的场景，或者需要强一致性和完整分布式事务的场景。它的优势是通过尽量将并行计算下推到各个存储节点。对于小表（比如千万级以下）不适合 TiDB。因为数据量少导致表的 region 数量有限，发挥不了并行计算的优势。最极端的就是计数器表，几行记录高频更新，会变成存储引擎上的几个 KV 高频更新，然后数据都存储在一个 region 里，而这个 region 的流量都在一个计算节点上，再加上后台强一致性复制的开销，以及 TiDB 到 TiKV 的开销，最后表现出来的就是没有单个 MySQL 好。