什么原因让Redis气急败坏的回击挑战者?总有奸人想害朕
近日,一位前谷歌、前亚马逊的工程师根据自己的测试数据宣称,他开发的系统远超鼎鼎大名的Redis,此举招来Redis团队的怦然回击:总有人想替Redis换套新架构。此举也吸引来众多开源技术人员的关注和议论。事情的起因是这样,这位前谷歌、前亚马逊的工程师,创作了一款开源内存数据缓存系统 Dragonfly,用 C/C++ 编写,基于 BSL 许可(Business Source License)分发。
近日,一位前谷歌、前亚马逊的工程师根据自己的测试数据宣称,他开发的系统远超鼎鼎大名的Redis,此举招来Redis团队的怦然回击:总有人想替Redis换套新架构。此举也吸引来众多开源技术人员的关注和议论。
事情的起因是这样,这位前谷歌、前亚马逊的工程师,创作了一款开源内存数据缓存系统 Dragonfly,用 C/C++ 编写,基于 BSL 许可(Business Source License)分发。
这款新系统提供了对 Memcached 和 Redis 协议的支持,但能够以更高的性能进行查询,运行时内存消耗也更少。与 Redis 相比,Dragonfly 在典型工作负载下实现了 25 倍的性能提升;单个 Dragonfly 服务器每秒可以处理数百万个请求;在 5GB 存储测试中,Dragonfly 所需的内存比 Redis 少 30%。
实话说,作为一个开源软件,Dragonfly 在短短两个月获得了 9.2K GitHub 星,177 个 fork 分支。虽然这些年,涌现了不少类似的 Redis 兼容型内存数据存储系统,例如 KeyDB、Skytable,但是都没能像这次这么“轰动”。
Redis团队为了回击这款新系统 Dragonfly,开始持续发声。
Redis 的联合创始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架构师 Yossi Gottlieb、Redis Labs 的性能工程师 Filipe Oliveira 联合发布了一篇名为《13 年后,Redis 是否需要新的架构》的文章。
在文章中,他们特地给出了自认更加公平的 Redis 7.0 vs. Dragonfly 基准测试结果:Redis 的吞吐量比 Dragonfly 高 18% - 40%,以及一些有关 Redis 架构的观点和思考,以证明 “为什么 Redis 的架构仍然是内存实时数据存储(缓存、数据库,以及介于两者之间的所有内容)的最佳架构”。
最有趣的是,很多网友加入了这场讨论。
当Redis 指出 Dragonfly 基准测试的比较方法 “不能代表 Redis 在现实世界中的运行方式” 。
对此,Reddit 上有网友反驳称:它绝对代表了现实世界中普通用户运行 Redis 的方式。“在单台机器上运行集群,只是为了能够使用超过 1 个 core" 是额外的复杂性,人们只有在别无选择的情况下才会这样做,如果竞争者无论有多少个 core 都能 “just works",那么最好能有更容易的设置。
权威就是用来挑战的,因为权威当初也是挑战旧王而成为新王的。所以,更多网友表示,Redis 发文章进行“回击”,就已经代表他们的营销部门输了:
“Redis 投入如此多的工程精力来写这么一篇文章,还对 Reids/Dragonfly 进行了基准测试,这是对 Dragonfly 的极大赞美。”“我很高兴 Redis 发了这篇文章,因此我必须要去了解一下 Dragonfly,它看起来很棒。”
对于Redis和Dragonfly的表现以及网友的评论,您怎么看?
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)