一、数据库性能测试方法:
可以帮助发现性能瓶颈,并及时采取措施来优化数据库性能。
序号 | 测试方法 | 描述 |
---|---|---|
1 | 基准测试(Benchmark Testing) | ①. 通过运行预定义的测试项目来测量数据库性能的方法 ②. 基准测试适用于比较不同数据库系统或不同硬件配置的性能 ③. 建议根据实际使用场景来选择最适合的基准测试工具,例如TPC-C、TPC-DS等 |
2 | 负载测试(Load Testing) | ①. 通过模拟实际业务场景下的访问量,来测试在高并发情况下的性能表现 ②. 可以使用压力测试工具,如JMeter等 |
3 | 实时监控(Real-time Monitoring) | ①. 可以使用实时监控工具来监控数据库的响应时间、CPU和内存使用情况、磁盘IO等性能指标 |
4 | 数据库执行计划(Execution Plan) | ①. 通过查看SQL语句的执行计划,确定查询的瓶颈在哪里 ②. 数据库自带的执行计划工具,如EXPLAIN命令 |
二、数据库处理数据的类型:
随着企业信息化的发展,数据量越来越庞大,对于数据分析和处理提出了更高的要求。在数据仓库中,联机分析处理(OLAP)和联机事务处理(OLTP)是常见的两种处理方式。
序号 | 技术指标 | OLTP | OLAP |
---|---|---|---|
1 | 应用类型 | 业务操作(应用) | 统计报表(分析) |
2 | 响应速度 | 快、短 | 一般 |
3 | 吞吐量 | 小 | 大 |
4 | 并发量 | 高 | 低 |
5 | 数据量规模 | 小 | 中大 |
6 | 场景 | 银行类、电子商务类的交易系统 | 数据仓库 |
- 联机事务处理(OLTP:On-line Transaction Processing),数据量少,DML频繁,并行事务处理多,但是要求处理时间短,一般用途或事务处理模板。
- 联机分析处理(OLAP:On-line Analytical Processing),数据量大,DML少,使用数据仓库模板。
数据仓库中的OLAP和OLTP是两种不同的数据处理方式,分别以数据分析和实时事务处理为核心。在实际应用中,我们针对不同的数据应用类型,可以选择不同的设计方案,以满足实际的业务需求。
三、基准测试中TPC-C、TPC-H、TPC-DS的区别:
序号 | 测试基准 | 数据应用类型 | 作用 | 测试工具 |
---|---|---|---|---|
1 | TPC-C | OLTP | ①. 用于在线事务处理(OLTP)数据库的性能测试 | sysbench测试工具就支持oltp测试 |
2 | TPC-H | OLAP | ①. 面向商品零售业的决策支持系统测试基准 ②. 定义了8张表,22个查询,遵循SQL92标准 |
http://TPC.org官方提供测试包 |
3 | TPC-DS | OLAP | ①. 数据仓库的表结构,采用星型、雪花型等多维数据模式 ②. 包含7张事实表,17张纬度表 ③. 与大数据的分析挖掘应用非常类似 ④. 测试案例都有很高的IO负载和CPU计算需求 |
http://TPC.org官方提供测试包 |
四、基准测试TPC-C压测:
1. 测试服务器型号:
2. 测试数据量:
40张表,每张表25000条记录,测试数据量为10.62G左右。
3. 安装sysbench:
Sysbench是一款基于LuaJIT的,模块化多线程基准测试工具,常用于数据库基准测试。
yum -y install epel-release
yum -y install sysbench
sysbench --version
压测脚本默认会安装在 /usr/share/sysbench 目录下,看看该目录的内容,除了oltp_***mon.lua是个公共模块,其它每个 lua 脚本都对应一个测试场景。
4. 开通MySQL数据库实例:
创建数据库实例后,并不能马上进行使用,需要大概等待6分钟左右才能进行使用。
5. 开通TDSQL-C MySQL Serverless实例:
创建数据库实例后,大概等待不到1分钟左右就能进行使用。
所以,我们选择的TDSQL-C MySQL Serverless的***U算力是Min为4,Max为8。
对比MySQL与TDSQL-C MySQL Serverless基准测试的测试报告:
***mand是 sysbench 要执行的命令,支持的选项有:prepare、run、cleanup
命令参数:
序号 | 选项 | 功能 |
---|---|---|
1 | prepare | ①. 生成压测数据 ②. 执行测试前的预备操作,如 创建文件、填充数据等 |
2 | run | 运行压测 |
3 | cleanup | 清理数据 |
1. 只写场景 - oltp_read_only:
# 准备数据
sysbench --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 oltp_write_only prepare
# 运行 workload
sysbench --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 --events=0 --time=30 --threads=500 --percentile=95 --report-interval=1 oltp_write_only run
# 清理数据
sysbench --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 oltp_write_only cleanup
测试结果对比:
压测数据结果解释:
序号 | 参数值 | 描述 | 对比 |
---|---|---|---|
1 | thds:500 | 500个线程在压测 | |
2 | tps:1611.38 | 每秒执行了1611.38个事务 | TDSQL强 |
3 | qps: 10924.90 | 每秒可以执行10924.90个请求 | TDSQL强 |
4 | (r/w/o: 0/7263.12/3661.79) | ①. 在每秒10924.90个请求中,对QPS进行了拆解 ②. 有0个请求是读请求 ③. 有7263.12个写请求 ④. 有3661.79个其他的请求 |
TDSQL强 |
5 | lat (ms, 95%): 325.98 | 95%的请求的延迟都在 97.55毫秒以下 | |
6 | err/s: 0.00 reconn/s: 0.00 | 每秒有0个请求是失败的,发生了0次网络重连 |
2. 只读(point select)场景 - oltp_read_only:
# 准备数据
sysbench --db-driver=mysql --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 oltp_read_only prepare
# 运行 workload
sysbench --db-driver=mysql --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 --events=0 --time=30 --threads=512 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=1 oltp_read_only run
# 清理数据
sysbench --db-driver=mysql --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 oltp_read_only cleanup
3. 只读(range select)场景 - oltp_read_only:
# 准备数据
sysbench --db-driver=mysql --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 oltp_read_only prepare
# 运行 workload
sysbench --db-driver=mysql --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 --events=0 --time=30 --threads=512 --percentile=95 --skip-trx=1 --report-interval=1 oltp_read_only run
# 清理数据
sysbench --db-driver=mysql --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.*** --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tp***_test --table_size=25000 --tables=40 oltp_read_only cleanup
4. 总结:
从上面测试的数据来看,可以看到大部分的场景下,压测的TDSQL-C MySQL Serverless的要比传统的MySQL的TPS和QPS要高一点,而且从CPU的的效率来看,也是节约了近一半的效率。
5. 遇到问题点:
执行报错“Can’t create more than max_prepared_stmt_count statements (current value:16382)”,经过查询默认值为16382,将值改大。
执行报错“unable to connect to MySQL server on host”,将max_connections值改大。
五、基准测试TPC-DS压测:
TPC-DS是一个面向决策支持系统(decision support system)的包含多维度常规应用模型的决策支持基准,包括查询(queries)与数据维护,此基准对被测系统(System Under Test’s, SUT)在决策支持系统层面上的表现进行的评估具有代表性。
此基准体现决策支持系统以下特性:
- 测试大规模数据
- 对实际商业问题进行解答
- 执行需求多样或复杂的查询(如临时查询,报告,迭代OLAP,数据挖掘)
- 以高CPU和IO负载为特征
- 通过数据库维护对OLTP数据库资源进行周期同步
- 解决大数据问题,如关系型数据库(RDBMS),或基于Hadoop/Spark的系统
- 基准结果用来测量,较为复杂的多用户决策中,单一用户模型下的查询响应时间,多用户模型下的查询吞吐量,以及数据维护表现。
1. TPC-DS的下载和编译:
下载地址
2. 创建数据库:
3. 创建表:
mysql -h gz-cynosdbmysql-grp-8zlf9ba7.sql.tencentcdb.*** -P 27124 -u root -p -D tpcds < ./tpcds.sql
4. 生成测试数据:
-SCALE 参数指定数据的大小,以G为单位
5. 生成导入数据的脚本:
LOAD DATA LOCAL INFILE '/tmp/11/call_center.dat' INTO TABLE call_center FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/customer.dat' INTO TABLE customer FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/in***e_band.dat' INTO TABLE in***e_band FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/ship_mode.dat' INTO TABLE ship_mode FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/warehouse.dat' INTO TABLE warehouse FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/catalog_page.dat' INTO TABLE catalog_page FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/customer_demographics.dat' INTO TABLE customer_demographics FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/inventory.dat' INTO TABLE inventory FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/store.dat' INTO TABLE store FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/web_page.dat' INTO TABLE web_page FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/catalog_returns.dat' INTO TABLE catalog_returns FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/date_dim.dat' INTO TABLE date_dim FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/item.dat' INTO TABLE item FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/store_returns.dat' INTO TABLE store_returns FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/web_returns.dat' INTO TABLE web_returns FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/catalog_sales.dat' INTO TABLE catalog_sales FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/dbgen_version.dat' INTO TABLE dbgen_version FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/promotion.dat' INTO TABLE promotion FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/store_sales.dat' INTO TABLE store_sales FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/web_sales.dat' INTO TABLE web_sales FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/customer_address.dat' INTO TABLE customer_address FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/household_demographics.dat' INTO TABLE household_demographics FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/reason.dat' INTO TABLE reason FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/time_dim.dat' INTO TABLE time_dim FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
LOAD DATA LOCAL INFILE '/tmp/11/web_site.dat' INTO TABLE web_site FIELDS TERMINATED BY '|' LINES TERMINATED BY '\n';
6. 对比MySQL与TDSQL-C MySQL Serverless基准测试的测试报告:
序号 | MySQL执行时间 | TDSQL执行时间 | 结果对比 |
---|---|---|---|
SQL3 | 73ms | 26 ms | 2.81倍 |
SQL 6 | 914520ms | 162820ms | 5.62倍 |
SQL 7 | 69830ms | 12673ms | 5.51倍 |
SQL 9 | 56670ms | 19113ms | 2.96倍 |
六、TDSQL-C MySQL Serverless优势:
TDSQL-C MySQL Serverless版(TDSQL-C for MySQL Serverless)是腾讯云自研的新一代云原生关系型数据库。
- 融合了传统数据库、云计算与新硬件技术的优势
- 为用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务
- TDSQL-C MySQL 版100%兼容 MySQL 5.7、8.0
- 实现超百万级 QPS 的高吞吐,最高 PB 级智能存储,保障数据安全可靠
1. Serverless 数据库:
Serverless数据库是一种基于Serverless架构的数据库服务,结合了云数据库和Serverless 两者的优势。
Serverless 数据库更加适用于 IoT 边缘计算、开发测试、无法预估负载等场景,这些场景平均负载比较低,资源大部分时间可能都是闲置的,使用Serverless后,可以节约大量成本,最高可节约 90%左右。
2. 与传统的云数据库相比,Serverless 数据库具有以下特点:
- 自动匹配资源:根据用户自身的业务负载,自动匹配相应的资源,无需用户预估业务规模,自动弹性扩容,充分了体现了云计算的优势。
- 按需付费:用户只需根据实际使用的资源付费,无需关心底层基础设施服务,实现了真正的按需付费,用多少,收多少。不用就不收费。
- 降低数据库选型难度:用户无需关心数据库选型,只需关心自身业务即可,而且完全兼容MySQL 5.7、8.0,迁移没有任何风险。
- 减轻DBA运维工作:Serverless数据库可以根据流量的峰值自动弹性伸缩资源,动态去调整配置,为业务运行提供强有力的后台保障,也在活动期间,大幅度的降低DBA的运维工作量。
3. Serverless 服务架构:
Serverless 服务是腾讯云自研的新一代云原生关系型数据库 TDSQL-C MySQL 版的无服务器架构版,是全 Serverless 架构的云原生数据库。Serverless 服务支持按实际计算和存储资源使用量收取费用,不用不付费,将腾讯云云原生技术普惠用户。
4. 适用场景:
- 低频数据库使用场景:如开发、测试环境使用云数据库、固定时间段使用业务(如12306晚间不能下单)
- 物联网(IoT)、边缘计算等不确定负载的场景
- 小程序云开发、中小企业建站等 SaaS 应用场景:相同的业务逻辑,不同的用户规模,不同用户的业务规模增长速度也不同
- 学校实验或教学环境等应用场景
- 全托管或希望完全免运维的用户
- 有不确定性、波动性、间歇性的业务场景
- 统一的数据平台:由于数据量可以支撑TB,给公司各部门或者各个产品、服务条线使用
5. Serverless服务特性:
TDSQL-C MySQL 版提供 Serverless 服务以满足企业对特定业务场景的数据库服务要求,助力企业降本增效,介绍 Serverless 服务的几大特性。
序号 | 特性项 | 说明 |
---|---|---|
1 | 自动启停 | ①. Serverless 服务支持自定义实例自动暂停时间,无连接时实例会自动暂停 ②. 当有任务连接接入时,实例会秒级无间断自动唤醒 |
2 | 资源扩缩范围(***U) | ①. 可调整 ***U 弹性扩缩容的范围 ②. Serverless 集群会在该范围内根据实际业务压力自动增加或减少 ***U |
3 | 弹性策略 | ①. Serverless 集群会持续监控用户的 CPU、内存等 workload 负载情况,根据一定的规则触发自动扩缩容策略 |
下面我们将针对这3个场景来测试一下数据库的特性。
七、Serverless自动启停:
您可根据业务需要,自助开启或关闭自动暂停设置。
1. 如何会实现自动停止?
- 1.开启状态下,需要设定自动暂停时间,默认为1小时。数据库在该时间内没有连接和 CPU 使用时,将自动暂停,暂停后计算不计费,存储仍然按实际使用量计费。
- 2.可以在控制台根据实际视图模式对指定数据库进行手动暂停操作。
2. 如何会实现自动启动?
关闭状态下,数据库会保持持续运行,在没有连接和 CPU 使用时,按用户配置的最小 ***U 算力进行计费,适用于业务有心跳连接的应用场景。
3. 实测自动启动时间:
写一个.sql的文件,里面是查看所有的表,使用Linux的time命令可以用来统计命令的执行时间。
- real表示实际执行时间是5.769s
- user表示系统CPU时间是0s
- sys表示用户CPU时间是0.016s
当然,这个实际时间也可能跟网速、存储数据量(我这里是近10TB数据)等因素相关,所以,只能根据实际的业务场景进行衡量。
八、Serverless 服务的弹性策略:
Serverless 服务的弹性策略是利用监控计算层实现的。通过监控业务负载情况,系统对计算资源进行自动扩缩容,并对该时刻所消耗的资源进行计费。
- 当没有数据库请求时,监控服务会触发计算资源的回收,并通知接入层。
- 当用户再次访问时,接入层则会唤醒集群,再次提供访问。
Serverless 服务的弹性策略一开始会根据用户购买时选择的容量范围,将 CPU、内存资源限制到最大规格,极大程度降低因 CPU 和内存扩容带来的时间影响和使用限制。
- 当集群触发到自动弹性的负载阈值后,Buffer pool 会根据监控提前进行分钟级调整。
- 在这个方案下用户使用数据库可以无感知进行 CPU 扩容,并且不会因为连接突增导致实例 OOM。
1. 开通测试使用的机器:
如下,为了方便的进行阶梯式的压测变化,开通了3台服务器,再加自己本地,一共4台设备进行阶段性压测,看一下服务的弹性策略变化。
2. 为了方便测试,将TDSQL-C MySQL服务器的算力配置调整成Min为0.5,Max为1。
3. 压测结果分析:
如下是4台设备进行压测的截图,分别为压测的进程Threads数为200、300、400、300,前面三台机器可以正常使用,到了第4台设备机器,资源不足,导致所有压测中断。
序号 | 机器标识 | Threads数 | 时间阶梯 | 结果 |
---|---|---|---|---|
1 | 第一台机器 | 200 | 第一批(间隔5min) | CPU负载在0-20左右 |
2 | 第二台机器 | 300 | 第二批(间隔5min) | CPU负载在20-60左右 |
3 | 第三台机器 | 400 | 第三批(间隔5min) | CPU负载在60-100左右 |
4 | 第四台机器 | 300 | 第四批(间隔5min) | 报错,导致所有脚本退出 |
以下是具体的性能监控图,我们来对比一下各个阶段的不同指标有什么变化。
内存的使用量和使用率在三个周期中,也是发生了递归上升的变化。内存最大使用率为91.76%,内存最大使用量约6G。
下面来重点分析一下***U的算力,由于最开始设置的算力区间是0.5 – 1,但是第一批次压测发现:
- 1.算力根本就不满足,监控到***U的负载情况不足后,根据一定的规则触发自动扩缩容策略,马上秒级扩容到算力为4
- 2.CPU的使用率还不是很高峰值为18%左右
第二次压测发现:
- 1.CPU的使用率最高峰值为近40%左右
- 2.***U算力还维持在4左右
第三次压测发现:
- 1.CPU的使用率最高峰值为近100%左右
- 2.***U算力值最高自动扩缩容在4.575左右
第四次压测发现:
- 1.由于资源不足,导致所有sysbench脚本全部退出
- 2.CPU、内存、CUU等又跌回到原来的0左右
以下为CPU、内存、InnoDB Buffer Pool Pages、InnoDB Row Operations等参数的变化图。
九、数据库执行计划:
execution plan主要负责生成执行计划的组件就是优化器,优化器利用表结构、字段、索引、查询条件、数据库的统计信息和配置参数决定 SQL 语句的最佳执行方式。如果想要解决慢查询的性能问题,首先应该查看它的执行计划。
可以分析如下SQL语句中,在store_sales这张表中,是进行了扫表的操作,大概扫了3190062行数据,可以进行一些索引的优化、或者语句的优化,防止产生慢查询,拖垮数据库的性能。
十、总结:
伴随着云原生概念的迅速发展,未来 Serverless 的数据库服务对中小用户还是很有吸引力的,因为 Serverless 模式大大简化了数据库运维管理工作,用户的 DBA 的工作负担大幅降低,可以专注于查询性能优化,Serverless 服务状态监控,数据访问控制机制管理等工作。用户的数据库使用成本也会相应大幅降低。
从性能也有很大的提升,事务内路由优化,大幅降低事务整体执行延迟,TP业务分布式事务较多的场景,可大幅降低整个事务的整体执行延迟,TP性能显著提升,4核小规格部署环境下,sysbench综合读写能力相比提升最高40%。
同时,也对Serverless 服务的自动启停、弹性策略和资源扩缩范围(***U)进行了实际的测试,Serverless 服务支持按实际计算和存储资源使用量收取费用,不用不付费,将腾讯云云原生技术普惠用户。而且,充分了利用了云计算的弹性能力。