所以,我来到了一个地方,我想把我存储在redis的数据分割成单独的数据库,因为我有时需要在一种特定的数据上使用键命令,并想把它分开,以使其更快。

If I segment into multiple databases, everything is still single threaded, and I still only get to use one core. If I just launch another instance of Redis on the same box, I get to use an extra core. On top of that, I can't name Redis databases, or give them any sort of more logical identifier. So, with all of that said, why/when would I ever want to use multiple Redis databases instead of just spinning up an extra instance of Redis for each extra database I want? And relatedly, why doesn't Redis try to utilize an extra core for each extra database I add? What's the advantage of being single threaded across databases?


当前回答

甚至Salvatore Sanfilippo (Redis的创造者)也认为在Redis中使用多个db是一个坏主意。点击这里查看他的评论:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

I understand how this can be useful, but unfortunately I consider Redis multiple database errors my worst decision in Redis design at all... without any kind of real gain, it makes the internals a lot more complex. The reality is that databases don't scale well for a number of reason, like active expire of keys and VM. If the DB selection can be performed with a string I can see this feature being used as a scalable O(1) dictionary layer, that instead it is not. With DB numbers, with a default of a few DBs, we are communication better what this feature is and how can be used I think. I hope that at some point we can drop the multiple DBs support at all, but I think it is probably too late as there is a number of people relying on this feature for their work.

其他回答

你不希望在一个redis实例中使用多个数据库。正如您所指出的,多个实例使您可以利用多个内核。如果使用数据库选择,则升级时必须进行重构。监视和管理多个实例并不困难,也不痛苦。

实际上,通过基于实例的隔离,您可以获得对每个db更好的度量。每个实例都有反映该数据段的统计信息,这可以实现更好的调优、响应更及时、更准确的监控。使用最新版本并按实例分隔数据。

正如Jonaton所说,不要使用按键命令。如果您只是创建一个键索引,您将发现更好的性能。无论何时添加键,都要将键名添加到集合中。keys命令在扩展后并不是特别有用,因为返回它将花费大量时间。

让访问模式决定如何构建数据,而不是按照您认为有效的方式存储数据,然后再考虑如何访问和切碎数据。您将看到更好的性能,并发现数据消费代码通常更干净和更简单。

对于单线程,考虑redis是为速度和原子性而设计的。当然,在一个db中修改数据的操作不需要等待另一个db,但是如果该操作保存到转储文件中,或者在slave上处理事务呢?在这一点上,您开始进入并发编程的杂草。

通过使用多个实例,您可以将多线程的复杂性转化为更简单的消息传递样式系统。

我正在使用redis来实现电子邮件地址的黑名单,并且我对不同级别的黑名单有不同的TTL值,因此在同一实例上使用不同的db对我有很大帮助。

甚至Salvatore Sanfilippo (Redis的创造者)也认为在Redis中使用多个db是一个坏主意。点击这里查看他的评论:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

I understand how this can be useful, but unfortunately I consider Redis multiple database errors my worst decision in Redis design at all... without any kind of real gain, it makes the internals a lot more complex. The reality is that databases don't scale well for a number of reason, like active expire of keys and VM. If the DB selection can be performed with a string I can see this feature being used as a scalable O(1) dictionary layer, that instead it is not. With DB numbers, with a default of a few DBs, we are communication better what this feature is and how can be used I think. I hope that at some point we can drop the multiple DBs support at all, but I think it is probably too late as there is a number of people relying on this feature for their work.

上面没有提到我们的动机。我们使用多个数据库,因为我们经常需要删除一组特定类型的数据,而FLUSHDB可以简化这一操作。例如,我们可以在数据库0上使用FLUSHDB清除所有缓存的网页,而不影响我们对Redis的所有其他使用。

这里有一些讨论,但我没有找到关于这vs扫描和删除性能的明确信息:

https://github.com/StackExchange/StackExchange.Redis/issues/873

原则上,相同实例上的Redis数据库与RDBMS数据库实例中的模式没有区别。

所以,说了这么多,为什么/什么时候我想要使用倍数 Redis数据库,而不是仅仅旋转一个额外的Redis实例 为我想要的每个额外数据库?

There's one clear advantage of using redis databases in the same redis instance, and that's management. If you spin up a separate instance for each application, and let's say you've got 3 apps, that's 3 separate redis instances, each of which will likely need a slave for HA in production, so that's 6 total instances. From a management standpoint, this gets messy real quick because you need to monitor all of them, do upgrades/patches, etc. If you don't plan on overloading redis with high I/O, a single instance with a slave is simpler and easier to manage provided it meets your SLA.