2012-02-24 10 views
7

Creo que tengo una buena comprensión de todos los comandos para usar Redis, pero estoy teniendo dificultades para encontrar la mejor manera de usarlo. Estoy diseñando un sistema de notificación al cliente que los notificará a través de su método preferido (correo electrónico, SNMP, Syslog) cuando haya una alarma en cualquiera de sus circuitos.Necesito ayuda para conceptualizar en Redis/NoSQL

Entonces, obtengo el nombre de un dispositivo y un puerto. Necesito asociar eso con un solo cliente, y luego asociar ese cliente a un método de entrega. Con una base de datos relacional, se vería probablemente se verá algo como esto:

Device name: Los_Angeles 
Port: 11 

SELECT Customer_ID, Customer_name from device_info where device_port = 'Los_Angeles:11' 
SELECT Customer_protocol, SNMP_destination, Syslog_destination from CUSTOMER 
    where Customer_ID = <customer_id from above> 

(ejemplo muy simplificado).

Puedo ver cómo hacerlo programáticamente con un hash de listas o un hash de hashes. Pero supongo que lo que estoy teniendo problemas en Redis es que esas estructuras de datos más complejas no están disponibles para mí (hasta donde yo sé). Entonces, ¿cómo puedo asociar varias piezas de información con una sola clave? Puedo pensar en algunas maneras en que puedo hacerlo, pero todos parecen implicar varios pasos, y me gustaría obtener información de los programadores actuales de Redis sobre cuál es la "mejor" manera de hacer esto.

+0

¿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

+0

En realidad, no vi HMSET/HMGET. Debe ser una nueva adición después del tutorial que realicé. Jugaré con eso. –

Respuesta

10

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).

+0

¡Gracias por esto! Es exactamente lo que estaba buscando. –

Cuestiones relacionadas