PolarDB-X 1.0-性能白皮书-TPC-H测试说明

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 本文详细介绍了PolarDB-X的TPC-H测试设计、测试过程和测试结果。

TPC-H说明

TPC-H是业界常用的一套Benchmark,由TPC委员会制定发布,用于评测数据库的分析型查询能力。TPC-H查询包含8张数据表、22条复杂的SQL查询,大多数查询包含若干表Join、子查询和Group-by聚合等。


说明 本文的TPC-H的实现基于TPC-H的基准测试,并不能与已发布的TPC-H基准测试结果相比较,本文中的测试并不符合TPC-H基准测试的所有要求。

测试设计

  • 企业版测试环境:PolarDB-X计算资源DRDS实例企业版32C128G(单节点16C64G)、4台RDS MySQL 5.7实例(8C32G独享型)。
  • 标准版测试环境:PolarDB-X计算资源DRDS实例标准版16C64G(单节点8C32G)、4台RDS MySQL 5.7实例(4C32G 独享型)。

以下测试结果基于50G数据量(Scalar Factor = 50),其中主要表数据量如下:LINEITEM表约3亿行,ORDERS表7500万行,PARSUPP表4000万行。

以Q18为例,包含4张千万到亿级表的Join(含一个子查询SemiJoin)和Group-by聚合。在PolarDB-X计算资源DRDS实例上查询执行时间约11秒。


select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
from CUSTOMER, ORDERS, LINEITEM
where o_orderkey in (
        select l_orderkey
        from LINEITEM
        group by l_orderkey
        having sum(l_quantity) > 314
    )
    and c_custkey = o_custkey
    and o_orderkey = l_orderkey
group by c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice
order by o_totalprice desc, o_orderdate
limit 100;

测试过程


说明 以下测试过程依赖了LoadData功能做TPH数据导入,该功能要求内核版本>=5.4.7-16000638。

  1. 准备压力机ECS。这是以下所有操作的基础,准备数据、运行压测等都需在这台ECS上进行。说明
  • 建议选择VPC网络,经典网络有可能遇到RDS某些规格没有库存。请记录VPC的ID和名称,之后所有的实例和数据都部署在这个VPC里面。
  • 建议使用最新的Debian或者CentOS镜像,防止编译时缺少依赖库。
  1. 创建PolarDB-X计算资源DRDS实例以及相应的RDS实例,注意必须和上一步骤创建的ECS在同一个VPC中。
  2. 在PolarDB-X计算资源DRDS实例上创建库和表,注意要指定分库分表方式,建议使用以下表结构:
