TiDB 5.0 异步事务特性体验——基于X86和ARM混合部署架构

【是否原创】是
【首发渠道】TiDB 社区
【正文】

业务背景

神州数码是国内领先的企业数字化服务商,从2018年开始,我们使用v2.0.5搭建了第一套TiDB数据库集群,之后便与TiDB结下不解之缘,在集团内多个业务场景下使用TiDB, 其中一个比较有意思的场景是员工考勤。

神州数码拥有三家上市公司,平台遍布全国各地,员工数量众多,早上九点左右打卡,打卡途径包括但不限于门禁、指纹、人脸识别和移动签到,并且各地的考勤规则也略有差异。各地的打卡机不同,对接的数据库也不同,比如mysql、oracle、SQL Server等。过去,员工只能在下午四点半以后才能查询当天早上的打卡情况。随着业务规模和人员数量的增长,服务器需要不停的升级以应对高峰期打卡时的并发数据量,有时会出现打卡异常情况。上下班高峰期对考勤系统是一个不小的挑战,并且这是一个典型的写多读少的场景,为了能及时反馈打卡结果,对数据写入的延迟要求比较高。

而TiDB在5.0版本中提供了异步事务提交特性,这一点对写入频繁的场景非常有用,它可以有效地降低请求延时提高吞吐量。 考虑到这非常适用于考勤系统的场景,我们在同等配置下测试TiDB 5.0对事务读写性能的提升情况。

为什么使用混合部署架构

ARM架构的处理器以其优异的性能、低廉的成本和功耗被越来越多地使用在各种设备之上,对比X86的机器,ARM机器在性能功耗比(Performance per watt)方面是具有天然优势的,众多服务器厂商也早已经把ARM架构应用在CPU设计中,华为鲲鹏920便是比较典型的一款产品。

TiDB可以完美运行在ARM架构之上,这一点已经有实际案例可以说明。

基于TiDB的多平台兼容特性,我们同时使用ARM和X86的机器搭建混合架构的TiDB集群,来测试一下在混合部署架构下TiDB 5.0的异步事务提交特性到底有多少性能提升。

本次测试使用ARM物理机是神州鲲泰多路服务器,它搭载了4颗鲲鹏920CPU,核心数达到96核。

资源配置

本次测试所有的节点都运行在Centos 7.6系统,ARM节点和X86节点分别运行在两台物理机,使用千兆网络通信。

TiDB集群的拓扑结构如下图所示:

具体说明为:

  • 3台相同配置的TiDB节点,其中2台ARM+1台X86
  • 3台相同配置的PD节点,其中2台ARM+1台X86
  • 6台相同配置的TiKV节点,其中3台ARM+3台X86
  • 1台监控节点,ARM架构
  • 1台HAProxy节点,X86架构
  • 1台Sysbench节点,X86架构

测试工具使用Sysbench基准测试,版本是1.0.20,用oltp_read_write场景模拟复杂的事务提交,最后对比TiDB 4.0版本和5.0版本在不同并发量下事务的吞吐量和延时情况。

TiDB集群配置项:

global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"
  arch: "arm64"

monitored:
  node_exporter_port: 9100
  blackbox_exporter_port: 9115

server_configs:
  tidb:
    log.level: "error"
    prepared-plan-cache.enabled: true
  tikv:
    log.level: "error"

pd_servers:
  - host: 10.3.65.xxx
  - host: 10.3.65.xxx
  - host: 10.3.70.xxx
    arch: "amd64"

tidb_servers:
  - host: 10.3.65.xxx
  - host: 10.3.65.xxx
  - host: 10.3.70.xxx
    arch: "amd64"

tikv_servers:
  - host: 10.3.65.xxx
  - host: 10.3.65.xxx
  - host: 10.3.65.xxx
  - host: 10.3.70.xxx
    arch: "amd64"
  - host: 10.3.70.xxx
    arch: "amd64"
  - host: 10.3.70.xxx
    arch: "amd64"

  - host: 10.3.65.xxx

  - host: 10.3.65.xxx

alertmanager_servers:
  - host: 10.3.65.xxx

测试方法

  • 使用tiup部署4.0.0版本集群
  • 使用HAProxy代理3个TiDB节点
  • 使用Sysbench准备测试数据,10张表,单表1000万行数据
  • 对oltp_read_write场景分别做并发维度50、100、200、400、800的压测
  • 销毁集群
  • 用相同的配置文件部署5.0.0版本集群,默认开启了异步事务提交
  • 使用Sysbench准备相同数据量的测试数据
  • 对oltp_read_write场景分别做并发维度50、100、200、400、800的压测
  • 数据对比得出结论,对比指标分别是QPS、TPS、延时

Sysbench配置项:

 --table_size=10000000 
 --tables=10 
 --threads={50、100, 200, 400, 800} 
 --time=300 
 --report-interval=10

测试步骤

首先搭建TiDB4.0.0集群,集群信息如下:

HAProxy负载均衡清单:

创建测试库:

create database sbtest;

导入测试数据:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=100 --time=300 --report-interval=10 prepare

执行50线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=50 --time=300 --report-interval=10 run

执行100线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=100 --time=300 --report-interval=10 run

执行200线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=200 --time=300 --report-interval=10 run

执行400线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=400 --time=300 --report-interval=10 run

执行800线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=800 --time=300 --report-interval=10 run

以上5次压测的事务监控汇总为:

接下来清理掉4.0.0的集群:

tiup cluster destroy tidb-test

重新部署5.0.0的新集群:

我们查看新集群已经开启了异步事务提交:
image

同样导入单表1000万行数据后做5次压测。

执行50线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=50 --time=300 --report-interval=10 run

执行100线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=100 --time=300 --report-interval=10 run

执行200线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=200 --time=300 --report-interval=10 run

执行400线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=400 --time=300 --report-interval=10 run

执行800线程下的压测:

sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --mysql-host={proxy ip} --mysql-port=4000 --mysql-db=sbtest --mysql-user=root --mysql-password=  --table_size=10000000 --tables=10 --threads=800 --time=300 --report-interval=10 run

以上5次压测的事务监控汇总为:

测试结果

通过以上对比数据可以看出,在并发量比较小的时候5.0版本性能提升非常明显,到400并发后吞吐量已经到了极限,随着并发量不断加大凸显出了硬件瓶颈,性能提升开始放缓,不过此时各指标依然高于4.0版本。

从各节点IO指标的监控数据来看,性能瓶颈主要是TiKV节点IO近乎打满导致,这一点也说明存储层依然对硬件要求比较高,希望TiDB能在后续版本中继续深度优化。

参考官方给出的TiDB 5.0测试数据,混合部署的测试结果在性能提升上还要高于纯X86机器,这一点还是非常让人惊喜的。

另外一点值得一提的是,从各自5次测试的监控曲线来看,TiDB 5.0在事务提交上的稳定性也有肉眼可见的提升,4.0的事务曲线波动比较大,5.0的事务曲线整体趋于平稳。

总结

  • TiDB支持多元架构部署,为各种应用提供架构选择。本次测试的两个TiDB版本都能够非常平稳地运行在混合架构下,整个测试过程没有任何异常问题。
  • 单在事务提交优化上,TiDB 5.0版本比4.0版本有大幅的性能提升,QPS、TPS、延时这3个重要指标都明显优于4.0。
  • 事务性能的提升,意味着TiDB在面对高并发的TP型业务有了更多发展空间。
    分析了上面的测试数据,我们对把已有的业务系统升级到TiDB 5.0有了充足的信心。
6赞