Por lo general, es una idea incorrecta colocar datos relacionados en diferentes bases de datos de Redis. Casi no hay beneficio en comparación con la definición de espacios de nombres mediante convenciones de nomenclatura de claves (sin granularidad adicional con respecto a la seguridad, la persistencia, la gestión de caducidad, etc.). Y un gran inconveniente es que los clientes tienen que manejar manualmente la selección de la base de datos correcta, lo que es propenso a errores para los clientes que apuntan a varias bases de datos al mismo tiempo.
Ahora, si aún desea utilizar varias bases de datos, hay una forma de hacerlo funcionar con secuencias de comandos redis-py y Lua.
redis-py no define un contenedor para el comando SELECT (normalmente se usa para cambiar la base de datos actual), debido a la implementación subyacente del grupo de conexiones seguras para subprocesos. Pero nada le impide llamar a SELECT desde un script de Lua.
Considere el siguiente ejemplo:
$ redis-cli
SELECT 0
SET mykey db0
SELECT 1
SET mykey db1
El siguiente script muestra el valor de mykey en las 2 bases de datos de la misma conexión de cliente.
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 !!!"
El script lua1 es ingenuo:simplemente selecciona una base de datos determinada antes de devolver el valor. Su uso es engañoso, ya que después de su ejecución, la base de datos actual asociada a la conexión ha cambiado. No hagas esto.
El script lua2 es mucho mejor. Toma la base de datos de destino y la base de datos actual como parámetros. Se asegura de que la base de datos actual se reactive antes de que finalice el script, de modo que el siguiente comando aplicado en la conexión aún se ejecute en la base de datos correcta. Desafortunadamente, no hay ningún comando para adivinar la base de datos actual en el script de Lua, por lo que el cliente tiene que proporcionarlo sistemáticamente. Tenga en cuenta que la secuencia de comandos de Lua debe restablecer la base de datos actual al final, pase lo que pase (incluso en caso de un error anterior), por lo que hace que las secuencias de comandos complejas sean engorrosas e incómodas.
