Il est certes possible de modéliser ces données avec Redis, mais il faut penser en termes de structures de données ET de chemins d'accès. Avec Redis, les chemins d'accès ne sont pas gérés implicitement (comme avec les index dans RDBMS/MongoDB).
Pour l'exemple fourni, vous pourriez avoir :
user:<user hash> -> hash of user properties
user:<user hash>:sent -> set of <msg hash>
user:<user hash>:received -> set of <msg hash>
message:<msg hash> -> hash of message properties
Ajouter/supprimer un message reviendrait à conserver les ensembles *:sent et *:received correspondant aux expéditeurs et aux destinataires, en plus d'ajouter/supprimer l'objet message lui-même.
Récupérer les messages envoyés ou reçus pour un utilisateur donné est juste une commande SMEMBERS, ou un SORT si vous souhaitez récupérer également les propriétés du message en même temps :
# Get a list of message hash codes only in one roundtrip
smembers user:<user hash>:received
# Get a list of message contents in one roundtrip
sort user:<user hash>:received by nosort get message:*->sender get message:*->message
Pour la justification de l'utilisation du tri, voir :
- Obtenir plusieurs valeurs de clé de Redis
- Besoin d'aide pour conceptualiser dans Redis/NoSQL
Remarque 1 : avec Redis, il est préférable d'utiliser des entiers comme clés plutôt que des UUID ou des codes de hachage (en particulier dans les ensembles), car ils sont stockés de manière plus efficace.
Remarque 2 : si vous avez besoin d'ordonner les messages, alors des listes doivent être utilisées au lieu d'ensembles. La conséquence est que seuls les messages les plus anciens peuvent être supprimés et que seuls les nouveaux messages peuvent être ajoutés de manière efficace. Vous devriez également ajouter une liste globale pour tous les messages.
