KeeWiDB性能压测

原创邓亚运三七互娱技术团队

背景：

1. 当前数据部存在较多的pika服务是采用cvm自建，由于pika这个产品官方许久没有维护，加上一致的想法是能尽量全部使用云产品，故需要有新的产品能够替换pika。同时需要低成本。

2. 当前数据部广告投放采用redis cluster集群，成本居高不下，也急需新产品能够替换redis cluster，达到节约成本的目的。

基于上述2点，测试腾讯云新的产品：KeeWiDB

官网介绍：https://cloud.tencent.com/document/product/1520

云数据库 KeeWiDB（TencentDB for KeeWiDB，KeeWiDB）是腾讯云自研的兼容 Redis 协议的分布式 KV 数据库，使用持久化内存技术，拥有亚毫秒级的响应延迟、数百Gb/s的吞吐、冷热数据分级存储，100TB级的存储规模，数据持久化、高性能读写，可广泛应用于低成本大容量 KV 存储、缓存 + 存储方案的替换、实时高性能存储等多种业务场景，助力企业提升生产效率，降低运营成本。

什么是云数据库 KeeWiDB

开源 Redis 使用内存存储介质，能够在计算和缓存场景提供超高并发和超低延迟。然而 Redis 的使用场景早已经突破了缓存的边界，在存储场景中的应用越来越多。Redis 作为存储数据库，面临海量数据和极致用户体验的双重挑战，为彻底解决 Redis 在存储场景所面临的性能、成本、持久化、规模限制等方面存在的问题，腾讯云研发了兼容 Redis 协议的 KV（key-value）存储数据库 KeeWiDB。

云数据库 KeeWiDB（TencentDB for KeeWiDB，KeeWiDB）是腾讯云自研的兼容 Redis 协议的分布式 KV 数据库，使用持久化内存技术，拥有亚毫秒级的响应延迟、数百Gb/s的吞吐、冷热数据分级存储，100TB级的存储规模，数据持久化、高性能读写，可广泛应用于低成本大容量 KV 存储、缓存 + 存储方案的替换、实时高性能存储等多种业务场景，助力企业提升生产效率，降低运营成本。

为什么选择云数据库 KeeWiDB

云数据库 KeeWiDB 在简单易用、持久化存储、大容量、低成本、弹性扩容、数据可靠性、高性能、智能监控等方面均体现出自己独有的优势

压测环境：

施压机：24核98G

压测工具：

YCSB，https://github.com/brianfrankcooper/YCSB

工作负载

各个数据类型2千万。数据分布方法为zipfian，具体测试场景如下：

Load：100%的写操作。
Workload C：100%的读操作。
Workload A：50%的更新操作与50%的读操作。

测试命令

workload=a./bin/ycsb load redis -s -P workloads/workload${workload} -p "redis.host=${server_ip}" -p "redis.port=${port}" -p "redis.password=${password}" -p "recordcount=${recordcount}" -p "operationcount=${operationcount}" -p "redis.timeout=30000" -p "redis.command_group=${command_group}" -p "fieldcount=${fieldcount}" -p "fieldlength=${fieldlength}" -threads ${threads} -p "redis.password=$password"
#运行Workload C#workload=c./bin/ycsb run redis -s -P workloads/workload${workload} -p "redis.host=${server_ip}" -p "redis.port=${port}" -p "redis.password=${password}" -p "recordcount=${recordcount}" -p "operationcount=${operationcount}" -p "redis.timeout=30000" -p "redis.command_group=${command_group}" -p "fieldcount=${fieldcount}" -p "fieldlength=${fieldlength}" -threads ${threads} -p "redis.password=$password"
#运行Workload A#workload=a./bin/ycsb run redis -s -P workloads/workload${workload} -p "redis.host=${server_ip}" -p "redis.port=${port}" -p "redis.password=${password}" -p "recordcount=${recordcount}" -p "operationcount=${operationcount}" -p "redis.timeout=30000" -p "redis.command_group=${command_group}" -p "fieldcount=${fieldcount}" -p "fieldlength=${fieldlength}" -threads ${threads} -p "redis.password=$password"

重要参数说明：

