最佳场景实践与压测 | 学习笔记

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介: 快速学习最佳场景实践与压测

开发者学堂课程【PolarDB for PostgreSQL 开源人才初级认证培训课程最佳场景实践与压测学习笔记,与课程紧密连接,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/1077/detail/15559


最佳场景实践与压测


内容介绍

一、TPC 背景介绍

二、TPC-C 介绍

三、TPC-H 介绍

四、TPC-H 测试报告

五、Pgbench 并发测试介绍

本节课介绍 PolarDB 压力测试的基本知识,介绍主要内容是什么是 TPC-C 测试和 TPC-H 测试,两个测试的分别针对什么样的业务;以及 pgbench 的并发测试。


一、TPC 背景介绍

1. 组织介绍

(1)TPC 组织:

TPC是第三方的组织,所以发布的一些测试的标准是受到公认的,这个组织位于美国,一共有四种测试方式:TPC-C、TPC-E、TPC-H、TPC-DS四种。前面两个是针对OLTP的业务,比如数据库针对OLTP应用的,如果数据库是支持数据仓库的,就采用这两种方式。

事务处理性能测试委员会TPC(Transaction process performance Council)是一个专门负责制定计算机事务处理能力测试标准并监督其执行的组织,其总部位于美国,针对数据库不同的使用场景TPC组织发布了多项测试标准,其中被业界广泛使用的有TPC-C、TPC-E,TPC-H和TPC-DS,前两者应用到OLTP,后两者应用到OLAP场景。

2.OLTP 与 OLAP 区别:

①OLP

联机事务处理OLTP(on-line transaction processing)主要是执行基本日常的事务处理,比如数据库记录的增删查改。比如在银行的一笔交易记录,就是一个典型的事务。高并发,高性能,且满足事务的ACID特性。

②OLAP

联机分析处理OLAP(On-Line Analytical Processing)是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。典型的应用就是复杂的动态的报表系统。对实时性要求不高,数据量大。

因为OLTP和OLAP的业务性质不一样,比如OLTP主要执行日常的事务处理,基本包括大量的增删改查,特点是高并发、高性能,虽然有很多事务,但是每个事务修改的量不大。

而OLAP就是典型的数据仓库的用法。支持复杂的查询,比如多表连接、涉及到聚集函数,查询出来的结果侧重于决策支持。特点是数据量特别大。

③OLTP和OLAP的比较

 

业务特点

SQL类型

常见TCP测试标准

OLTP

要求高并发,事务满足ACID特性

基本增删改查

TPC-C,TPC-E

OLAP

对实时性要求不高,数据量大

复杂分析操作

TPC-H,TPC-D5


二、TPC-C 介绍

接下来详细介绍TPC-C。

1.测试标准-OLTP

OLTP测试模型一直是TPC组织的重点测试标准,TPC-C测试模拟了一个比较复杂的OLTP应用环境是一个在线零售公司,此公司对10W种商品进行销售,TPC-E是对TPC-C升级版本,但是目前PO选型时普通使用的仍然是TPC-C标准,先简单介绍两个标准的差异。

 

TPC-C

TPC-E

业务模型

批发零售系统,订单处理

证券交易系统,覆盖股票交易所有业务

事务

5种事务

10种实时业务事务,2个批处理事务

9张表

33张表

92个字段

188个字段

数据类型

4大类型[num [整型,精度类型],[CHAR,DATE,LOB]]

10大类型[num[整形,精度类型],CHAR,DATE,BOOL,LOB等]

 

TPC-C 有两种测试方式,分别是TPC-C和TPC-E,区别在于难度不同,TPC-E实际上可以理解为是TPC-C的升级版本,其中测试的内容更加复杂,要求更高。TPC-C的业务模拟的是批发零售的业务,最主要的是订单的处理能力,比如数据库在这种高并发的业务量大的情况下。TPC-C的处理能力包括5种事务、9张表,最常见的数据类型是num、char、date、lob,由此可见的处理能力。我们可以经常看到不同的数据库厂商会出不同的报告,以此来表现数据库的处理能力。

TPC-E模拟的是证券交易系统,这种系统要求的实时性更好。包括10种实时业务事务和2个批处理事务。里面表的结构、数据类型更加丰富。所以选择不同的测试就要根据客户的一个要求去选择。

2.TPC-C 介绍

TPC-C模拟的是在线零售公司,假如一个仓库举例,仓库对10万种商品进行销售,具备针对用户进行水平扩展的能力,即建立更多的仓库。每个仓库负责10个区域,每个区域有单独的订单系统,每个区域管理3000个顾客,因此一个仓库负责3万个客户。树状图如下图,根据需要去选择。

3.TPC-C业务数据模型(续)

l TPC-C 业务涉及到的9张表以及ER图介绍:

1) ITEM 商品信息表:10w条商品信息,保持不变。

2) warehouse 仓库表:按需库容,比如上图表示有W个仓库,则有 W 条记录。

3) Stock 库存表:每个仓库有10W条商品的库存信息,因此总数目为 W*10w3) district 区域表:每个仓库管理10个区域,因此有W*10条记录。

