# databench-a-c

**Repository Path**: caict-databench/databench-a-c

## Basic Information

- **Project Name**: databench-a-c
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-07-24
- **Last Updated**: 2024-02-21

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 分析型数据库稳定性测试

## 硬件环境

分析型数据库稳定性测试的硬件环境由中国信通院提供。测试人员需在中国信通院实验室机房使用指定的标准测试服务器集群进行测试，整个服务器集群不连接外网，内网通过一套千兆内网和一套万兆内网互相连接。测试共使用12台服务器，10台用于部署被测数据库，1台用于部署分析型数据库性能测试工具，1台用于部署分布式系统混沌测试工具。

## 测试用例概述

在进行稳定性测试时，要先进行一组基准实验。基准实验在不注入任何故障的情况下进行，模拟被测系统在生产环境中处于稳定状态的工作情况。通过基准实验可得出被测系统在无故障时的性能指标$E_0$。基准实验完毕后，开始进行故障实验。在进行故障实验时，需在运行与基准实验相同的压力测试的同时使用混沌测试工具对被测系统注入规定的故障，目的是测试被测系统在相应故障场景下的工作情况。被测系统在故障场景下完成压力测试后可得出被测系统在相应故障场景下的性能指标$E_i$。在完成所有故障场景测试用例后，应再进行一次在无故障环境下进行的性能测试，这次测试称为恢复性验证，可得出恢复性验证性能指标$E_{11}$。

## 基准实验

对于分析型数据库稳定性测试，应先对待测数据库进行一次在无故障环境下进行的性能测试，这次测试称为基准实验。基准实验使用分析型数据库性能测试工具进行。性能测试工具的部署和使用方式请参考《分析型数据库性能测试》和《分析型数据库性能测试工具》。基准实验可采用金融场景或电信场景，数据规模设置如下：

* 金融场景的数据规模设置为：$user\_basic=7500000$、$product\_basic=250$，数据量约5T

* 电信场景的数据规模设置为：$dwa\_d\_cus\_user\_info=95000000$，数据量约5T

上述列表中未提到的参数无需修改，维持初始值即可。能力测试中轮训次数设置为1次，吞吐量测试中并发度设置为5。

完成性能测试后，应记录测试工具展示的TPS测试结果，以该结果作为被测系统在无故障时的性能指标$E_0$。该指标的计算公式为：

${Performance}=\frac{\frac{Allocation}{Standard}\times{threadNum}\times{SQLFinishDegree}}{\sqrt[4]{{0.01}\times{L_{cost}}\times{\Sigma{P_{cost}}}\times{\Sigma{T_{cost}}}\times{\Sigma{B_{cost}}}}}$

* $\frac{Allocation}{Standard}$：配置数据规模与标准规模的比值

* $Standard$：表示数据规模的基准配置，以精准营销为例，若$user\_basic=30000000$、$product\_basic=1000$，则$Standard={30000000}\times{1000}$

* $Allocation$：与实际配置数据量相关，若$user\_basic=3000$、$product\_basic=10$，则$Allocation={3000}\times{10}$

* $threadNum$：代表并发并发测试的线程数量或客户端数量

* $SQLFinishDegree$：SQL完成度，在测试过程中超时执行或语法不兼容执行失败的SQL记为失败，同时根据并发数和轮询次数与SQL通过数乘积计算SQL总量

* $L_{cost}$：数据导入时间

* $\Sigma{P_{cost}}$：串行测试总时间

* $\Sigma{T_{cost}}$：并发测试总时间

* $\Sigma{B_{cost}}$：业务测试总时间

## 故障实验

分析型数据库稳定性测试共设置10个故障场景测试用例：

1. 扰动类别：CPU负载，扰动程度：99%，扰动节点数：4，扰动类型：计算

2. 扰动类别：硬盘空间填充，扰动程度：98%，扰动节点数：4，扰动类型：存储

3. 扰动类别：内存空间填充，扰动程度：98%，扰动节点数：4，扰动类型：存储

