测试方法

测试目的

广告RTA业务对广告主的技术要求较高，对于广告主来说，一方面需要满足媒体侧的快速响应要求，另一方面还要求数据存储成本可控。近年来，越来越多的RTA业务使用云数据库GeminiDB Redis做为KV特征库，性能与成本双赢。

本章节基于真实RTA业务做压力测试，评估GeminiDB Redis的数据压缩能力、QPS、带宽、时延等各项性能指标表现。

测试环境

本次测试使用的GeminiDB Redis集群规格和弹性云服务器（Elastic Cloud Server，简称ECS）规格如下：

• GeminiDB Redis规格

  局点	上海一
  可用区类型	可用区一/二/三混合部署
  节点CPU规格	16 vCPUs
  节点数量	20
  实例总容量	2 TB

• ECS规格：

  可用区类型	AZ1
  规格	c7.4xlarge.2，3台
  CPU	16vCPUs
  内存	32GiB
  操作系统	CentOS 8.2 64bit

测试工具

本次测试采用Redis Labs推出的多线程压测工具memtier_benchmark，具体使用方法请参见memtier_benchmark。

测试指标

本次模拟的广告业务场景（RTA）业务规模大致抽象为：1TB数据量、160w QPS、1.5Gbit/s带宽。

1. 数据样本

   本次测试使用的数据样本主要分为以下三种：

   类型	Key	Value
   Hash	34位字符	10对field(10位)-value(20-80位)
   String	68位字符	32位随机字符
   String	19位字符	500 – 2000位随机字符

   其中，需要存储在Redis中的Key总数约为40亿条。各类型数据占比约为2:7:1，高频访问的数据约占总体的50%。

2. 评估指标

   对于上述测试模型及场景，记录各数据库操作的如下测试指标：

   指标缩写	指标描述
   QPS	每秒执行的请求数，单位为次/秒。
   Avg Latency（ms）	请求的平均时延，代表GeminiDB Redis整体性能表现。
   P99 Latency（ms）	请求的P99时延，是比较严格的时延指标，表示99%的请求执行时间都小于该值。
   P9999 Latency(ms)	请求的P9999时延，是非常严格的时延指标，表示99.99%的请求执行时间小于该值，仅少量尾部请求超过该值。

测试步骤

1. 注入测试数据

   测试前，生成并注入数据库测试数据。基于测试模型三种类型的分布，对三种数据类型进行如下配置：

   1. hash类型
      • key：34位字符，使用字符串前缀+9位数字，数字由1亿-9亿连续，以控制数据总量和热数据分布。
      • field-value共注入10对，其中field为10位字符，value为20-80位随机字符，注入测试数据时取均值50位。
      • 构造并注入约8亿个key：

        memtier_benchmark -s ${ip} -a $(passwd} -p ${port} -c 20-t20 -n7500000 -d 32 -key-maximum=3
        800000000 -key-minimum =1000000000 --key-pr efix ='cefkljrithuir123894873h4523blj4b2jkjh2iw13b
        nfdhsbnkfhsdjkh' --key-pattern=P:P--ratio=1:0 -pipelire=100

   2. string类型
      • key：68位字符，使用字符串前缀+10位数字，数字由10亿-38亿连续，以控制数据总量和热数据分布。
      • value：注入32位随机字符。
      • 构造并注入约28亿个key：

        memtier_benchmark -s ${ip} -a ${passwd} -p ${port} -c 20 -t 20 -n 2500000 --command='hset __key__ mendke398d __data__ mebnejkehe __data__ fmebejdbnf __data__ j3i45u8923 __data__ j43245i908 __data__ jhiriu2349 __data__ 21021034ji __data__ jh23ui45j2 __data__ jiu5rj9234 __data__ j23io45u29 __data__' -d 50 --key-maximum=900000000 --key-minimum=100000000 --key-prefix='ewfdjkff43ksdh41fuihikucl' --command-key-pattern=P --pipeline=100

   3. string类型
      • key：19位字符，使用字符串前缀+9位数据，数字由1亿到3亿连续，以控制数据总量和热数据分布。
      • value：500 – 2000位随机字符，注入测试数据时取均值1250位。
      • 构造并注入约4亿个key：

        memtier_benchmark -s ${ip} -a ${passwd} -p ${port} -c 20 -t 20 -n 520000 -d 1250 --key-maximum=300000000 --key-minimum=100000000 --key-prefix='miqjkfdjiu' --key-pattern=P:P --ratio=1:0 --pipeline=100

   数据注入完成后，观察其key个数为3,809,940,889个key（约38亿）。观察GeminiDB Redis控制台中使用数据总量，计算GeminiDB Redis的数据压缩比。压缩后的存储容量约为155GB，即压缩比约为13.8%。

   

   • 受memtier_benchmark数据平铺时数据生成影响，生成数据在40亿条左右，各类型间数据分布不受影响。
   • memtier_benchmark工具构造随机字符串中连续字符较多，因此压缩比偏低。根据经验，实际生产数据压缩比一般在30%-50%左右，仍可以达到很好的压缩效果。
2. 压测命令

   在三台ECS上对GeminiDB Redis实例执行多个压测任务，压测任务分别为：

   1. ECS1上，对类型一进行hgetall查询操作，通过key范围控制仅访问部分高频数据：

      memtier_benchmark -s ${ip} -a ${passwd} -p ${port} -c 20 -t 30 --test-time 1200 --random-data --randomize --distinct-client-seed --command='hgetall __key__' --key-maximum=600000000 --key-minimum=200000000 --key-prefix='ewfdjkff43ksdh41fuihikucl' --out-file=./output_filename

   2. 对类型二进行get查询操作，通过key范围控制仅访问部分高频数据：

      memtier_benchmark -s ${ip} -a ${passwd} -p ${port} -c 70 -t 30 --test-time 1200 --random-data --randomize --distinct-client-seed --key-maximum=2400000000 --key-minimum=1000000000 --key-prefix='cefkljrithuin123894873h4523bhj4b2jkjh2iu13bnfdhsbnkfhsdjkh' --ratio=0:1 --out-file=./output_filename

   3. 对类型三进行get查询操作，通过key范围控制仅访问部分高频数据：

      memtier_benchmark -s ${ip} -a ${passwd} -p ${port} -c 10 -t 30 --test-time 1200 --random-data --randomize --distinct-client-seed --key-maximum=300000000 --key-minimum=100000000 --key-prefix='miqjkfdjiu' --ratio=0:1 --out-file=./output_filename

   其中，连接数(c、t两个参数乘积)通过调整各个压测实例的client数量及配置使整体达到160w QPS，同时读请求流量1.5Gb/s。保持该业务流量，评估GeminiDB Redis的性能表现。