共计 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 的集体博客 发表。