4. 扰动类别：读写高负载，扰动程度：区块重复读写>90%，扰动节点数：4，扰动类型：存储

5. 扰动类别：网络抖动（万兆网卡），扰动程度：200ms~800ms随机延迟，扰动节点数：4，扰动类型：网络

6. 扰动类别：网络丢包（万兆网卡），扰动程度：10%，扰动节点数：4，扰动类型：网络

7. 扰动类别：包损坏（万兆网卡），扰动程度：10%，扰动节点数：4，扰动类型：网络

8. 每隔60s，随机选取3项分别属于计算、存储、网络的扰动，分别注入到随机2个节点中

9. 每隔60s，随机选取3项分别属于计算、存储、网络的扰动，分别注入到随机4个节点中

10. 扰动类别：杀掉一主要线程，扰动节点数：1

每个测试用例的配置均为每隔60s注入一次故障，每次故障持续30s。

在执行分析型数据库稳定性测试时，应按顺序进行上述10个测试用例的测试。对于每个测试用例，应先正确配置分布式系统混沌测试工具的配置参数，配置方式详见《分布式系统混沌测试工具》中的说明。配置文件的配置方式可参考"chaostest"文件。

正确配置后，先运行混沌测试工具，观察到故障注入生效后，开始使用分析型数据库性能测试工具进行性能测试，数据规模和测试规模设置与基准实验相同。完成性能测试后，应记录测试工具展示的TPS测试结果，以该结果作为被测系统在故障场景下的性能指标$E_i$（$i$对应故障场景的测试用例编号，即$E_1$至$E_{10}$）。

记录性能指标并确认无误后，请移除该故障场景所注入的故障并确认性能测试工具停止工作，准备下一个故障场景的测试。

## 恢复性验证

在完成所有故障场景测试用例后，应再进行一次在无故障环境下进行的性能测试，这次测试称为恢复性验证。恢复性验证的数据规模和测试规模设置与基准实验相同。完成性能测试后，应记录测试工具展示的TPS测试结果，以该结果作为恢复性验证性能指标$E_{11}$。

## 测试用例合计

分析型数据库稳定性测试合计共12个测试用例：

0. 基准实验

1. CPU负载注入测试（扰动类别：CPU负载，扰动程度：99%，扰动节点数：4，扰动类型：计算）

2. 硬盘负载注入测试（扰动类别：硬盘空间填充，扰动程度：98%，扰动节点数：4，扰动类型：存储）

3. 内存负载注入测试（扰动类别：内存空间填充，扰动程度：98%，扰动节点数：4，扰动类型：存储）

4. 读写负载注入测试（扰动类别：读写高负载，扰动程度：区块重复读写>90%，扰动节点数：4，扰动类型：存储）

5. 网络抖动注入测试（扰动类别：网络抖动（万兆网卡），扰动程度：200ms~800ms随机延迟，扰动节点数：4，扰动类型：网络）

6. 网络丢包注入测试（扰动类别：网络丢包（万兆网卡），扰动程度：10%，扰动节点数：4，扰动类型：网络）

7. 网络包损坏注入测试（扰动类别：包损坏（万兆网卡），扰动程度：10%，扰动节点数：4，扰动类型：网络）

8. 低强度综合故障注入测试（每隔60s，随机选取3项分别属于计算、存储、网络的扰动，分别注入到随机2个节点中）

9. 高强度综合故障注入测试（每隔60s，随机选取3项分别属于计算、存储、网络的扰动，分别注入到随机4个节点中）

10. 单节点线程故障测试（扰动类别：杀掉一主要线程，扰动节点数：1）

11. 恢复性验证

## 测试流程

测试时间为7天。测试人员进入中国信通院实验室机房7*24小时后未完成所有测试用例则视为未通过测试。

