Tiene razón en que solo las estructuras de datos simples están disponibles con Redis, y no pueden estar compuestas por valor (como podría hacer 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 juegos, etc.). Tratemos de aplicar esto a su ejemplo.
Para modelar una relación entre clientes y dispositivo + puerto, puede usar conjuntos que contengan ID de cliente. Para almacenar información sobre los clientes, una tabla de hash por cliente está bien.
Éstos 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: Identificación
Vamos a asociar dos de ellos a un dispositivo y el puerto:
sadd d:Los_Angeles:11 2 3
La clave de este conjunto es d: dispositivo: puerto. Los prefijos c: yd: son solo una convención. Se debe crear un juego por dispositivo/puerto. Un cliente determinado podría pertenecer a varios conjuntos (y, por lo tanto, asociado a varios dispositivos/puertos).
Ahora, para encontrar a los clientes con los métodos de entrega conectados a este dispositivo/puerto, solo tenemos que recuperar el contenido del conjunto.
smembers d:Los_Angeles:11
1) "2"
2) "3"
entonces la información del cliente correspondiente puede ser recuperada mediante la canalización de 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 tenga miedo de la serie 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 un número mínimo de viajes de ida y vuelta. Con solo usar un poco y varias 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 en Redis, y se puede usar para guardar una 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 dispositivo/conjunto de puertos y obtiene la información del cliente correspondiente.
Este ejemplo fue trivial, pero en 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, conserve sus datos en Y sus casos de uso).
¿Has echado un vistazo al Redis Hash? hmset/hmget, por ejemplo, le permite asociar una sola clave y múltiples 'campos' que podrían representar sus identidades. http://openmymind.net/2012/1/23/The-Little-Redis-Book/ - el Libro Redis tiene algunos buenos ejemplos. – Alex
En realidad, no vi HMSET/HMGET. Debe ser una nueva adición después del tutorial que realicé. Jugaré con eso. –