BenchmarkSQL支持TiDB驱动及tidb-loadbalance介绍

使用 BenchmarkSQL 对 TiDB 进行 TPC-C 测试

众所周知 TiDB 是一个兼容 MySQL 协议的分布式关系型数据库，用户可以使用 MySQL 的驱动以及连接方式连接 TiDB 进行使用，并且使用语法上与 MySQL 也没有差异。TPC-C 是一个对 OLTP（联机交易处理）系统进行测试的规范，模拟的是一个商品销售模型的场景，包括新订单生成、订单付款、最近订单查询、配送、库存缺货状态分析。

PingCAP 在早期通过在开源的 BenchmarkSQL5.0 的基础上添加了对 MySQL 协议的支持，实现对 TiDB 进行 TPC-C 测试。具体可以参考 PingCAP 官方文档：https://docs.pingcap.com/zh/tidb/v3.0/benchmark-tidb-using-tpcc

TiDB-JDBC 以及 tidb-loadbalance 介绍

由于早期版本 TiDB 计算节点并不支持负载均衡，所以 TiDB 集群需要配合 HAProxy、LVS 或者 F5 等负载均衡使用，将应用连接分发到不同的计算节点上。TiDB 官方在 6.1 版本之后针对 Java 程序推出了 TiDB 自己的驱动 TiDB-JDBC和 Java 客户端负载均衡 tidb-loadbalance:

?TiDB-JDBC是基于 MySQL 8.0.29 的定制版本。TiDB-JDBC 基于 MySQL 官方 8.0.29 版本编译，修复了原 JDBC 在 prepare 模式下多参数、多字段 EOF 的错误，并新增 TiCDC snapshot 自动维护和 SM3 认证插件等功能。

?tidb-loadbalance 是应用端的负载均衡组件。通过 tidb-loadbalance，你可以实现自动维护 TiDB server 的节点信息，根据节点信息使用 tidb-loadbalance 策略在客户端分发 JDBC 连接。客户端应用与 TiDB server 之间使用 JDBC 直连，性能高于使用负载均衡组件。目前 tidb-loadbalance 已实现轮询、随机、权重等负载均衡策略。

适配 BenchmarkSQL

我们希望让 BenchmarkSQL 支持 TiDB-JDBC 驱动以及 tidb-loadbalance 应用端负载均衡，这样在对 TiDB 进行 TPC-C 测试时可以不用额外部署负载均衡软件来支持连接分发。先附上修改适配之后的 Github 仓库链接：https://github.com/Win-Man/benchmarksql/tree/5.0-tidb-support

本节将详细介绍如何通过修改 BenchmarkSQL 代码来支持 TiDB 驱动。

增加 TiDB 数据库类型定义

修改 src/client/jTPCC.java 文件，增加 TiDB 数据库定义：

if (iDB.equals("firebird")) dbType = DB_FIREBIRD; else if (iDB.equals("***")) dbType = DB_ORACLE; else if (iDB.equals("postgres")) dbType = DB_POSTGRES; else if (iDB.equals("mysql")) dbType = DB_MYSQL; else if (iDB.equals("tidb")) dbType = DB_TIDB; else { log.error("unknown database type " + iDB + ""); return; }

修改 src/client/jTPCCConfig.java 文件，增加 TiDB 数据库类型：

public final static int DB_UNKNOWN = 0, DB_FIREBIRD = 1, DB_ORACLE = 2, DB_POSTGRES = 3, DB_MYSQL = 4, DB_TIDB = 5;

SQL 子查询增加别名

修改 src/client/jTPCCConnection.java 在 SQL 子查询中增加 AS L 别名，否则会出现语法错误。

