Logo
TPC-C 基准测试

TPC-C 基准测试 #

TPC-C 的测试场景模拟了在线电商的交易情况：

有一个大型商品批发商，在地理分布的多个 区域 (district) 有业务，并且使用仓库管理。当业务扩展的时候，公司将添加新的 仓库 (warehouse)。每个仓库负责为 10 个区域供货；每个区域为 3000 个 客户 (customer) 提供服务。所有仓库维护公司销售的 100,000 种 商品 (item) 的 库存 (stock) 记录。平均每个客户的一个 订单 (order) 有 10 个订单项 (order line)；所有订单中约 1% 的订单项在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。

客户向公司的系统发出新的订单或者查询其订单状态。

公司的系统也用于处理客户的付款，处理发货的订单，检查库存状态以便发现潜在的供货短缺问题。

下图显示了 仓库 (warehouse)，区域 (district) 和 客户 (customer) 间的关系。

测试方案一：单存储节点、单计算节点性能测试 #

选取 BenchmarkSQL 测试单存储节点下的 DBPlusEngine-Proxy、DBPlusEngine-Driver 与 MySQL 的性能对比。

测试目的 #

在相同数据量场景下，使用 BenchmarkSQL 压测模型分别对 DBPlusEngine-Proxy、DBPlusEngine-Driver 与 MySQL 进行性能对比，从而使用户对 DBPlusEngine-Proxy、DBPlusEngine-Driver 性能有详细的了解认识。

测试工具 #

BenchmarkSQL 是一款经典的开源数据库测试工具，内嵌了 TPC-C 测试脚本，可以对 PostgreSQL、MySQL、Oracle 以及 SQL Server 等数据库进行测试。

测试环境 #

应用IP地址端口版本
DBPlusEngine-Proxy192.168.xx.2533071.2
DBPlusEngine-Driver192.168.xx.24-1.2
MySQL192.168.xx.20133068.0.29

服务器配置

条目配置
CPU48 C
内存96 G
硬盘SSD 820 G
JDK17.0.2

测试步骤 #

  1. 创建测试库。
mysql -utest -h192.168.xx.20 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc;
  1. 安装测试工具。
wget https://udomain.dl.sourceforge.net/project/benchmarksql/benchmarksql-5.0.zip
yum -y install ant
unzip benchmarksql-5.0.zip -d  /usr/local
cd /usr/local/benchmarksql-5.0
ant
cp mysql-connector-java-8.0.24.jar benchmarksql-5.0/run/lib

创建 props.proxy 文件。

db=postgres
driver=com.mysql.jdbc.Driver
conn=jdbc:mysql://192.168.xx.25:3307/sharding_db?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=8192&prepStmtCacheSqlLimit=8000
user=root
password=root
warehouses=200
loadWorkers=100
terminals=200
runTxnsPerTerminal=0
runMins=10
limitTxnsPerMin=0
terminalWarehouseFixed=true
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
shardingNumber=1
  1. YAML
rules:
  - !SHARDING
    bindingTables:
      - bmsql_warehouse, bmsql_customer
      - bmsql_stock, bmsql_district, bmsql_order_line
    defaultDatabaseStrategy:
      none:
    defaultTableStrategy:
      none:
    keyGenerators:
      snowflake:
        type: SNOWFLAKE
    tables:
      bmsql_config:
        actualDataNodes: ds_0.bmsql_config

      bmsql_warehouse:
        actualDataNodes: ds_${0..0}.bmsql_warehouse
        databaseStrategy:
          standard:
            shardingColumn: w_id
            shardingAlgorithmName: mod_1

      bmsql_district:
        actualDataNodes: ds_${0..0}.bmsql_district
        databaseStrategy:
          standard:
            shardingColumn: d_w_id
            shardingAlgorithmName: mod_1

      bmsql_customer:
        actualDataNodes: ds_${0..0}.bmsql_customer
        databaseStrategy:
          standard:
            shardingColumn: c_w_id
            shardingAlgorithmName: mod_1

      bmsql_item:
        actualDataNodes: ds_${0..0}.bmsql_item
        databaseStrategy:
          standard:
            shardingColumn: i_id
            shardingAlgorithmName: mod_1

      bmsql_history:
        actualDataNodes: ds_${0..0}.bmsql_history
        databaseStrategy:
          standard:
            shardingColumn: h_w_id
            shardingAlgorithmName: mod_1

      bmsql_oorder:
        actualDataNodes: ds_${0..0}.bmsql_oorder
        databaseStrategy:
          standard:
            shardingColumn: o_w_id
            shardingAlgorithmName: mod_1

      bmsql_stock:
        actualDataNodes: ds_${0..0}.bmsql_stock
        databaseStrategy:
          standard:
            shardingColumn: s_w_id
            shardingAlgorithmName: mod_1

      bmsql_new_order:
        actualDataNodes: ds_${0..0}.bmsql_new_order
        databaseStrategy:
          standard:
            shardingColumn: no_w_id
            shardingAlgorithmName: mod_1

      bmsql_order_line:
        actualDataNodes: ds_${0..0}.bmsql_order_line
        databaseStrategy:
          standard:
            shardingColumn: ol_w_id
            shardingAlgorithmName: mod_1

    shardingAlgorithms:
      mod_1:
        type: MOD
        props:
          sharding-count: 1
  1. 数据准备。