5) custoer 客户表:每个仓库负责10个区域,每个区域管理3000个客户,因此客户数为 W*3w。

6 ) Order订单表:每次客户下单会生成一条记录,会持续增长,不删除,初始化为每个客户一条订单,因此初始值为W*3w。

7) New-Order新订单表:没有发货的订单,发货后即删除,初始值为每个仓库9000条记录,因此为W*9000。

8) order-line订单明细表:每个订单会购买5-15件商品(平均为10),对于每件商品都要记录到这里,因此它的数目约为Order的10倍,会持续增长,不删除,初始值为W*30w。

9) history表:历史信息表,没有主键,不需要查询,每次支付的时候生成一条记录,初始值为W*3w条。

其中最重要的是表是New-Orders表,此表会不断的进行更新,比如没有发货的订单,发完货会删除;新进来的订单会添加,初始值每个仓库9000条记录。还有一个Order总订单表,有新的客户就会有新的记录,此表会持续增长,不会删除,初始化为每个客户一条订单,所以初始值在乘以总仓库的数量,即W*3w。所以实际上是模拟零售系统,其中包括订单,订单中包含发货,发货中会涉及到交易信息。具体会到PolarDB终极认证时讲到TPC-C的部署实施的实现。

4. TPC-C 业务模型image.png

5. TPC-C测试报告

TPC-C测试的能力主要是每分钟的事务处理能力,主要针对New-Orders新订单表,考察一分钟处理事务的能力,这个数量越大,处理能力就越高。要注意TPC-C部署的时候,数据仓库的数量也会影响业务的复杂度,不仅是测试数据库的处理能力,也同时测试服务器的配置,业务量的多少。比如同样的硬件配置和业务量,10个仓库分别用oracle环境、pg环境和PolarDB环境测试测试每分钟的处理量,最终在相同的条件下,谁的数量越大说明处理能力越强,此时比较的就是数据库的能力。TPC-C测试完成后可以将字符的测试报告格式化为html的,会更具有可读性,如图:image.png


三、TPC-H 介绍

1. 测试标准-OLAP

随着开源 Hapdoop、Spark、HDFS、HBASE 等技术的商用化,大数据管理技术得到了突飞猛进的发展,为了更客观地比较不同数据管理系统,TPC组织牵头制定了大数据测试基准TPC-H, TPC-DS后者是 TPC 组织在TPC-H基础上的升级版木.下面介绍一下两者差异以及TPC-DS的SQL覆盖

 

TCP-H

TPC-D5

数据模型

关系模型

关系模型、星型模型、雪花模型

Sql标准

SQL92

SQL99,3..3,OLAP

数据对象

8张表

24张表,平均每张表含有18列

测试案例

22个

99个

TPC-H VS TPC-DS

接下来介绍TPC-H,TPC-H主要针对决策、系统数差等。TPC-H也提供两种测试,分别是TPC-H和更复杂的TPC-DS,TPC-DS包含子表达式、关联子查询、不相关联子查询、聚集、排序等,像这些都是在对数据进行分析常运用的语法。

SQL特征

查询数量

子表达式

31

关联子查询

15

不想关联子查询

76

groupby

78

Orderby

64

Rollup

9

partition

11

exists

5

union

17

Intersect

2

Minus

1

case

24

having

5

2. TPC-H 介绍

①测试标准-OLAP

TPC-H也是TPC-C出的一套标准的测试,它主要针对的是统计分析、数据挖掘、分析处理等决策支持方面,TPC-H模拟的数据库的模型,容量可以在1GB-10000GB的8个级别中进行选择,根据客户的业务量来决定,其中包括8张数据表。模拟商品零售业决策支持系统提供了22个常用的查询语句,包含分组、排序、聚集、子查询、多表关联等,通过这些可以测试各个查询响应的时间是否达到要求。

l TPC-H是事务处理性能委员会(Transaction ProcessingPerformance Council )制定的基准程序之一。

l TPC-H主要目的是评测数据库系统在统计分析、数据挖掘、分析处理等决策支持方面的能力。

l 该基准模拟了决策支持系统中的数据库操作,测试数据库系统复杂查询的响应时间,以每小时执行的查询数(TPC-H QphH@ Siz)作为度量指标。

l TPC-H基准模型中定义了一个数据库模型,容量可以在1GB~10000GB的8个级别中进行选择。数据库模型包括CUSTOMER、LINEITEM、NATION、ORDERS、PART、PARTSUPP、REGION和SUPPLIER 8张数据表。

l 模拟商品零售业决策支持系统的22个查询,涉及22条复杂的select查询流语句和2条带有insert和delete程序段的更新流语句。SQL涵盖了统计分组、排序、聚集操作、子查询、多表关联等复杂操作,可以测试各个查询的响应时间。

3. TPC-H Q1语句介绍

比如第一条Q1查询语句,查询的是lineltems表的一个定价总结报告。

在单个表lineitem上查询某个时间段内,对已经付款的、已经运送的等各类商品进行统计,包括业务量的计费、发货、折扣、税、平均价格等信息。

这个Q1语句的特点是带有分组、排序、聚集操作并存的单表查询操作,这个查询回访问表中95%-97%的行。查询语句根据业务量、复杂度和涉及到的数据量来判断处理的能力。

