SERVICE | NODE TYPE | NODE COUNT |
Redis 7.2.5 | c7g.8xlarge | 1 |
DragonflyDB 1.21.2 | c7g.8xlarge | 1 |
晨章KV 0.7.4 | c7g.8xlarge | 1 |
Client - Memtier | c6gn.8xlarge | 1 |
我们按照官方文档配置晨章KV、DragonflyDB和Redis。
对于Redis，我们禁用了AOF和RDB的持久化功能。
redis-server --save "" --appendonly no
对于DragonflyDB，我们只需禁用检查点功能，因为它尚不支持日志记录。
dragonfly --dbfilename=
对于晨章KV，我们在config.ini文件中禁用了持久存储，并关闭了WAL（预写日志）功能。
# set it to off to turn off persistent storage
enable_data_store=off
# set it to off to turn off WAL
enable_wal=off
01. 写入负载测试
为了评估晨章KV的写入性能，我们使用memtier_benchmark以Put:Get 1:0的比例（仅写入）运行，配置如下：
memtier_benchmark -t $thread_num -c $client_num -s $server_ip -p $server_port --distinct-client-seed --ratio=1:0 --key-prefix="kv_" --key-minimum=1 --key-maximum=5000000 --random-data --data-size=128 --hide-histogram --test-time=300
- **-t**：线程数，固定设置为32。
- **-c**：每个线程的客户端数量。我们配置为4、8、16 和 32，以评估不同的并发级别。总的并发数分别为 128、256、512 和1024，计算方法为thread_num × client_num。
- **--ratio**：写读比率，对于纯写入负载设置为1:0。
结果
以下是写入专用负载的结果。
X轴：表示不同的并发级别（thread_num × client_num），模拟不同程度的并发数据库访问。
左Y轴：吞吐量，以KOPS（每秒查询数，单位千）表示。
右Y轴：99.9百分位延迟，以毫秒（ms）表示。
02. 只读负载测试
对于只读负载，我们调整memtier-benchmark的参数，将Put:Get比例设置为0:1。
memtier_benchmark -t $thread_num -c $client_num -s $server_ip -p $server_port --distinct-client-seed --ratio=0:1 --key-prefix="kv_" --key-minimum=1 --key-maximum=5000000 --random-data --data-size=128 --hide-histogram --test-time=300
结果
03. 混合负载测试
最后，我们测试了混合负载，设置为1:10 的Put:Get比率：
memtier_benchmark -t $thread_num -c $client_num -s $server_ip -p $server_port --distinct-client-seed --ratio=1:10 --key-prefix="kv_" --key-minimum=1 --key-maximum=5000000 --random-data --data-size=128 --hide-histogram --test-time=300
**--ratio**：设置为1:10，以进行混合写入-读取操作。
结果
晨章KV的吞吐量与DragonflyDB相似。随着并发性增加，晨章KV的P999延迟略高于DragonflyDB，但即使在超过一千个并发连接的情况下，延迟仍保持在4毫秒以下。
分析与结论
01. 单线程or多线程?
晨章KV和DragonflyDB在现代多核服务器上的性能显著优于单进程模型的Redis。这一差异源于Redis的基本设计理念。Redis将内存数据结构操作限制为单个工作线程，而多个I/O线程处理网络和持久性。这种选择虽然大大简化了Redis的设计，但自然限制了其在多核系统上的性能。相比之下，晨章KV和DragonflyDB都支持多个工作线程。
关于性能比较是否公平存在许多争论。比如，Redis在单个服务器节点上支持水平扩展，可以部署为具有多个实例/分片的集群。即使是单线程架构，仍然有优化空间，正如Valkey所展示的，后者推动了类似Redis的键值存储的性能（https://valkey.io/blog/unlock-one-million-rps）。
尽管如此，随着CPU核心数量的增加和查询工作负载的复杂化，我们认为单线程设计面临基本限制。即使Redis也在为某些查询探索多线程。Redis集群的行为与单服务器不同，需要特别关注键分区和负载均衡。我们将在下篇博客中讨论集群。
