The rise of distributed applications and cloud computing has created a demand for scalable, high-performance key-value storage systems. This paper presents a performance evaluation of three prominent NoSQL key-value stores: Redis, Aerospike, and Dragonfly, using the Yahoo! Cloud Serving Benchmark (YCSB) framework. We conducted extensive experiments across three distinct workload patterns (read-heavy, write-heavy), and balanced while systematically varying client concurrency from 1 to 32 clients. Our evaluation methodology captures both latency, throughput, and memory characteristics under realistic operational conditions, providing insights into the performance trade-offs and scalability behaviour of each system
academic- 论文ID: 2510.08863
- 标题: Comparative Performance Analysis of Modern NoSQL Data Technologies: Redis, Aerospike, and Dragonfly
- 作者: Deep Bodra (Harrisburg University of Science and Technology), Sushil Khairnar (Virginia Tech)
- 分类: cs.DB cs.DC
- 发表期刊: Journal of Research, Innovation and Technologies, Volume IV, Issue 2(8), 2025
- 论文链接: https://doi.org/10.57017/jorit.v4.2(8).05
随着分布式应用和云计算的兴起,对可扩展、高性能键值存储系统的需求日益增长。本文使用Yahoo! Cloud Serving Benchmark (YCSB)框架对三个主要的NoSQL键值存储系统进行了性能评估:Redis、Aerospike和Dragonfly。研究在三种不同的工作负载模式(读密集型、写密集型和平衡型)下进行了广泛实验,系统地将客户端并发数从1个变化到32个。评估方法在现实操作条件下捕获了延迟、吞吐量和内存特性,为每个系统的性能权衡和可扩展性行为提供了深入洞察。
- 现代应用需求挑战:现代数字环境涉及大量数据创建和使用,Web应用、移动技术和物联网设备的快速扩展对数据库系统提出了新的挑战
- 传统数据库局限性:传统关系型数据库管理系统虽然功能强大,但在满足现代应用的性能和可扩展性要求方面存在困难,特别是需要亚毫秒响应时间和每秒处理数百万操作的应用
- NoSQL数据库的崛起:NoSQL数据库,特别是键值存储,通过强调性能和可扩展性来克服这些挑战
- 实用价值:为系统架构师选择合适的键值存储解决方案提供实用指导
- 学术价值:填补了对Redis、Aerospike和Dragonfly系统性比较评估的空白
- 技术价值:通过不同工作负载模式和并发级别的系统性评估,揭示各系统的性能特征
虽然这些系统被广泛使用,但缺乏系统性评估其在各种工作负载模式和并发级别下性能特征的全面比较研究。
- 全面的性能比较:提供了包括延迟和吞吐量指标的完整性能比较分析
- 内存消耗特性分析:深入分析了三个系统的内存使用模式和效率
- 多工作负载评估:在读密集型、写密集型和平衡型三种工作负载下进行系统评估
- 可扩展性分析:通过1-32个并发客户端的测试揭示各系统的扩展特性
- 实用指导:为系统架构师选择合适的键值存储解决方案提供实际指导
Redis:
- 开源的内存数据结构存储,2009年开发
- 单线程架构,消除复杂锁机制但限制多核系统扩展性
- 支持多种数据结构:字符串、哈希、列表、集合、有序集合等
- 通过定期快照或仅追加文件实现持久化
Aerospike:
- 分布式NoSQL数据库,2009年创立
- 混合内存架构:DRAM存储索引,SSD存储数据
- 无共享架构,每个节点独立操作
- 提供强一致性和自动故障转移功能
Dragonfly:
- 2022年推出的内存数据存储,作为Redis的直接替代
- 多线程、无共享架构,可利用多CPU核心
- 与Redis协议兼容
- 实现复杂的内存管理和无锁数据结构
硬件环境:
- 系统:Mac OS with Apple M3 Pro chip
- 配置:12核心,36GB RAM,macOS Sequoia
- 部署:使用Docker容器确保一致和隔离的环境
基准测试框架:
- 使用Yahoo! Cloud Serving Benchmark (YCSB)
- 两阶段方法:加载阶段填充初始数据,运行阶段执行基准操作
- 并发级别:1、2、4、8、16、32个客户端
- 键选择分布:Zipfian分布,模拟真实的非均匀访问模式
读密集型工作负载:
- 95%读取,5%更新操作
- 每条记录1KB数据(10个字段,每个100字节)
- 加载1,474,560条记录
- 模拟缓存场景、内容分发系统等
平衡型工作负载:
- 50%读取,50%更新操作
- 相同的1KB记录结构
- 代表社交媒体平台、协作应用等混合访问模式
写密集型工作负载:
- 10%读取,90%插入操作
- 时间序列数据,64个字段,每个字段8字符
- 运行阶段执行2,949,120次插入操作
- 模拟IoT应用、监控系统等高吞吐量数据摄取场景
Aerospike表现最优:
- P99延迟:436ms(单客户端)到2,979ms(32客户端)
- 吞吐量:3,348 ops/s到32,592 ops/s
- 性能优势源于混合内存架构和无共享设计
Redis表现中等:
- P99延迟:862ms到4,447ms
- 吞吐量:1,656到17,158 ops/s
- 单线程架构成为高并发下的性能瓶颈
Dragonfly延迟最高:
- P99延迟:1,137ms到4,883ms
- 吞吐量:1,371到16,328 ops/s
- 多线程协调开销抵消了并行处理优势
性能层次保持一致:
- Aerospike:P99延迟441ms-2,409ms,吞吐量3,372-33,741 ops/s
- Redis:P99延迟874ms-4,017ms,吞吐量1,664-17,004 ops/s
- Dragonfly:P99延迟1,187ms-4,631ms,吞吐量1,278-16,497 ops/s
所有系统表现最佳:
- Aerospike:P99延迟410ms-2,233ms,吞吐量3,562-34,896 ops/s
- Redis:P99延迟808ms-3,547ms,吞吐量1,757-17,170 ops/s
- Dragonfly:P99延迟1,124ms-3,859ms,吞吐量1,331-16,925 ops/s
| 系统 | 运行前(MB) | 运行后(MB) | 增长倍数 |
|---|
| Redis | 36.32 | 2610 | 72x |
| Aerospike | 232.1 | 772.3 | 3.3x |
| Dragonfly | 58.98 | 2350 | 40x |
关键发现:
- Aerospike内存效率最高,得益于混合存储模型
- Redis内存开销最大,反映单节点内存存储的局限性
- Dragonfly介于两者之间,多线程协调结构带来额外开销
吞吐量扩展特性:
- Aerospike:近线性扩展,9-10x提升
- Redis:10-11x提升,但延迟增长更显著
- Dragonfly:12-13x提升,基线性能较低
论文引用了多项相关研究:
- 基准测试框架:Cooper et al. (2010) 的YCSB框架奠定了云服务系统基准测试基础
- NoSQL比较研究:Anthony & Rao的键值存储实证比较
- 系统特定研究:Volminger (2021) 的Aerospike研究,Charan et al. 的Redis分析
- 最新发展:Mohan et al. (2024) 的OLAP工作负载NoSQL评估
- Aerospike综合领先:在所有工作负载和并发级别下表现最优,具有最佳的吞吐量扩展性和相对较低的延迟
- Redis稳定可靠:在所有工作负载模式下表现稳定可预测,但受单线程架构限制
- Dragonfly潜力与挑战并存:尽管设计现代,但延迟表现不佳,在写密集型场景下显示潜力
- 工作负载影响显著:所有数据库在写密集型条件下表现最佳
- 最大性能需求:选择Aerospike
- 操作简单性优先:Redis足够满足需求
- Redis兼容性需求:Dragonfly是有趣选择,但需仔细评估延迟敏感应用
- 单机测试环境:所有测试在单台机器上进行,未能充分体现分布式系统优势
- 有限的网络条件:未考虑网络延迟和分区对性能的影响
- 数据分布单一:仅使用Zipfian分布,实际应用可能有不同模式
- 集群模式缺失:未测试真实的分布式部署场景
- 生产环境测试:在真实生产条件下评估系统性能
- 分布式场景:测试集群模式下的真实分布式可扩展性
- 一致性模型研究:CAP定理对各系统设计的影响
- 故障容错机制:节点故障期间的容错机制评估
- 跨数据中心复制:网络分区下的数据一致性和复制延迟
- 方法严谨:使用标准YCSB框架确保公平比较
- 实验全面:涵盖多种工作负载和并发级别
- 分析深入:不仅提供性能数据,还深入分析架构原因
- 实用价值高:为实际系统选择提供明确指导
- 写作清晰:结构合理,技术描述准确
- 环境局限:单机Docker环境无法充分展现分布式系统优势
- 配置单一:未测试不同配置参数对性能的影响
- 持久化缺失:未详细评估持久化机制对性能的影响
- 成本分析缺失:未考虑硬件成本和运维复杂度
- 长期稳定性:缺乏长时间运行的稳定性测试
- 学术价值:为NoSQL数据库性能研究提供了系统性方法
- 实用价值:为工业界选择合适的键值存储系统提供参考
- 方法论贡献:展示了如何系统性地比较NoSQL系统性能
- 可复现性:实验设置描述详细,便于复现和扩展
- 系统选型:为需要选择键值存储系统的项目提供参考
- 性能优化:为现有系统性能调优提供基准
- 架构设计:为大规模分布式系统架构设计提供依据
- 学术研究:为相关领域研究提供基础数据和方法参考
论文引用了多个重要参考文献,包括:
- Cooper, B.F. et al. (2010). Benchmarking cloud serving systems with YCSB
- Anthony, A., & Rao, Y. N. M. Memcached, Redis, and Aerospike Key-Value Stores Empirical Comparison
- Mohan, R. K. et al. (2024). Evaluating NoSQL Databases for OLAP Workloads
- 以及各数据库系统的官方文档和技术资料
本论文为NoSQL数据库性能评估领域提供了有价值的贡献,通过系统性的实验设计和深入的分析,为理解现代键值存储系统的性能特征和选择合适的技术方案提供了重要参考。