4.TPC-H Q2语句介绍

第二条Q2查询语句,查询的是最小代价供货商的查询。

Q2语句查询获得最小代价的供货商。得到给定的区域内,对于指定的零件(某一类型和大小的零件),哪个供应者能以最低的价格供应它,就可以选择哪个供应者来订货。

Q2语句特点是带有排序、聚集操作、子查询并存的多表查询操作。 

 

四、TPC-H 检测报告

TPC-H测试出来的结果如果是字符型看起来就较为简单,可以结合JeMeter工具,此工具可以将TPC-H测试出来的结果以图形的方式显示,将来用于报表更为方便,如图:

l 结合JeMeter产生测试报告

image.png

l Label:就是请求名称。

l #Samples:总线程数,值=线程数*循环次数。

l Average:单个请求的平均响应时间,值=总运行时间/发送到服务器的总请求数,单位是毫秒。

l Median、90%line、95%line、99%line分别代表50%、90%、95%、99%的用户响应时间,也就是有百分之多少的请求小于这个值。其中,90%line是性能测试中比较重要的一个衡量指标。

 

五、Pgbench 并发测试介绍

1.Pgbench 特点

下面讲解Pgbench并发测试,相比较之前的TPC-C和TPC-H都需要部署,部署起来需要安装软件,操作较为复杂,而Pgbench是自带测试器,不需要部署。Pgbench测试的是并发的压力测试工具,可以指定并发的数量。

①postgresql自带提供的一款轻量级的压力测试工具。

②可自行编写脚本,按自己的需求对数据库进行性能压力测试。

③可以自己编写针对pgbench的拓展工具,极大的增强了他的功能

2.Pgbench 优点

①系统自带,与postgresql兼容性好,而且配置方便;

②工具小,执行速度快;

③开源软件,可以在网上找到各种功能插件,让测试具有更大的复杂度

3.Pgbench 劣势

①测试的结果浮动比较大,比如同样的环境中,两次的结果相差较大,所以要多测几次结果,取平均值;

②一旦开始测试,无法中途停止,直至测试全部结束。

4.Pgbench 并发测试报告

Pgbench测试的指标是tps,根据客户的业务需求定制并发用户和执行实践,tps指每秒钟处理的事务量的多少,事务量越大能力越强。

总结以上介绍的,在PolarDB下,做压力测试可以用到的工具,PolarDB是基于pg进行开发的,所以对于pg原生态的插件全部支持。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
5月前
|
测试技术
性能场景之压测策略设计
【2月更文挑战第19天】性能场景之压测策略设计
542 4
性能场景之压测策略设计
|
消息中间件 监控 测试技术
消息队列和应用工具产品体系-性能测试场景和工具
消息队列和应用工具产品体系-性能测试场景和工具
消息队列和应用工具产品体系-性能测试场景和工具
|
11月前
|
消息中间件 弹性计算 Java
使用阿里云性能测试工具 JMeter 场景压测 RocketMQ 最佳实践
使用阿里云性能测试工具 JMeter 场景压测 RocketMQ 最佳实践
1234 6
|
3月前
|
测试技术
性能测试场景设计
**性能测试场景设计**涉及模拟用户行为和负载以评估系统在真实环境下的性能、稳定性和可靠性。常用的测试方法包括:**负载测试**,模拟实际使用以检查不同负载下的性能;**压力测试**,超负荷运行以检测系统极限;**稳定性测试**,验证系统长时间高负载的稳定性;**并发测试**,检查多用户访问时的性能和问题;以及**容量测试**,确定系统处理能力和资源利用率。测试场景多样,旨在确保系统应对未来增长需求的能力。
67 4
|
11月前
|
存储 测试技术 API
面对大促场景来临,如何从容进行性能测试
面对大促场景来临,如何从容进行性能测试
174 10
|
SQL 监控 测试技术
如何分析并设计性能测试场景
以上就是关于性能需求分析以及场景设计的内容,文中举的例子仅供参考,在实际的工作中,需要学会灵活变通。
如何分析并设计性能测试场景
EMQ
|
消息中间件 监控 网络协议
MQTT 性能测试入门:常见测试场景和指标
探讨常见的测试场景和用于评估MQTT Broker性能的关键指标。通过这些技术和见解,优化您的系统可靠性和物联网基础设施。
EMQ
519 0
MQTT 性能测试入门:常见测试场景和指标
|
供应链 Oracle 关系型数据库
|
SQL 关系型数据库 数据挖掘
PolarDB for PostgreSQL 开源必读手册-最佳场景实践与压测(下)
PolarDB for PostgreSQL 开源必读手册-最佳场景实践与压测
207 0
PolarDB for PostgreSQL 开源必读手册-最佳场景实践与压测(下)
|
运维 监控 安全
性能测试从零开始实施指南-场景模型篇
需求不明确导致无法对测试点&测试场景进行详尽完善的分析,最终的测试结果与实际需要的结果差距很大,无法对瓶颈定位和线上容量规划提供精确的参考;
性能测试从零开始实施指南-场景模型篇