所以，我来到了一个地方，我想把我存储在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?
原则上，相同实例上的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.
原则上，相同实例上的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.
甚至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”，你可能有一个最小的内存大小，并将为你分配的内存付费。然而，如果你的数据集比这个小，那么你就会浪费一些分配，因此也会浪费一些钱。
使用数据库，您可以使用相同的Redis云实例为(比如说)开发、UAT和生产提供服务，或者应用程序的多个实例，或者其他任何东西——这样可以使用更多的已分配内存，因此更划算。
我正在研究的一个用例有几个应用程序实例，每个实例使用20 - 300k，但我的云提供商上的最小分配是1M。我们可以将10个实例合并到一个Redis上，而不受任何限制，因此可以节省大约90%的Redis托管成本。我知道这种方法有局限性和问题，但我认为值得一提。
