Serve aiuto per concettualizzare in Redis/NoSQL

Question

Penso di avere una buona conoscenza di tutti i comandi per usare Redis, ma ho difficoltà a capire il modo migliore per usarlo. Sto progettando un sistema di notifica dei clienti che li notificherà tramite il loro metodo preferito (Email, SNMP, Syslog) quando c'è un allarme su uno qualsiasi dei loro circuiti.

Quindi, ottengo un nome dispositivo e una porta. Devo associarlo a un singolo cliente e quindi associare quel cliente a un metodo di consegna. Con un db relazionale, sarebbe risultato probabilmente cercare qualcosa di simile:

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> 

(esempio molto semplificato).

Riesco a vedere come eseguire questa operazione con un hash di elenchi o un hash di hash. Ma immagino che quello che sto avendo problemi con Redis sia che quelle strutture di dati più complesse non sono disponibili per me (per quanto ne so). Quindi, come posso associare più informazioni con una sola chiave? Posso pensare ad alcuni modi in cui posso farlo, ma sembrano tutti implicare più passaggi, e mi piacerebbe avere qualche input dagli attuali programmatori Redis su quale sia il modo "migliore" per farlo.

Answer 1

È corretto che solo le strutture di dati semplici sono disponibili con Redis e non possono essere composte in base al valore (come si potrebbe fare con un database orientato ai documenti come CouchDB o MongoDB). Tuttavia, è possibile comporre strutture di dati per riferimento, e questo è uno schema molto comune.

Ad esempio, gli elementi contenuti in un set possono essere le chiavi per altri oggetti (elenchi, tabelle hash, altri set, ecc.). Proviamo ad applicare questo al tuo esempio.

Per modellare una relazione tra clienti e dispositivo + porta, è possibile utilizzare set contenenti ID cliente. Per memorizzare le informazioni sui clienti, una tabella hash per cliente va bene.

Qui ci sono i clienti:

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 

Le chiavi di questi documenti sono c: ID

Let associato due di loro di un dispositivo e la porta:

sadd d:Los_Angeles:11 2 3 

La chiave di questo set è d: device: port. Il c: e d: i prefissi sono solo una convenzione. Dovrebbe essere creato un set per dispositivo/porta. Un determinato cliente potrebbe appartenere a più set (e quindi associato a più dispositivi/porte).

Ora per trovare i clienti con metodi di consegna collegati a questo dispositivo/porta, dobbiamo solo recuperare il contenuto del set.

smembers d:Los_Angeles:11 
1) "2" 
2) "3" 

quindi le informazioni sul cliente corrispondente può essere recuperato da pipelining una serie di comandi 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" 

Non temere il numero di comandi. Sono molto veloci e la maggior parte dei client Redis è in grado di eseguire la pipeline delle query in modo che sia necessario un numero minimo di roundtrip. Usando solo uno smembratore e diversi hgetall, il problema può essere risolto con solo due roundtrip.

Ora, è possibile ottimizzare ulteriormente, grazie al comando SORT onnipresente. Questo è probabilmente il comando più complesso in Redis e può essere utilizzato per salvare un roundtrip qui.

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" 

In un comando, si recupera il contenuto di un set di dispositivi/porto e recupera le informazioni sul cliente corrispondente.

Questo esempio è stato banale, ma più in generale, mentre è possibile rappresentare strutture dati complesse con Redis, non è immediato. È necessario riflettere attentamente sul modello sia in termini di struttura che di accesso ai dati (ad esempio in fase di progettazione, attenersi ai dati E i casi d'uso).