数据库初始化，通过 Proxy 建表并插入数据。

cd /usr/local/benchmarksql/run

./runDatabaseDestroy.sh props.proxy

./runDatabaseBuild.sh props.proxy
  1. 压测阶段。
./runBenchmark.sh props.proxy

测试结果 #

测试对象tpmC
MySQL180,300
DBPlusEngine-Proxy122,299
DBPlusEngine-Driver175,392

结论：在单存储节点场景下， DBPlusEngine-Driver 略低于 MySQL，DBPlusEngine-Proxy 低于 DBPlusEngine-Driver。

监控信息 #

BenchmarkSQL ——> MySQL #

  • MySQL

BenchmarkSQL ——> Proxy ——> MySQL #

  • MySQL

  • Proxy

BenchmarkSQL ——> Driver ——> MySQL #

  • MySQL

  • Driver

名词解释 #

warehouses：仓库数，决定数据量

terminals：线程数

runMins：测试执行时长

tpmC：每分钟处理事务数

测试方案二：存储节点扩容 #

使用 BenchmarkSQL 工具对 2/4 存储节点场景进行压测。

测试目的 #

在相同数据量下，使用 BenchmarkSQL 压测模型分别对 DBPlusEngine-Proxy 2/4 存储节点场景下进行对比，通过压测结果分析，使用户更加理解分片场景下优势。

测试工具 #

BenchmarkSQL

测试环境 #

应用IP地址端口版本
DBPlusEngine-Proxy192.168.xx.2533071.2
MySQL192.168.xx.20133068.0.29
MySQL192.168.xx.21133068.0.29
MySQL192.168.xx.22133068.0.29
MySQL192.168.xx.23133068.0.29

服务器配置

条目配置
CPU48 C
内存96 G
硬盘SSD 820 G
JDK17.0.2

测试步骤 #

  1. 创建测试表。
mysql -utest -h192.168.xx.20 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc;

mysql -utest -h192.168.xx.21 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc;

mysql -utest -h192.168.xx.22 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc; 

mysql -utest -h192.168.xx.23 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc;
  1. 安装测试工具。
wget https://udomain.dl.sourceforge.net/project/benchmarksql/benchmarksql-5.0.zip
yum -y install ant
unzip benchmarksql-5.0.zip -d  /usr/local
cd /usr/local/benchmarksql-5.0
ant
cp mysql-connector-java-8.0.24.jar benchmarksql-5.0/run/lib

创建 props.proxy 文件。

db=postgres
driver=com.mysql.jdbc.Driver
conn=jdbc:mysql://192.168.xx.25:3307/sharding_db?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=8192&prepStmtCacheSqlLimit=8000
user=root
password=root
warehouses=200
loadWorkers=100
terminals=200
runTxnsPerTerminal=0
runMins=10
limitTxnsPerMin=0
terminalWarehouseFixed=true
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
shardingNumber=2
  1. YAML
