Creo que el mejor consejo es evitar ceñirse al modelo relacional al migrar algo de un RDBMS a Redis. Y más allá del modelo, una diferencia importante es centrarse en las rutas de acceso a los datos, así como en las estructuras de datos.
Redis no incluye un lenguaje de consulta (sino comandos a la memcached) y, por lo tanto, no puede responder a consultas arbitrarias. Si una ruta de acceso a los datos no es parte de la estructura de datos, entonces los datos no se pueden recuperar de manera eficiente.
Redis no es la mejor tienda NoSQL cuando se trata de admitir consultas arbitrarias. Por ejemplo, le serviría mejor algo como MongoDB.
Ahora, si realmente desea implementar sus cosas con Redis, puede intentar usar una estrategia similar a los motores de etiquetado. Sus registros se pueden almacenar en objetos hash. Para cada parte de la columna de las consultas arbitrarias que necesita admitir, crea índices inversos utilizando conjuntos.
Por ejemplo:
# Set up the records: one hash object per record
hmset user:1 name Bilbo type Hobbit job None
hmset user:2 name Frodo type Hobbit job None
hmset user:3 name Gandalf type Maiar job Wizard
hmset user:4 name Aragorn type Human job King
hmset user:5 name Boromir type Human job Warrior
# Set up the indexes: one set per value per field
sadd name:Bilbo 1
sadd name:Frodo 2
sadd name:Gandalf 3
sadd name:Aragorn 4
sadd name:Boromir 5
sadd type:Hobbit 1 2
sadd type:Maiar 3
sadd type:Human 4 5
sadd job:None 1 2
sadd job:Wizard 3
sadd job:King 4
sadd job:Warrior 5
# Perform a query: we want the humans who happen to be a king
# We just have to calculate the intersection of the corresponding sets
sinterstore tmp type:Human job:King
sort tmp by nosort get user:*->name get user:*->job get user:*->type
1) "Aragorn"
2) "King"
3) "Human"
Al combinar unión, intersección, diferencia, se pueden implementar consultas más complejas. Para valores no discretos, o para consultas basadas en rangos, se deben usar conjuntos ordenados (zset) (y se pueden combinar con conjuntos normales).
Este método suele ser bastante rápido si los valores son lo suficientemente discriminantes. Sin embargo, tenga en cuenta que no tiene la flexibilidad de un RDBMS (sin expresiones regulares, sin búsqueda prefijada, las consultas de rango son difíciles de manejar, etc.)