测试人员进入机房后，需要在指定的服务器集群中选择规定数量的服务器并按照需要设置RAID、安装操作系统、部署测试工具和被测数据库。测试人员可自带笔记本电脑连接千兆内网进行操作。由于服务器集群不连接外网，且机房没有可连接外网的有线网络或WIFI网络，请测试人员提前准备测试需要的操作系统安装镜像和相关软件。推荐使用U盘安装操作系统。

被测数据库部署完成后，测试人员需对被测数据库的主界面或版本信息界面进行截图，填入检验报告中“检验样品照片”页。注意测试人员应在开始测试的当天或合理时间范围内进行截图，请留意图片上的时间信息。

本项测试需使用分析型数据库性能测试工具和测试工具和分布式系统混沌测试工具，测试工具的部署请参考《分析型数据库性能测试工具》和《分布式系统混沌测试工具》。被测数据库和测试工具部署完成后，需进行测试前审核以确认测试配置无误。测试前审核的具体要求可参考检验报告附件中“测试审核”部分，请按照要求操作并对操作结果进行截图填入相应位置。测试前审核结果无误后可执行测试用例的测试。测试审核部分填入的内容应为截图形式，不得直接复制粘贴代码或命令行界面输出的文字。

各测试用例的测试执行完毕后，需对测试工具展示的测试结果进行截图填入检验报告附件中“测试记录”部分。测试记录中填入的内容应为截图形式，不得直接复制粘贴测试工具输出的文字。

测试结果确认无误后，需将测试得出的各项指标的精确数值以文字的形式填入检验报告中“检验结果”页的相应位置。测试指标的计算方法详见《分布式数据库系统稳定性测试的基本测试过程和指标计算方法》。

性能指标为性能测试工具直接测得的平均TPS值，结果记为$E_0$到$E_{11}$。

RP指相对性能指标（Relative Performance），可反映被测系统的性能受故障影响的程度。数值越高说明故障对被测系统的影响越小。对于恢复性验证，这个指标反映了被测系统移除故障后的恢复能力（系统恢复率）。该指标记为$RP_1$到$RP_{11}$，计算公式为：

$RP_i=\frac{E_i}{E_0}$

* $RP_i$：第i组实验的相对性能指标
* $E_i$：第i组实验的性能指标
* $E_0$：基准实验的性能指标

CPU、存储、网络丢包、网络包损坏部分的测试用例需计算RCP指对性价比指标（Relative Cost Performance），可反映各实验组的系统性价比（单位时间、单位硬件资源所完成的工作总量）相对于基准实验组的变化情况。该数值越高说明系统对相应的故障的韧性越强。该指标记为$RCP_1$到$RCP_{11}$，可由系统性价比指标（CP）计算：

系统性价比指标由主要性能评估指标除以实验可用的硬件资源量得到。反映了单位时间，单位硬件资源所完成的工作总量：

基准实验组：

$CP_0=\frac{E_0}{NR}$

故障实验组：

$CP_i=\frac{E_i}{(N-{N_i}{P_i}{\Lambda})R}$

然后可计算相对性价比指标：

$RCP_i=\frac{CP_i}{CP_0}=\frac{E_iN}{E_0(N-{N_i}{P_i}{\Lambda})}$

* $RCP_i$：第$i$组实验的相对性价比指标
* $R$：各节点的系统资源总量
* $E_i$：第i组实验的性能指标
* $E_0$：基准实验的性能指标
* $N$：被测集群总节点数
* $N_i$：第i组实验注入故障的节点数
* $P_i$：第i组实验故障平均占用资源比率
* $\Lambda$：故障时间覆盖率（一般的故障实验中每分钟对节点注入一次持续30秒的故障，该值取${30s}/{60s}=0.5$）

## 测试终止条件

单项测试用例的测试中如出现以下状况，测试人员需考虑终止该项测试，该项的测试结果部分记录为“未完成”。

* 单项实验的运行时间过长，被测系统无能够正常完成压力测试的迹象
* 被测产品发生故障导致实验终止，重复2次后仍有发生
* 基础功能指标错误，重复2次后仍有发生