Itβs usually not the right idea to put related data in different Redis databases. There is practically no benefit compared to defining namespaces under key naming conventions (without additional granularity regarding security, persistence, timing management, etc.). And the main disadvantage is that clients have to manually process the selection of the correct database, which is the cause of errors for clients targeting multiple databases at the same time.
Now, if you still want to use multiple databases, there is a way to make it work with redis-py and Lua scripts.
redis-py does not define a wrapper for the SELECT command (usually used to switch the current database) due to the streaming implementation of the connection pool. But nothing prevents you from calling SELECT from a Lua script.
Consider the following example:
$ redis-cli SELECT 0 SET mykey db0 SELECT 1 SET mykey db1
The following script displays the value of mykey in two databases from the same client connection.
import redis pool = redis.ConnectionPool(host='localhost', port=6379, db=0) r = redis.Redis(connection_pool=pool) lua1 = """ redis.call("select", ARGV[1]) return redis.call("get",KEYS[1]) """ script1 = r.register_script(lua1) lua2 = """ redis.call("select", ARGV[1]) local ret = redis.call("get",KEYS[1]) redis.call("select", ARGV[2]) return ret """ script2 = r.register_script(lua2) print r.get("mykey") print script2( keys=["mykey"], args = [1,0] ) print r.get("mykey"), "ok" print print r.get("mykey") print script1( keys=["mykey"], args = [1] ) print r.get("mykey"), "misleading !!!"
Script lua1 is naive: it just selects the given database before returning the value. Its use is misleading because after its execution the current database associated with the connection has changed. Do not do that.
Script lua2 is much better. The parameters are the target database and the current database. It ensures that the current database is activated until the end of the script, so that the next command applied to the connection is still running in the correct database. Unfortunately, there is no command to guess the current database in the Lua script, so the client must provide it systematically. Note that the Lua script must reset the current database at the end of what happens (even in the case of a previous error), so complex scripts are cumbersome and inconvenient.