一、数据库性能测试方法：

可以帮助发现性能瓶颈,并及时采取措施来优化数据库性能。

二、数据库处理数据的类型：

随着企业信息化的发展，数据量越来越庞大，对于数据分析和处理提出了更高的要求。在数据仓库中，联机分析处理（OLAP）和联机事务处理（OLTP）是常见的两种处理方式。

• 联机事务处理（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_common.lua是个公共模块，其它每个 lua 脚本都对应一个测试场景。

  

  4. 开通MySQL数据库实例：

  创建数据库实例后，并不能马上进行使用，需要大概等待6分钟左右才能进行使用。

  

  5. 开通TDSQL-C MySQL Serverless实例：

  创建数据库实例后，大概等待不到1分钟左右就能进行使用。

  

  所以，我们选择的TDSQL-C MySQL Serverless的CCU算力是Min为4，Max为8。

  

  对比MySQL与TDSQL-C MySQL Serverless基准测试的测试报告：

  command是 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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_test --table_size=25000 --tables=40 oltp_write_only prepare
  # 运行 workload
  sysbench --db-driver=mysql --mysql-host=rm-bp1i6ktwzqcs153neyo.mysql.rds.aliyuncs.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com --mysql-port=3306 --mysql-user=root_123 --mysql-password=Testdb@123 --mysql-db=tpcc_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.com -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/income_band.dat' INTO TABLE income_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	资源扩缩范围（CCU）	①. 可调整 CCU 弹性扩缩容的范围 ②. Serverless 集群会在该范围内根据实际业务压力自动增加或减少 CCU
          3	弹性策略	①. Serverless 集群会持续监控用户的 CPU、内存等 workload 负载情况，根据一定的规则触发自动扩缩容策略

          下面我们将针对这3个场景来测试一下数据库的特性。

          ---

          七、Serverless自动启停：

          您可根据业务需要，自助开启或关闭自动暂停设置。

          1. 如何会实现自动停止？

          • 1.开启状态下，需要设定自动暂停时间，默认为1小时。数据库在该时间内没有连接和 CPU 使用时，将自动暂停，暂停后计算不计费，存储仍然按实际使用量计费。

            

          • 2.可以在控制台根据实际视图模式对指定数据库进行手动暂停操作。

            

            2. 如何会实现自动启动？

            关闭状态下，数据库会保持持续运行，在没有连接和 CPU 使用时，按用户配置的最小 CCU 算力进行计费，适用于业务有心跳连接的应用场景。

            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。

                  下面来重点分析一下CCU的算力，由于最开始设置的算力区间是0.5 – 1，但是第一批次压测发现：

                  • 1.算力根本就不满足，监控到CCU的负载情况不足后，根据一定的规则触发自动扩缩容策略，马上秒级扩容到算力为4
                  • 2.CPU的使用率还不是很高峰值为18%左右

                    第二次压测发现：

                    • 1.CPU的使用率最高峰值为近40%左右
                    • 2.CCU算力还维持在4左右

                      第三次压测发现：

                      • 1.CPU的使用率最高峰值为近100%左右
                      • 2.CCU算力值最高自动扩缩容在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 服务的自动启停、弹性策略和资源扩缩范围（CCU）进行了实际的测试，Serverless 服务支持按实际计算和存储资源使用量收取费用，不用不付费，将腾讯云云原生技术普惠用户。而且，充分了利用了云计算的弹性能力。

                           
                           中国毕业设计论文网  合优网房产  江门企业免费建站  东莞建设网站  百度域名是什么  广州建站公司排名