CREATE TABLE `customer` (
  `c_custkey` int(11) NOT NULL,
  `c_name` varchar(25) NOT NULL,
  `c_address` varchar(40) NOT NULL,
  `c_nationkey` int(11) NOT NULL,
  `c_phone` varchar(15) NOT NULL,
  `c_acctbal` decimal(15,2) NOT NULL,
  `c_mktsegment` varchar(10) NOT NULL,
  `c_comment` varchar(117) NOT NULL,
  PRIMARY KEY (`c_custkey`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 dbpartition by hash(`c_custkey`) tbpartition by hash(`c_custkey`) tbpartitions 4;
CREATE TABLE `lineitem` (
  `l_orderkey` bigint(20) NOT NULL,
  `l_partkey` int(11) NOT NULL,
  `l_suppkey` int(11) NOT NULL,
  `l_linenumber` bigint(20) NOT NULL,
  `l_quantity` decimal(15,2) NOT NULL,
  `l_extendedprice` decimal(15,2) NOT NULL,
  `l_discount` decimal(15,2) NOT NULL,
  `l_tax` decimal(15,2) NOT NULL,
  `l_returnflag` varchar(1) NOT NULL,
  `l_linestatus` varchar(1) NOT NULL,
  `l_shipdate` date NOT NULL,
  `l_commitdate` date NOT NULL,
  `l_receiptdate` date NOT NULL,
  `l_shipinstruct` varchar(25) NOT NULL,
  `l_shipmode` varchar(10) NOT NULL,
  `l_comment` varchar(44) NOT NULL,
  KEY `IDX_LINEITEM_PARTKEY` (`l_partkey`),
  PRIMARY KEY (`l_orderkey`,`l_linenumber`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 dbpartition by RIGHT_SHIFT(`l_orderkey`,6) tbpartition by RIGHT_SHIFT(`l_orderkey`,6) tbpartitions 4;
CREATE TABLE `orders` (
  `o_orderkey` bigint(20) NOT NULL,
  `o_custkey` int(11) NOT NULL,
  `o_orderstatus` varchar(1) NOT NULL,
  `o_totalprice` decimal(15,2) NOT NULL,
  `o_orderdate` date NOT NULL,
  `o_orderpriority` varchar(15) NOT NULL,
  `o_clerk` varchar(15) NOT NULL,
  `o_shippriority` bigint(20) NOT NULL,
  `o_comment` varchar(79) NOT NULL,
  PRIMARY KEY (`O_ORDERKEY`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 dbpartition by RIGHT_SHIFT(`O_ORDERKEY`,6) tbpartition by RIGHT_SHIFT(`O_ORDERKEY`,6) tbpartitions 4;
CREATE TABLE `part` (
  `p_partkey` int(11) NOT NULL,
  `p_name` varchar(55) NOT NULL,
  `p_mfgr` varchar(25) NOT NULL,
  `p_brand` varchar(10) NOT NULL,
  `p_type` varchar(25) NOT NULL,
  `p_size` int(11) NOT NULL,
  `p_container` varchar(10) NOT NULL,
  `p_retailprice` decimal(15,2) NOT NULL,
  `p_comment` varchar(23) NOT NULL,
  PRIMARY KEY (`p_partkey`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 dbpartition by hash(`p_partkey`) tbpartition by hash(`p_partkey`) tbpartitions 4;
CREATE TABLE `partsupp` (
  `ps_partkey` int(11) NOT NULL,
  `ps_suppkey` int(11) NOT NULL,
  `ps_availqty` int(11) NOT NULL,
  `ps_supplycost` decimal(15,2) NOT NULL,
  `ps_comment` varchar(199) NOT NULL,
  KEY `IDX_PARTSUPP_SUPPKEY` (`PS_SUPPKEY`),
  PRIMARY KEY (`ps_partkey`,`ps_suppkey`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 dbpartition by hash(`ps_partkey`) tbpartition by hash(`ps_partkey`) tbpartitions 4;
CREATE TABLE `supplier` (
  `s_suppkey` int(11) NOT NULL,
  `s_name` varchar(25) NOT NULL,
  `s_address` varchar(40) NOT NULL,
  `s_nationkey` int(11) NOT NULL,
  `s_phone` varchar(15) NOT NULL,
  `s_acctbal` decimal(15,2) NOT NULL,
  `s_comment` varchar(101) NOT NULL,
  PRIMARY KEY (`s_suppkey`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 dbpartition by hash(`s_suppkey`) tbpartition by hash(`s_suppkey`) tbpartitions 4;
CREATE TABLE `nation` (
  `n_nationkey` int(11) NOT NULL,
  `n_name` varchar(25) NOT NULL,
  `n_regionkey` int(11) NOT NULL,
  `n_comment` varchar(152) DEFAULT NULL,
  PRIMARY KEY (`n_nationkey`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 broadcast;
CREATE TABLE `region` (
  `r_regionkey` int(11) NOT NULL,
  `r_name` varchar(25) NOT NULL,
  `r_comment` varchar(152) DEFAULT NULL,
  PRIMARY KEY (`r_regionkey`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 broadcast;
  1. 准备导入数据到PolarDB-X计算资源DRDS实例。将脚本下载至压力机ECS上,下载链接:tpchData.zip
#解压tpchData.zip 脚本
unzip tpchData.zip
cd tpchData
#编辑conf文件
vim param.conf
  1. 将conf文件中最后一行的连接信息改成真实的连接信息。
#!/bin/bash
### remote generating directory
export remoteGenDir=./
### target path
export targetPath=../tpch/tpchRaw
export sourcePath=../tpch/tpchRaw
### cores per worker, default value is 1
export coresPerWorker=1
### threads per worker, default value is 1
export threadsPerWorker=1
export hint=""
###如果需要测试其他规模的数量级,比如100G的话,则数据库名换成tpch_100g
export insertMysql="mysql -hxxxxxxxxxx.drds.aliyuncs.com -P3306 -uxxx -pxxxxxx -Ac --local-infile tpch_50g -e"
  1. 生成50G的数据。
cd workloads
#编辑生成各个表数据的文件数量
cp tpch.workload.1.lst tpch.workload.50.lst
#进入上层目录datagen
cd datagen
#生成数据,这个步骤只需执行一次,后续如果有重复准备数据,可以不再重复执行
sh generateTPCH.sh 50
#将数据载入PolarDB-X计算资源DRDS实例
cd ../loadTpch
sh loadTpch.sh 50
  1. 验证数据正确性。
MySQL [tpch_5g]> select (select count(*) from customer) as customer_cnt,
    ->        (select count(*)  from lineitem) as lineitem_cnt,
    ->        (select count(*)  from nation) as nation_cnt,
    ->        (select count(*)  from orders) as order_cnt,
    ->        (select count(*) from part) as part_cnt,
    ->        (select count(*) from partsupp) as partsupp_cnt,
    ->        (select count(*) from region) as region_cnt,
    ->        (select count(*) from supplier) as supplier_cnt;
  1. 运行TPCH 测试前,使用 ANALYZE 命令采集统计信息。
analyze table customer;
analyze table lineitem;
analyze table nation;
analyze table orders;
analyze table part;
analyze table partsupp;
analyze table region;
analyze table supplier;
  1. 测试。
cd tpchData
cd runTpch
sh runTpch.sh
#运行结束进入result_fixed_mget,查看各条sql成绩
cd result_fixed_mget

测试结果


说明 PolarDB-X计算资源DRDS实例入门版不具备Parallel Query能力,不建议用于执行分析型查询。

drds-expansion1.png

Query 企业版(单位:秒) 标准版(单位:秒)
Q01 55.82 111.84
Q02 6.12 11.54
Q03 15.99 30
Q04 17.71 36.56
Q05 10.89 23.01
Q06 8.06 16.76
Q07 17.09 34.80
Q08 13.44 26.09
Q09 53.81 101.51
Q10 8.73 19.67
Q11 18.25 19.74
Q12 8.80 18.60
Q13 14.15 31.33
Q14 17.49 42.43
Q15 20.62 42.79
Q16 2.13 4.15
Q17 1.93 4.07
Q18 11.01 22.82
Q19 12.97 27.61
Q20 27.77 49.25
Q21 38.84 68.08
Q22 5.27 11.29
总计 386.77 754.65
相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
3月前
|
存储 缓存 调度
性能提升利器|PolarDB- X 超详细列存查询技术解读
本文将深入探讨 PolarDB-X 列存查询引擎的分层缓存解决方案,以及其在优化 ORC 列存查询性能中的关键作用。
380 24
|
6月前
|
存储 算法 Cloud Native
【PolarDB-X列存魔法】揭秘TPC-H测试背后的性能优化秘籍!
【8月更文挑战第25天】阿里巴巴的云原生数据库PolarDB-X以其出色的性能、可靠性和扩展性闻名,在多种业务场景中广泛应用。尤其在列存储模式下,PolarDB-X针对分析型查询进行了优化,显著提升了数据读取效率。本文通过TPC-H基准测试探讨PolarDB-X列存执行计划的优化策略,包括高效数据扫描、专用查询算法以及动态调整执行计划等功能,以满足复杂查询的需求并提高数据分析性能。
138 1
|
6月前
|
关系型数据库 MySQL 分布式数据库
Polardb mysql测试
polardb 初体验,效果明显
57 0
|
6月前
|
C# Windows IDE
WPF入门实战:零基础快速搭建第一个应用程序,让你的开发之旅更上一层楼!
【8月更文挑战第31天】在软件开发领域,WPF(Windows Presentation Foundation)是一种流行的图形界面技术,用于创建桌面应用程序。本文详细介绍如何快速搭建首个WPF应用,包括安装.NET Framework和Visual Studio、理解基础概念、创建新项目、设计界面、添加逻辑及运行调试等关键步骤,帮助初学者顺利入门并完成简单应用的开发。
212 0
|
7月前
|
监控 Oracle 关系型数据库
关系型数据库Oracle恢复测试
【7月更文挑战第20天】
117 7
|
9月前
|
关系型数据库 MySQL 数据库
测试部署PolarDB-X 分布式与集中式
在本文中,作者详述了在CentOS 7.9上部署测试PolarDB-X分布式与集中式数据库的过程。PolarDB-X作为阿里云优化的分布式数据库,提供高稳定性和与MySQL的兼容性,是应对单体数据库扩展性和性能瓶颈的解决方案,同时也符合国产化需求。文章介绍了部署环境准备,包括关闭防火墙和SELinux,设置系统参数,安装Python3和Docker,以及配置MySQL客户端。接着,通过PXD工具部署了PolarDB-X的集中式和分布式版,遇到的问题包括阿里云镜像源异常导致的部署失败以及指定版本安装的困扰。最后,作者进行了初步的压力测试,并对文档完善、生态工具建设以及提供更多使用案例提出了建议。
48044 10
测试部署PolarDB-X 分布式与集中式
|
8月前
|
关系型数据库 MySQL 分布式数据库
PolarDB测试
在CentOS 7.9环境下,作者探索实践了PolarDB-X的分布式与集中式部署,强调了PolarDB-X的稳定性和与MySQL的高兼容性。测试涵盖Anolis OS和openEuler系统,涉及PXD工具和Kubernetes部署。部署步骤包括环境调整、Python 3、Docker和MySQL客户端的安装。在集群部署中,遇到镜像源和版本匹配问题,通过PXD解决。总结中建议官方改进文档、丰富生态工具并提供更多案例,以促进其发展。这次体验展现了PolarDB-X的技术潜力和国产数据库的重要性。
560 4
|
8月前
|
关系型数据库 分布式数据库 数据库
PolarDB产品使用问题之如何解决测试连接时出现2003-Can't connect的问题
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
9月前
|
安全 druid Java
Seata 1.8.0 正式发布,支持达梦和 PolarDB-X 数据库
Seata 1.8.0 正式发布,支持达梦和 PolarDB-X 数据库
672 11
Seata 1.8.0 正式发布,支持达梦和 PolarDB-X 数据库
|
9月前
|
存储 DataWorks 监控
DataWorks,一个 polar db 有上万个数据库,解决方案
DataWorks,一个 polar db 有上万个数据库,解决方案

相关产品

  • 云原生分布式数据库 PolarDB-X