为什么创建比Redis更快的KeyDB?就是玩儿! - Sully

21-04-28 banq

离开微软后,我想开始一些新的事情。一个想法是搜索引擎,您可以在其中使用正则表达式来搜索我使用Redis构建的Internet。但是,我不明白为什么它只使用我的八个CPU内核之一。我很生气,因为它只使用了机器的一小部分,所以我花了一个月的时间添加多线程,然后写了一篇博客文章说:Redis应该是多线程的”。

我对该帖子的反馈感到非常惊讶。在Hacker News上反应很大,但是Redis认为那太复杂了。

我的想法仅仅是,如果他们不这样做,那我们就可以做到。因此,我们做到了–我们将KeyDB设置为我​​们认为应该拥有的数据库。

当时我们并不想成立一家数据库公司,这只是一个兴趣产物。但是各方面反应的确让我们感到惊讶。我认为在这里有很大的需求,而Redis出于某种原因决定不提供服务。如果他们不会,那么我们会。

以这种方式开始提出了一些挑战。投资者真的不知道该如何看待我们。投资方YC在这次面谈中的主要关注点是我们是否真正在构建与Redis不同的东西。我很感激他们和我们抓住了机会。

Redis是一个很好的基础,它的创始人Salvatore Sanfilippo在构建它方面做得非常出色,但是我们希望将其带往另一个方向。他想要简单性,我们却想要性能。

Redis通常用作缓存,因此我们认为专注于性能是最有意义的。Redis随后使用I / O线程稍微改变了方向,但是我们在KeyDB上的方法获得了更好的性能。

我们还花费大量时间来确保我们始终与Redis兼容。例如,Redis具有一定的一致性保证:如果执行此查询,则将得到此结果。这对用户来说很重要,因为他们不想切换到其他数据库,那会遇到只在某些时间出现的细微错误。

随着我们做更多的工作来改善多线程的能力,例如我们已经完成了从全局锁转向异步的工作,我们将保持这种兼容性。我们绝不会(出于性能的考虑)放松这些保证,我们始终保持这种兼容性。

我们使用的是现代C ++,而不是旧的C ++ 98,这是一种不好的语言,而现代C ++很好,因为它是C的超集,而Redis仍然是C。如果我们需要从中继承任何代码,我们仍然可以这样做,但是其中具有额外的功能也很不错。

当您想跨不同的CPU核扩展时,由于全局锁定,瓶颈开始蔓延。我们一直在进行更多的无锁编程,以尝试改善这种情况。

在技​​术层面上这是非常困难的,但是最具挑战性的事情实际上是在业务方面。但是当您开始为此收费时,期望值就会上升。作为一个开源项目,您可以相当成功,但是,如果您想开始尝试出售产品,则需要更加有条理。那是一个很大的学习曲线。

性能测试方面:您可以并行或一次发送多个命令。如果使用这种方法,Redis可以得到相当不错的数字,问题在于,大多数客户应用程序的工作方式并非如此。在大多数情况下,发送查询会等待结果,然后进行一些处理,然后可能会发送另一个查询。我们总是以这种方式进行测试。

开源KeyDB是Redis的多线程高性能分支,KeyDB开源号称是世界上最快的内存数据库,当然比Redis更快。

 

黑客新闻网友讨论

真正的问题是Redis Cluster协议,该协议将所有智能设备推送到客户端。这意味着每个客户端实现的行为都不同,失败也不同。我鼓励Redis用户使用Envoy代理作为Redis客户端(即使用vanilla客户端,并使用Envoy作为集群客户端)。您将获得Redis Cluster的所有HA和实用性,但是麻烦就少了。另外,强烈鼓励人们看看Elasticache,它也真的很好。

 

大约9年前,我分叉Redis创建了Thredis。有关如何实施的一些说明:

https://github.com/grisha/thredis/blob/master/README-THREDIS

然后,我向其中添加了SQLite,更多详细信息在这里:http://thredis.org,尽管我确实在一个实际的项目中使用了一段时间,但大部分都是为了玩儿

 

出于某些相同的原因,我们编写了Redis的Erlang版本(https://github.com/cbd/edis)-多线程以有趣的方式更改了某些缩放语义。它主要是为了娱乐,但最终以一些简单的REDIS协议实现前端出现在一些实际项目中,在后端可以用实现者想要的任何东西代替后端。

 

我们团队中的某个人对KeyDB进行了研究,对于我们的工作量(每个查询很多MGET),它并没有比Redis好得多。但是,我们仍然可以继续使用它,因为我们的GCP Memorystore实例几乎始终处于100%CPU的状态。我们尚未评估Redis6。

虽然KeyDB是多线程,但是我们可以以集群方式在每个内核上运行的一个Redis呢?在8核CPU上运行8个Redis?以您有9个节点的Redis集群的场景为例:使用KeyDB,您可以通过3个线程将其缩减到3个节点,同时获得相同的吞吐量。这减少了维护负担,同时还减少了等待时间。如果使用Redis集群,每次访问单独的分片时,连接到不同的群集服务器都会产生开销。KeyDB提供更好的优点是:可以完全避免群集。对于许多人来说,这是KeyDB的最大赢家。

 

这是否意味着在单核或低端环境中,最好使用Redis。我认为消除多核复杂性将是有益的。目前,单线程KeyDB的速度要慢几个百分点。

 

KeyDB以“ DB”这样的名称来表示它可能支持持久性,KeyDB具有FLASH功能,可为我们提供基础持久性,您不再需要RDB或AOF。KeyDB的长期目标是让您在一个数据库中的内存和磁盘之间平衡数据集。将来,我认为缓存将只是功能更全的数据库的功能,而这正是我们使用KeyDB的方向。

 

 

1
猜你喜欢