最近出了 Dragonfly[1]，从其 Github 上的 benchmark 来看，似乎比较 Redis 的性能好很多。

而 Redis 官方写了一篇 13 Years Later – Does Redis Need a New Architecture?[2] 作为回应。

我恰好了解一点 in memory key value storage 的东西，所以在这里说一点个人看法。

我对这个领域最多就是了解，如果有任何不清楚或者说错的地方，还望大家可以指出，并且用批判的眼光看待这篇文章。

Dragonfly

Performance

Dragonfly 号称 fully compatible with Redis and Memcached APIs。Memcached 研究和优化似乎更多一些，一般大家愿意拿 Memcached 做比较 [5][10]。

当让也有拿 Redis 做比较的，比如 Noria[3][4]，不过 Noria 不是 In-Memory Key-Value Storage，而是一个可以维护缓存的 DBMS。

Noria 里面的 benchmark 是在 16 核机器上做的，而 Redis 又是单线程架构 (虽然 I/O 是多线程，但在内存读写数据，都是在单线程里做的)，而 Noria 的架构是多线程。

为了不欺负 Redis，所以直接给 Redis 乘以了 16 来做比较。

而 Dragonfly 的压测，分别在 AWS 的 r6g.16xlarge，c7g.16xlarge 和 c6gn.16xlarge 下做的，都是 64 核心。

这个压测，没办法说明 Dragonfly 本身性能好，还是在多核的作用下，性能才比 Redis 好。

这里做两组压测可能更好一些，一组是单核 CPU 下的比较。另一组在不同核心数下做，第一组主要看其本身的性能，第二组看多核的扩展性，即性能是否可以随着核心数的增加成线性增长。

这样做的好处是，第一次组看本身性能，第二组，排除其他因素的影响，比如 io_uring，单独看多线程实现的好坏。

multi-key operations atomicity guarantees

Redis 单机支持这个，但集群却不支持 [6]，也很少看到这方面的研究。

数据库里常用的方法是 multi-version concurrency control，比如这篇论文有对不同的算法做对比 [7]，在几十个核心的情况下，扩展性似乎不成问题。

好奇为什么 Dragonfly 会选择 VLL，也好奇具体是怎么做的。

13 Years Later – Does Redis Need a New Architecture?

这篇文章，是 Redis 反驳 Dragonfly 的。

40-shard Redis 7.0 Cluster

40 个 shards 大可不必，可以像 Noria 一样，压单机，再乘以核心数就好了啊，不但简单，数字还更好。

Dragonfly 有提供 multi-key operations atomicity guarantee，但 Redis 集群似乎不可以 [6]。

就好比跑 5 km，Dragonfly 负重了 5 公斤，而 Redis 却没有一样。

Some Other Architectures

Erlang 在很早之前，就开始做 SMP 相关的优化，比如 ETS 上优化有 [8][9]。

Erlang ETS 大约在 2010，即 12 年前，优化了读写锁。benchmark 是下面这个样子（scheduler 数目可以简单理解为线程数），在 8 核下，扩展性看起来还是不错的。

或者说不是 13 年后，12 年前，就有不同的实现。

顺便说一个八卦，Erlang creator Joe Armstrong 被他的同事嘲讽不会写 C，然后他的同事重写了 Erlang，让 Erlang 有了不错的性能。

如果让 Joe Armstrong 实现 ETS 的话，可能也会选择单线程吧？

比如 2014 年的 MICA[10]，从整体 (holistic approach) 上对 In-Memory Key-Value Storage 做了优化，比如请求处理，网络处理，数据结构等。

比如 2021 年的 BMC[5]，使用 ebpf 做 kernel bypass。

再比如网络协议（有些性能损耗在网络协议上了）的优化 Homa[11]。

不难看出，In-Memory Key-Value Storage 无论是十年前的工业实践（Erlang ETS），还是理论研究，都有很多有趣的东西。

收个尾

Dragonfly 刚刚开始，这样的压测方式有可能只是博人眼球，而 Redis 也在不断的进化中。

相信无论哪个都会越来越好。这样我这种 CRUD 程序员就可以更少的操心存储的事。

References

1. Dragonfly https://github.com/dragonflydb/dragonfly
2. 13 Years Later – Does Redis Need a New Architecture? https://redis.com/blog/redis-architecture-13-years-later/
3. Jon Gjengset, Partial State in Dataflow-Based Materialized Views, Phd thesis, 2021
4. Jon Gjengset, Partial State in Dataflow-Based Materialized Views, Doctoral Dissertation, 2021
5. Yoann Ghigoff, BMC: Accelerating Memcached using Safe In-kernel Caching and Pre-stack Processing, nsdi 2021
6. Redis cluster specification https://redis.io/docs/reference/cluster-spec/#implemented-subset
7. Y. Wu, et al., An Empirical Evaluation of In-Memory Multi-Version Concurrency Control, in VLDB, 2017
8. Rickard Green, RWLocks in Erlang/OTP, 2010 http://erlang.org/~rickard/euc-2010/
9. Konstantinos Sagonas, More Scalable Ordered Set for ETS Using Adaptation, 2014.
10. H. Lim. MICA: A Holistic Approach to Fast In-Memory Key-Value Storage, NSDI 2014
11. Homa: A receiver-driven low-latency transport protocol using network priorities