Hai ragione sul fatto che con Redis sono disponibili solo semplici strutture di dati e non possono essere composte da valore (come potresti fare con un database orientato ai documenti come CouchDB o MongoDB). Tuttavia, è possibile comporre strutture di dati per riferimento, e questo è un modello molto comune.
Ad esempio, gli elementi contenuti in un set possono essere chiavi per altri oggetti (liste, tabelle hash, altri set, ecc...). Proviamo ad applicare questo al tuo esempio.
Per modellare una relazione tra clienti e dispositivo+porta, puoi utilizzare set contenenti ID cliente. Per memorizzare informazioni sui clienti, va bene una tabella hash per cliente.
Ecco 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 record sono c:ID
Associamone due a un dispositivo e a una porta:
sadd d:Los_Angeles:11 2 3
La chiave di questo set è d:device:port. I prefissi c:e d:sono solo una convenzione. È necessario creare un set per dispositivo/porta. Un determinato cliente può 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, non ci resta che recuperare il contenuto del set.
smembers d:Los_Angeles:11
1) "2"
2) "3"
quindi le informazioni sui clienti corrispondenti possono essere recuperate collegando 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 aver paura del numero di comandi. Sono molto veloci e la maggior parte dei client Redis ha la capacità di pipeline delle query in modo che sia necessario solo un numero minimo di roundtrip. Usando solo uno smembers e diversi hgetall, il problema può essere risolto con solo due viaggi di andata e ritorno.
Ora è possibile ottimizzare un po' di più, grazie all'onnipresente comando SORT. Questo è probabilmente il comando più complesso in Redis e può essere utilizzato per salvare un viaggio di andata e ritorno 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, recupera il contenuto di un set di dispositivi/porte e recupera le informazioni sui clienti corrispondenti.
Questo esempio era banale, ma più in generale, mentre si possono rappresentare strutture dati complesse con Redis, non è immediato. Devi pensare attentamente al modello sia in termini di struttura che di accesso ai dati (cioè in fase di progettazione, attieniti ai tuoi dati E i tuoi casi d'uso).
