Performance Evaluation of Tencent Cloud KeeWiDB Using YCSB Workloads

Background: The data department currently uses self‑built Pika services on CVM and a Redis cluster for ad‑placement, both incurring high costs. They seek a low‑cost cloud alternative.

Tencent Cloud’s KeeWiDB (TencentDB for KeeWiDB) is a self‑developed distributed KV database compatible with the Redis protocol, leveraging persistent memory to achieve sub‑millisecond latency, hundreds of Gb/s throughput, hierarchical storage, and up to 100 TB capacity.

Test environment: Load generator – 24 CPU cores, 98 GB RAM; benchmark tool – YCSB (https://github.com/brianfrankcooper/YCSB). Workloads: Load (100 % writes), Workload C (100 % reads), Workload A (50 % reads, 50 % updates). Each workload uses 20 million keys with a Zipfian distribution. The YCSB commands used are:

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"
#run 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"
#run 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"

Important parameters: recordcount (data size), operationcount (number of operations), command_group (data structure: string, hash, set, zset), fieldcount, fieldlength, threads (fixed at 128 concurrent threads).

Results: Detailed tables show QPS, average latency, and 99th‑percentile latency for four data structures (String, Hash, Set, Sorted Set) under each workload and for three value sizes (128 B, 256 B, 1024 B). Key observations include:

String type delivers the highest throughput; with 128 B values it reaches ~149 k QPS in pure‑read (Workload C) and ~127 k QPS in pure‑write (Load).

Increasing value size to 1024 B reduces QPS dramatically (e.g., ~12 k QPS for writes), indicating bandwidth‑limited throttling.

Other data structures (Hash, Set, Sorted Set) achieve lower QPS than String, likely due to implementation overhead.

CPU is not a bottleneck; the observed limits stem from network bandwidth (max 1920 Mb/s) and Tencent’s traffic‑shaping policies.

Conclusion: KeeWiDB provides low‑cost, high‑performance KV storage compatible with Redis. It excels in scenarios with small values and read‑heavy workloads, while large values encounter throttling constraints.