rules:
  - !SHARDING
    bindingTables:
      - bmsql_warehouse, bmsql_customer
      - bmsql_stock, bmsql_district, bmsql_order_line
    defaultDatabaseStrategy:
      none:
    defaultTableStrategy:
      none:
    keyGenerators:
      snowflake:
        type: SNOWFLAKE
    tables:
      bmsql_config:
        actualDataNodes: ds_0.bmsql_config

      bmsql_warehouse:
        actualDataNodes: ds_${0..1}.bmsql_warehouse
        databaseStrategy:
          standard:
            shardingColumn: w_id
            shardingAlgorithmName: mod_2

      bmsql_district:
        actualDataNodes: ds_${0..1}.bmsql_district
        databaseStrategy:
          standard:
            shardingColumn: d_w_id
            shardingAlgorithmName: mod_2

      bmsql_customer:
        actualDataNodes: ds_${0..1}.bmsql_customer
        databaseStrategy:
          standard:
            shardingColumn: c_w_id
            shardingAlgorithmName: mod_2

      bmsql_item:
        actualDataNodes: ds_${0..1}.bmsql_item
        databaseStrategy:
          standard:
            shardingColumn: i_id
            shardingAlgorithmName: mod_2

      bmsql_history:
        actualDataNodes: ds_${0..1}.bmsql_history
        databaseStrategy:
          standard:
            shardingColumn: h_w_id
            shardingAlgorithmName: mod_2

      bmsql_oorder:
        actualDataNodes: ds_${0..1}.bmsql_oorder
        databaseStrategy:
          standard:
            shardingColumn: o_w_id
            shardingAlgorithmName: mod_2

      bmsql_stock:
        actualDataNodes: ds_${0..1}.bmsql_stock
        databaseStrategy:
          standard:
            shardingColumn: s_w_id
            shardingAlgorithmName: mod_2

      bmsql_new_order:
        actualDataNodes: ds_${0..1}.bmsql_new_order
        databaseStrategy:
          standard:
            shardingColumn: no_w_id
            shardingAlgorithmName: mod_2

      bmsql_order_line:
        actualDataNodes: ds_${0..1}.bmsql_order_line
        databaseStrategy:
          standard:
            shardingColumn: ol_w_id
            shardingAlgorithmName: mod_2

    shardingAlgorithms:
      mod_2:
        type: MOD
        props:
          sharding-count: 2
  1. 数据准备。

数据库初始化，通过 Proxy 建表并插入数据。

cd /usr/local/benchmarksql/run

./runDatabaseDestroy.sh props.proxy

./runDatabaseBuild.sh props.proxy
  1. 压测阶段。
./runBenchmark.sh props.proxy

测试结果 #

测试对象存储节点 AVG(CPU Load)tpmC
DBPlusEngine-Proxy(1 存储节点)73%122,299
DBPlusEngine-Proxy(2 存储节点)30%122,580
DBPlusEngine-Proxy(4 存储节点)12.5%128,035

结论：在 「1 Proxy 节点 + 1 存储节点」的场景下，可以看到性能压测瓶颈在 Proxy 所在服务器 CPU。因此扩容存储节点带来的性能提升不明显；本实验中扩容存储节点带来的优势在于各个存储节点的 CPU 利用率下降。

该结论仅供参考，用户可以根据实际业务情况，实际场景进行测试。

监控信息 #

BenchmarkSQL ——> Proxy ——> MySQL(1) #

  • MySQL

  • Proxy

BenchmarkSQL ——> Proxy ——> MySQL(2) #

  • MySQL(1)

  • MySQL(2)

  • Proxy

BenchmarkSQL ——> Proxy ——> MySQL(4) #

  • MySQL(1)

  • MySQL(2)

  • MySQL(3)

  • MySQL(4)

  • Proxy

名词解释 #

warehouses：仓库数，决定数据量。

terminals：线程数。

runMins：测试执行时长。

tpmC：每分钟处理事务数。

测试方案三：计算节点扩容 #

使用 BenchmarkSQL 工具对 4 存储节点(1 计算节点、2 计算节点)场景进行压测。

测试目的 #

在相同数据量下，使用 BenchmarkSQL 压测模型分别对 1/2 计算节点 DBPlusEngine-Proxy 在 4 存储节点场景下进行对比，通过压测结果分析，使用户更加了解计算节点扩容的优势。

测试工具 #

BenchmarkSQL

测试环境 #

应用IP地址端口版本
DBPlusEngine-Proxy192.168.xx.2533071.2
DBPlusEngine-Proxy192.168.xx.1933071.2
MySQL192.168.xx.20133068.0.29
MySQL192.168.xx.21133068.0.29
MySQL192.168.xx.22133068.0.29
MySQL192.168.xx.23133068.0.29

服务器配置

条目配置
CPU48 C
内存96 G
硬盘SSD 820 G
JDK17.0.2

测试步骤 #

  1. 创建测试表。
mysql -utest -h192.168.xx.20 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc;

mysql -utest -h192.168.xx.21 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc;

mysql -utest -h192.168.xx.22 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc; 

mysql -utest -h192.168.xx.23 -P13306 -p

DROP DATABASE IF EXISTS test_tpcc;

CREATE DATABASE IF NOT EXISTS test_tpcc;
  1. 安装测试工具。
