共计 1468 个字符,预计需要花费 4 分钟才能阅读完成。
仿佛总有几个我的项目宣称他们曾经建设了 ” 世界上最快的键 / 值存储 ”,有时应用的短语甚至更加离谱,比方以下我的项目:
- Redis:https://github.com/redis/redis
- KeyDB:https://github.com/snapchat/k…
- Dragonfly:https://github.com/dragonflyd…
- Skytable:https://github.com/skytable/s…
而依据国外的基准测试后果(30 个线程,每个线程 1 个客户端应用 GET/SET),很显著有些我的项目言过其实了,咱们来看一下理论的性能比照:
1. Redis:112,100 / 99,892
2. KeyDB:288,931 / 282,997
3. Dragonfly:408,322 / 392,446
4. Skytable:619,992 / 676,091
性能比照
Redis
我违心将 Redis 将称为 原始键
/ 值存储(在 memcached 之后),因为它是最古老且应用最宽泛的内存数据库。作为 Redis 的长期追随者,我的确晓得它是单线程的(并且从 6.0 开始应用 io-threads),因而与下面列出的其余多线程存储相比,它的吞吐量至多在某种程度上必定要小。但 Redis 最大的长处是:它是这里所有零碎中性能最残缺的,也是最古老的。
KeyDB
KeyDB 声称是Redis 的多线程分支,速度进步了 5 倍
。我真的很喜爱这个想法,因为我之前在同一个节点上运行了多个 Redis 实例,并像“单节点集群”一样代理它们,这样做的起因就是为了进步 CPU 利用率。单个 KeyDB 实例能够取代不须要的代理性能,因而很多人放弃了 Redis 来应用 KeyDB。
Dragonfly
Dragonfly 宣称它比 Redis 快 25 倍(很多开发者示意无奈重现),并且官网示意 Dragonfly 可能是宇宙中最快的内存存储
。它还反对 Redis/Memcache 的命令,但我感觉它很乏味次要是因为性能。此外,大家都想晓得为什么它更快,它的官网分明地概述了底层架构。
Dragonfly 和 Redis 性能比照
Dragonfly | Redis | |
---|---|---|
适配 Redis API | ✅ | ✅ |
快照长久化 | ✅ | ✅ |
Lua | 5.4.4 | 5.1 |
每个实例提供的 QPS | 3M | 200K |
Async core | ✅ | |
LRFU eviction | ✅ | |
适配 Memcached API | ✅ | |
反对云原生 Open Telemetry 协定 | ✅ |
Skytable
在寻找用 Rust 编写的我的项目时发现它,它同样宣称它 十分快
。Skytable 的“试验基准”宣称它比 Redis 快 10 倍左右,比 KeyDB 快 2-3 倍。我没有据说过 Skytable,而且它仿佛没有被宽泛的应用。
小结
Redis 不须要过多介绍,能够说在生产零碎上应用十分稳固。KeyDB 仿佛 ” 足够稳固”,而且 Snapchat 等企业曾经应用它。临时没有发现 Dragonfly vs Skytable 的基准测试。当然,Redis、KeyDB 和 Skytable 最好的点可能是它们不会对它们运行的零碎做出任何离谱的假如。
为什么这么说,次要是因为 Dragonfly 冀望运行的服务器领有最新的硬件和最新的内核。但理论根本不太可能,因为软硬件替换都会有一个过程。而且如果其余三家我的项目开始采纳最新性能,它们也可能会比当初快得多。最初,Dragonfly 和 Skytable 都还处于开发初期,因而将它们的性能与曾经存在更长时间的 Redis 和 KeyDB 进行比拟可能是不偏心的。此外,除了 Skytable,这些我的项目背地都有公司撑腰。
本文亦通过 NoOne 的集体博客 发表。