default: stmtStockLevelSelectLow = dbConn.prepareStatement( "SELECT count(*) AS low_stock FROM (" + " SELECT s_w_id, s_i_id, s_quantity " + " FROM bmsql_stock " + " WHERE s_w_id = ? AND s_quantity < ? AND s_i_id IN (" + " SELECT ol_i_id " + " FROM bmsql_district " + " JOIN bmsql_order_line ON ol_w_id = d_w_id " + " AND ol_d_id = d_id " + " AND ol_o_id >= d_next_o_id - 20 " + " AND ol_o_id < d_next_o_id " + " WHERE d_w_id = ? AND d_id = ? " + " ) " + " )AS L"); break;

修改测试运行脚本

修改 run/funcs.sh 文件，添加 TiDB 驱动拷贝操作

function setCP() { case "$(getProp db)" in firebird) cp="../lib/firebird/*:../lib/*" ;; ***) cp="../lib/***/*" if [ ! -z "${ORACLE_HOME}" -a -d ${ORACLE_HOME}/lib ] ; then cp="${cp}:${ORACLE_HOME}/lib/*" fi cp="${cp}:../lib/*" ;; postgres) cp="../lib/postgres/*:../lib/*" ;; mysql) cp="../lib/mysql/*:../lib/*" ;; tidb) cp="../lib/tidb/*:../lib/*" ;; esac myCP=".:${cp}:../dist/*" export myCP } # ---- # Make sure that the properties file does have db= and the value # is a database, we support. # ---- case "$(getProp db)" in firebird|***|postgres|mysql|tidb) ;; "") echo "ERROR: missing db= config option in ${PROPS}" >&2 exit 1 ;; *) echo "ERROR: unsupported database type db=$(getProp db) in ${PROPS}" >&2 exit 1 ;; esac

新增 TiDB 配置文件模板 props.tidb

新增 run/props.tidb 配置文件：

db=tidb driver=com.tidb.jdbc.Driver conn=jdbc:tidb://127.0.0.1:4000/tpcc?useSSL=false&useServerPrepStmts=true&useConfigs=maxPerformance&rewriteBatchedStatements=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=2048 user=root password= warehouses=1 loadWorkers=4 terminals=1 //To run specified transactions per terminal- runMins must equal zero runTxnsPerTerminal=0 //To run for specified minutes- runTxnsPerTerminal must equal zero runMins=10 //Number of total transactions per minute limitTxnsPerMin=0 //Set to true to run in 4.x compatible mode. Set to false to use the //entire configured database evenly. terminalWarehouseFixed=true //The following five values must add up to 100 //The default percentages of 45, 43, 4, 4 & 4 match the TPC-C spec newOrderWeight=45 paymentWeight=43 orderStatusWeight=4 deliveryWeight=4 stockLevelWeight=4 // Directory name to create for collecting detailed result data. // Comment this out to suppress. resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS //osCollectorScript=./misc/os_collector_linux.py //osCollectorInterval=1 //osCollectorSSHAddr=user@dbhost //osCollectorDevices=net_eth0 blk_sda

添加 TiDB-JDBC 驱动以及 tidb-loadbalance jar 包

新建 lib/tidb 目录并放入 jar 包

??

?

测试使用

下载测试程序

git clone -b 5.0-tidb-support https://github.com/Win-Man/benchmarksql.git

安装 java 和 ant，以 CentOS 为例，可以执行以下命令进行安装

sudo yum install -y java ant

进入 benchmarksql 目录并执行 ant 构建

cd benchmarksql ant

修改 benchmarksql/run/props.tidb 文件

conn=jdbc:mysql://{TiDB-IP}:{TiDB-PORT}/tpcc?useSSL=false&useServerPrepStmts=true&useConfigs=maxPerformance warehouses=1000 # 使用 1000 个 warehouse terminals=500 # 使用 500 个终端 loadWorkers=32 # 导入数据的并发数

{TiDB-IP}:{TiDB-PORT} 只需要填 TiDB 集群任意一个 TiDB Server 计算节点的 IP 地址与端口就可以，程序启动之后 tidb-loadbalance 会自动发现集群内部所有的计算节点并进行连接的分发。

在 TiDB 中创建 TPCC 测试库

create database tpcc;

运行 BenchmarkSQL 建表脚本并导入数据：

