Tiene razón en que solo las estructuras de datos simples están disponibles con Redis, y no se pueden componer por valor (como podría hacerlo con una base de datos orientada a documentos como CouchDB o MongoDB). Sin embargo, es posible componer estructuras de datos por referencia, y este es un patrón muy común.
Por ejemplo, los elementos contenidos en un conjunto pueden ser las claves para otros objetos (listas, tablas hash, otros conjuntos, etc...). Intentemos aplicar esto a tu ejemplo.
Para modelar una relación entre clientes y dispositivo+puerto, puede utilizar conjuntos que contengan ID de cliente. Para almacenar información sobre los clientes, una tabla hash por cliente está bien.
Estos son los clientes:
hmset c:1 name Smith protocol tcp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2
hmset c:2 name Jackson protocol udp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2
hmset c:3 name Davis protocol tcp snmp_dest 127.0.0.3 syslog_dest 127.0.0.4
Las claves de estos registros son c:ID
Asociemos dos de ellos a un dispositivo y puerto:
sadd d:Los_Angeles:11 2 3
La clave de este conjunto es d:dispositivo:puerto. Los prefijos c:y d:son solo una convención. Se debe crear un conjunto por dispositivo/puerto. Un mismo cliente puede pertenecer a varios conjuntos (y por tanto asociado a varios dispositivos/puerto).
Ahora, para encontrar los clientes con métodos de entrega adjuntos a este dispositivo/puerto, solo tenemos que recuperar el contenido del conjunto.
smembers d:Los_Angeles:11
1) "2"
2) "3"
luego, la información del cliente correspondiente se puede recuperar canalizando una serie de comandos hgetall:
hgetall c:2
hgetall c:3
1) "name"
2) "Jackson"
3) "protocol"
4) "udp"
5) "snmp_dest"
6) "127.0.0.1"
7) "syslog_dest"
8) "127.0.0.2"
1) "name"
2) "Davis"
3) "protocol"
4) "tcp"
5) "snmp_dest"
6) "127.0.0.3"
7) "syslog_dest"
8) "127.0.0.4"
No tengas miedo de la cantidad de comandos. Son muy rápidos y la mayoría de los clientes de Redis tienen la capacidad de canalizar las consultas para que solo se necesite una cantidad mínima de viajes de ida y vuelta. Con solo usar un smembers y varios hgetall, el problema se puede resolver con solo dos viajes de ida y vuelta.
Ahora, es posible optimizar un poco más, gracias al omnipresente comando SORT. Este es probablemente el comando más complejo de Redis y puede usarse para guardar un viaje de ida y vuelta aquí.
sort d:Los_Angeles:11 by nosort get c:*->name get c:*->protocol get c:*->snmp_dest get c:*->syslog_dest
1) "Jackson"
2) "udp"
3) "127.0.0.1"
4) "127.0.0.2"
5) "Davis"
6) "tcp"
7) "127.0.0.3"
8) "127.0.0.4"
En un comando, recupera el contenido de un conjunto de dispositivos/puertos y obtiene la información del cliente correspondiente.
Este ejemplo fue trivial, pero de manera más general, aunque puede representar estructuras de datos complejas con Redis, no es inmediato. Debe pensar detenidamente en el modelo tanto en términos de estructura como de acceso a los datos (es decir, en el momento del diseño, apéguese a sus datos Y sus casos de uso).