recordcount: 数据装载阶段准备的数据量。
operationcount: 执行操作的数据量。
command_group: 测试的数据结构，string，hash，set，zset
fieldcount：字段或元素个数，本案例中，String数据结构配置为1，其他数据结构配置为10。
fieldlength：值长度，根据测试需求配置
threads：YCSB线程数，统一 128个并发。

测试结果

测试指标

Load场景测试结果(纯写)

1. String数据结构

Value长度（字节）	QP （次/秒）	INSERT Average Latency（微秒）	INSERT 99th Percentile Latency（微秒）
128	127170	977	3833
256	118832	1060	4219
1024	97028	1302	6067

Value长度（字节）

（次/秒）

INSERT Average Latency（微秒）

INSERT 99th Percentile Latency（微秒）

128

127170

977

3833

256

118832

1060

4219

1024

97028

1302

6067

2. Hash数据结构

Key中的Field数量	Value长度（字节）	QPS（次/秒）	INSERT Average Latency（微秒）	INSERT 99th Percentile Latency（微秒）
10	128	76480	1650	7991
10	256	60679	2080	10935
10	1024	14110	8855	31439

3. Set数据结构

Key中的Member数量	Value长度（字节）	QPS（次/秒）	INSERT Average Latency（微秒）	INSERT 99th Percentile Latency（微秒）
10	128	76372	1644	8383
10	256	52076	2415	10567
10	1024	10837	11749	40447

4. Sorted Set数据结构

Key中的Element数量	Value长度（字节）	QPS（次/秒）	INSERT Average Latency（微秒）	INSERT 99th Percentile Latency（微秒）
10	128	46864	1349	6135
10	256	24776	5131	22543
10	1024	19495	7234	28651

Workload C场景测试结果(100%的读操作)

1. String数据结构

Value长度（字节）	QPS（次/秒）	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒）
128	149120	828	3651
256	148596	846	3695
1024	138025	897	4151

2. Hash数据结构

Key中的Field数量	Value长度（字节）	QPS（次/秒）	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒）
10	128	120358	924	3895
10	256	68533	1447	4035
10	1024	19233	5508	8423

3. Set数据结构

Key中的Member数量	Value长度（字节）	QPS（次/秒）	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒）
10	128	112195	905	3785
10	256	38298	2174	4069
10	1024	11234	7985	14407

4. Sorted Set数据结构

Key中的Element数量	Value长度（字节）	QPS（次/秒）	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒
10	128	65145	1544	6291
10	256	27691	3217	8751
10	1024	12310	2267	9865

Workload A场景测试结果(50%的更新操作与50%的读操作)

1. String数据结构

Value长度（字节）	QPS（次/秒）	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒）	UPDATE AverageLatency（微秒）	UPDATE 99thPercentileLatency（微秒）
128	128344	952	4699	977	4775
256	124091	999	5103	1032	5187
1024	101453	1201	8075	1264	8407

2. Hash数据结构

Key中的Field数量	Value长度（字节）	QPS（次/秒）	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒）	UPDATE AverageLatency（微秒）	UPDATE 99thPercentileLatency（微秒）
10	128	108471	1146	6211	1176	6371
10	256	94357	1246	7707	1424	7995
10	1024	38479	3055	11007	2334	9327

3. Set数据结构

Key中的Member数量	Value长度（字节）	QPS（次/秒）	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒）	UPDATE AverageLatency（微秒）	UPDATE 99thPercentileLatency（微秒）
10	128	118021	906	3654	1126	4728
10	256	42301	2236	4762	2263	5751
10	1024	22805	2267	5785	3367	6782

4. Sorted Set数据结构

Key中的Element数量	Value长度（字节）	QPS（次/秒	READ AverageLatency（微秒）	READ 99thPercentileLatency（微秒）	UPDATE AverageLatency（微秒）	UPDATE 99thPercentileLatency（微秒）
10	128	56507	1751	10439	2729	12975
10	256	48253	2292	11647	2954	13055
10	1024	26891	3361	18769	3363	23098

总结：

1. 对于string类型性能最好，在value 128字节左右的时候QPS可以跑到12w。
2. 对于大value，比如1024字节长度写入触发入流量限流，导致性能较差。瓶颈在带宽。询问腾讯答复暂时不会放开限制。当前网络最大吞吐：1920Mb/s
3. cpu没有瓶颈，其余的数据类型性能没有string好猜测和底层实现有关系。

流量限流：

继续滑动看下一个