cd run && \ ./runSQL.sh props.tidb sql.mysql/tableCreates.sql && \ ./runSQL.sh props.tidb sql.mysql/indexCreates.sql ./runLoader.sh props.tidb

运行测试

./runBenchmark.sh props.tidb

??

?

TPCC测试对于分布式数据库测试的意义

分布式数据库在近两年的热度一直非常高，由于 *** 以及***的 TPCC 打榜：

?世界第一！***云数据库 *** 登顶 TPC-C 榜，刷新全球纪录?

?*** 登顶 TPC-C：无关比赛，只是在追求自我的极致?

很多人在数据库选型的时候会关注 TPCC 的测试结果，所以也有很多数据库厂商会在 TPCC 测试上进行专门的优化以此来提升在 POC 节点的测试成绩。但是往往有很多客户在做了数据库选型之后，将数据库产品应用于真实业务场景时发现，一些在 POC 时 TPCC 测试成绩优异的产品，对于真实业务的性能提升非常有限，甚至有些还不如没做分布式改造之前的性能。所以在做数据库选型测试，我们规划测试案例的时候，我们需要非常清楚我们设计的测试案例所要测试的目的以及测试案例设计的是否合理。完整的数据库选型如何设计这是一个非常大的题目，我这边不做展开讲述，但是在客户选择使用 TPCC 作为数据库选型中的性能指标这一点上，我有一些自己的想法。

首先我们先了解 TPCC 这个测试的业务场景，这是一个典型的商品销售模型的场景，包括新订单生成、订单付款、最近订单查询、配送、库存缺货状态分析。交易的业务逻辑主要有：

仓库（Warehouse），有很多的仓库，每个仓库有很多的商品（Item），每个商品在每个仓库有自己的库存数目。仓的数目很多，比如一般测试都是1000仓起步（这个与一些电商平台是不一样的，例如淘宝，核心单元可能就个位数）。

买家（Customer），绝大多数情况下，买家只会从绑定的一个仓库买东西；少数情况下，买家才会从其他仓库买东西

基于这样的业务特征，很容易想到将数据库按照仓库 ID 进行分片，大多数的事务可以在单个分片内完成。对仓库 ID 进行分片这个第一反应就是很适合分库分表的分布式数据库解决方案。对数据进行分片之后，事务都在单个分片内执行，也就是在分库分表方案底下的单个数据库实例中实现，通过增加分片数量就可以很好的扩展整体的 TPCC 测试性能，从这个逻辑上 TPCC 体现的是单个数据库实例的性能，并不是一个分布式数据库整体的分布式能力。合理的设计分片字段后，只有少量的跨节点分布式事务，这对于分布式数据库的选型其实绕过了重要的分布式事务性能测试的点。

而很多 TPC-C 测试性能优异但是真实业务场景性能平平的原因，原因在于 TPCC 的测试模型相对简单，真实世界是非常复杂的，真实的业务场景也不一定能够完美的设计分片键将所有的数据库按照分片规则去分布，在单个数据库实例内部完成事务。一旦涉及到跨节点的分布式事务，分库分表的分布式解决方案在性能上会大幅下降，因为基于分库分表的方案底层还是 MySQL 或者 *** ,这些数据库不是原生的分布式数据库，要实现分布式事务需要通过 XA 事务接口或者其他方式实现，其性能不如原生的分布式数据库。并且原生分布式数据库从架构设计上就是为分布式考虑的，所以在分布式事务优化方面有更大的空间以及灵活度。

总结来说，TPCC 的性能测试仅建议做参考不建议作为选型依据，如果是希望数据库选型的性能测试，建议使用真实业务场景进行测试更为准确靠谱。可以通过 JMeter 压测业务接口模拟不同的业务压力。

其他可参考文档

?tidb-loadbalance 客户端方式软负载均衡配置实践?

?选择驱动或 ORM 框架?

?***-X 数据分布解读（三） ：TPCC与透明分布式?

?