网站集约化建设调研报告,分销微信小程序开发,上海网站建设q479185700棒,百度网盘登录作者#xff1a; GangShen 原文来源#xff1a; https://tidb.net/blog/3c274180 使用 BenchmarkSQL 对 TiDB 进行 TPC-C 测试 众所周知 TiDB 是一个兼容 MySQL 协议的分布式关系型数据库#xff0c;用户可以使用 MySQL 的驱动以及连接方式连接 TiDB 进行使用#xff0… 作者 GangShen 原文来源 https://tidb.net/blog/3c274180 使用 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-tpccTiDB-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(oracle))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) infirebird)cp../lib/firebird/*:../lib/*;;oracle)cp../lib/oracle/*if [ ! -z ${ORACLE_HOME} -a -d ${ORACLE_HOME}/lib ] ; thencp${cp}:${ORACLE_HOME}/lib/*ficp${cp}:../lib/*;;postgres)cp../lib/postgres/*:../lib/*;;mysql)cp../lib/mysql/*:../lib/*;;tidb)cp../lib/tidb/*:../lib/*;;esacmyCP.:${cp}:../dist/*export myCP
}# ----
# Make sure that the properties file does have db and the value
# is a database, we support.
# ----
case $(getProp db) infirebird|oracle|postgres|mysql|tidb);;) echo ERROR: missing db config option in ${PROPS} 2exit 1;;*) echo ERROR: unsupported database type db$(getProp db) in ${PROPS} 2exit 1;;
esac新增 TiDB 配置文件模板 props.tidb 新增 run/props.tidb 配置文件 dbtidb
drivercom.tidb.jdbc.Driver
connjdbc:tidb://127.0.0.1:4000/tpcc?useSSLfalseuseServerPrepStmtstrueuseConfigsmaxPerformancerewriteBatchedStatementstruecachePrepStmtstrueprepStmtCacheSize1000prepStmtCacheSqlLimit2048
userroot
passwordwarehouses1
loadWorkers4terminals1
//To run specified transactions per terminal- runMins must equal zero
runTxnsPerTerminal0
//To run for specified minutes- runTxnsPerTerminal must equal zero
runMins10
//Number of total transactions per minute
limitTxnsPerMin0//Set to true to run in 4.x compatible mode. Set to false to use the
//entire configured database evenly.
terminalWarehouseFixedtrue//The following five values must add up to 100
//The default percentages of 45, 43, 4, 4 4 match the TPC-C spec
newOrderWeight45
paymentWeight43
orderStatusWeight4
deliveryWeight4
stockLevelWeight4// Directory name to create for collecting detailed result data.
// Comment this out to suppress.
resultDirectorymy_result_%tY-%tm-%td_%tH%tM%tS
//osCollectorScript./misc/os_collector_linux.py
//osCollectorInterval1
//osCollectorSSHAddruserdbhost
//osCollectorDevicesnet_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 文件 connjdbc:mysql://{TiDB-IP}:{TiDB-PORT}/tpcc?useSSLfalseuseServerPrepStmtstrueuseConfigsmaxPerformance
warehouses1000 # 使用 1000 个 warehouse
terminals500 # 使用 500 个终端
loadWorkers32 # 导入数据的并发数{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.tidbTPCC测试对于分布式数据库测试的意义 分布式数据库在近两年的热度一直非常高由于 OceanBase 以及腾讯的 TPCC 打榜世界第一腾讯云数据库 TDSQL 登顶 TPC-C 榜刷新全球纪录 OceanBase 登顶 TPC-C无关比赛只是在追求自我的极致 很多人在数据库选型的时候会关注 TPCC 的测试结果所以也有很多数据库厂商会在 TPCC 测试上进行专门的优化以此来提升在 POC 节点的测试成绩。但是往往有很多客户在做了数据库选型之后将数据库产品应用于真实业务场景时发现一些在 POC 时 TPCC 测试成绩优异的产品对于真实业务的性能提升非常有限甚至有些还不如没做分布式改造之前的性能。所以在做数据库选型测试我们规划测试案例的时候我们需要非常清楚我们设计的测试案例所要测试的目的以及测试案例设计的是否合理。完整的数据库选型如何设计这是一个非常大的题目我这边不做展开讲述但是在客户选择使用 TPCC 作为数据库选型中的性能指标这一点上我有一些自己的想法。首先我们先了解 TPCC 这个测试的业务场景这是一个典型的商品销售模型的场景包括新订单生成、订单付款、最近订单查询、配送、库存缺货状态分析。交易的业务逻辑主要有仓库Warehouse有很多的仓库每个仓库有很多的商品Item每个商品在每个仓库有自己的库存数目。仓的数目很多比如一般测试都是1000仓起步这个与一些电商平台是不一样的例如淘宝核心单元可能就个位数。 买家Customer绝大多数情况下买家只会从绑定的一个仓库买东西少数情况下买家才会从其他仓库买东西 基于这样的业务特征很容易想到将数据库按照仓库 ID 进行分片大多数的事务可以在单个分片内完成。对仓库 ID 进行分片这个第一反应就是很适合分库分表的分布式数据库解决方案。对数据进行分片之后事务都在单个分片内执行也就是在分库分表方案底下的单个数据库实例中实现通过增加分片数量就可以很好的扩展整体的 TPCC 测试性能从这个逻辑上 TPCC 体现的是单个数据库实例的性能并不是一个分布式数据库整体的分布式能力。合理的设计分片字段后只有少量的跨节点分布式事务这对于分布式数据库的选型其实绕过了重要的分布式事务性能测试的点。而很多 TPC-C 测试性能优异但是真实业务场景性能平平的原因原因在于 TPCC 的测试模型相对简单真实世界是非常复杂的真实的业务场景也不一定能够完美的设计分片键将所有的数据库按照分片规则去分布在单个数据库实例内部完成事务。一旦涉及到跨节点的分布式事务分库分表的分布式解决方案在性能上会大幅下降因为基于分库分表的方案底层还是 MySQL 或者 PostgreSQL ,这些数据库不是原生的分布式数据库要实现分布式事务需要通过 XA 事务接口或者其他方式实现其性能不如原生的分布式数据库。并且原生分布式数据库从架构设计上就是为分布式考虑的所以在分布式事务优化方面有更大的空间以及灵活度。总结来说TPCC 的性能测试仅建议做参考不建议作为选型依据如果是希望数据库选型的性能测试建议使用真实业务场景进行测试更为准确靠谱。可以通过 JMeter 压测业务接口模拟不同的业务压力。其他可参考文档 tidb-loadbalance 客户端方式软负载均衡配置实践 选择驱动或 ORM 框架 PolarDB-X 数据分布解读三 TPCC与透明分布式