wget https://udomain.dl.sourceforge.net/project/benchmarksql/benchmarksql-5.0.zip
yum -y install ant
unzip benchmarksql-5.0.zip -d  /usr/local
cd /usr/local/benchmarksql-5.0
ant
cp mysql-connector-java-8.0.24.jar benchmarksql-5.0/run/lib

创建 props.proxy 文件。

db=postgres
driver=com.mysql.jdbc.Driver
conn=jdbc:mysql://192.168.xx.25:3307/sharding_db?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=8192&prepStmtCacheSqlLimit=8000
user=root
password=root
warehouses=200
loadWorkers=80
terminals=200
runTxnsPerTerminal=0
runMins=10
limitTxnsPerMin=0
terminalWarehouseFixed=true
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
shardingNumber=4
connBalance=192.168.xx.25:3333,192.168.xx.19:3333
  1. YAML
rules:
  - !SHARDING
    bindingTables:
      - bmsql_warehouse, bmsql_customer
      - bmsql_stock, bmsql_district, bmsql_order_line
    defaultDatabaseStrategy:
      none:
    defaultTableStrategy:
      none:
    keyGenerators:
      snowflake:
        type: SNOWFLAKE
    tables:
      bmsql_config:
        actualDataNodes: ds_0.bmsql_config

      bmsql_warehouse:
        actualDataNodes: ds_${0..3}.bmsql_warehouse
        databaseStrategy:
          standard:
            shardingColumn: w_id
            shardingAlgorithmName: mod_4

      bmsql_district:
        actualDataNodes: ds_${0..3}.bmsql_district
        databaseStrategy:
          standard:
            shardingColumn: d_w_id
            shardingAlgorithmName: mod_4

      bmsql_customer:
        actualDataNodes: ds_${0..3}.bmsql_customer
        databaseStrategy:
          standard:
            shardingColumn: c_w_id
            shardingAlgorithmName: mod_4

      bmsql_item:
        actualDataNodes: ds_${0..3}.bmsql_item
        databaseStrategy:
          standard:
            shardingColumn: i_id
            shardingAlgorithmName: mod_4

      bmsql_history:
        actualDataNodes: ds_${0..3}.bmsql_history
        databaseStrategy:
          standard:
            shardingColumn: h_w_id
            shardingAlgorithmName: mod_4

      bmsql_oorder:
        actualDataNodes: ds_${0..3}.bmsql_oorder
        databaseStrategy:
          standard:
            shardingColumn: o_w_id
            shardingAlgorithmName: mod_4

      bmsql_stock:
        actualDataNodes: ds_${0..3}.bmsql_stock
        databaseStrategy:
          standard:
            shardingColumn: s_w_id
            shardingAlgorithmName: mod_4

      bmsql_new_order:
        actualDataNodes: ds_${0..3}.bmsql_new_order
        databaseStrategy:
          standard:
            shardingColumn: no_w_id
            shardingAlgorithmName: mod_4

      bmsql_order_line:
        actualDataNodes: ds_${0..3}.bmsql_order_line
        databaseStrategy:
          standard:
            shardingColumn: ol_w_id
            shardingAlgorithmName: mod_4

    shardingAlgorithms:
      mod_4:
        type: MOD
        props:
          sharding-count: 4
  1. 数据准备。

数据库初始化，通过 Proxy 建表并插入数据。

cd /usr/local/benchmarksql/run

./runDatabaseDestroy.sh props.proxy

./runDatabaseBuild.sh props.proxy
  1. 压测阶段。
./runBenchmark.sh props.proxy

测试结果 #

测试对象tpmC存储节点 AVG(CPU Load)计算节点 AVG(CPU Load)
4 存储节点 + 1 DBPlusEngine-Proxy128,03512.5%98%
4 存储节点 + 2 DBPlusEngine-Proxy244,83728%78%

结论：在此场景下扩容计算节点可以近线性提升整体吞吐量。

监控信息 #

BenchmarkSQL ——> Proxy ——> MySQL(4) #

  • MySQL(1)

  • MySQL(2)

  • MySQL(3)

  • MySQL(4)

  • Proxy

BenchmarkSQL ——> Proxy(2) ——> MySQL(4) #

  • MySQL(1)

  • MySQL(2)

  • MySQL(3)

  • MySQL(4)

  • Proxy(1)

  • Proxy(2)

名词解释 #

warehouses：仓库数，决定数据量。

terminals：线程数。

runMins：测试执行时长。

tpmC：每分钟处理事务数。