Vous avez raison de dire que seules des structures de données simples sont disponibles avec Redis et qu'elles ne peuvent pas être composées par valeur (comme vous pourriez le faire avec une base de données orientée document telle que CouchDB ou MongoDB). Cependant, il est possible de composer des structures de données par référence, et c'est un modèle très courant.
Par exemple, les éléments contenus dans un ensemble peuvent être les clés d'autres objets (listes, tables de hachage, autres ensembles, etc ...). Essayons d'appliquer cela à votre exemple.
Pour modéliser une relation entre les clients et le périphérique+port, vous pouvez utiliser des ensembles contenant des ID client. Pour stocker des informations sur les clients, une table de hachage par client convient.
Voici les clients :
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
Les clés de ces enregistrements sont c:ID
Associons-en deux à un appareil et un port :
sadd d:Los_Angeles:11 2 3
La clé de cet ensemble est d:device:port. Les préfixes c:et d:ne sont qu'une convention. Un ensemble par périphérique/port doit être créé. Un même client peut appartenir à plusieurs ensembles (et donc être associé à plusieurs équipements/ports).
Maintenant, pour trouver les clients avec des méthodes de livraison attachées à cet appareil/port, il suffit de récupérer le contenu de l'ensemble.
smembers d:Los_Angeles:11
1) "2"
2) "3"
ensuite, les informations client correspondantes peuvent être récupérées en mettant en pipeline un certain nombre de commandes 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"
N'ayez pas peur du nombre de commandes. Ils sont très rapides et la plupart des clients Redis ont la capacité de canaliser les requêtes afin que seul un nombre minimum d'allers-retours soient nécessaires. En utilisant simplement un smembers et plusieurs hgetall, le problème peut être résolu en seulement deux allers-retours.
Maintenant, il est possible d'optimiser un peu plus, grâce à la commande SORT omniprésente. Il s'agit probablement de la commande la plus complexe de Redis, et elle peut être utilisée pour enregistrer un aller-retour ici.
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 une seule commande, il récupère le contenu d'un ensemble appareil/port et récupère les informations client correspondantes.
Cet exemple était trivial, mais plus généralement, si vous pouvez représenter des structures de données complexes avec Redis, ce n'est pas immédiat. Vous devez bien réfléchir au modèle à la fois en termes de structure et d'accès aux données (c'est-à-dire qu'au moment de la conception, respectez vos données ET vos cas d'utilisation).
