Het is zeker mogelijk om deze data met Redis te modelleren, maar je moet denken in datastructuren EN toegangspaden. Met Redis worden de toegangspaden niet impliciet beheerd (zoals bij indexen in RDBMS/MongoDB).
Voor het gegeven voorbeeld zou je kunnen hebben:
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
Het toevoegen/verwijderen van een bericht zou inhouden dat de *:sent en *:received sets overeenkomen met de afzenders en ontvangers, naast het toevoegen/verwijderen van het berichtobject zelf.
Het ophalen van verzonden of ontvangen berichten voor een bepaalde gebruiker is slechts een SMEMBERS-opdracht, of een SORT als u tegelijkertijd ook de eigenschappen van het bericht wilt ophalen:
# 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
Voor de grondgedachte over het gebruik van sorteren, zie:
- Meerdere sleutelwaarden ophalen van Redis
- Hulp nodig bij het conceptualiseren in Redis/NoSQL
Opmerking 1: met Redis is het beter om gehele getallen als sleutels te gebruiken in plaats van UUID of hash-codes (vooral in sets), omdat ze op een efficiëntere manier worden opgeslagen.
Opmerking 2: als u de berichten moet ordenen, moeten lijsten worden gebruikt in plaats van sets. Het gevolg is dat alleen oudste berichten kunnen worden verwijderd en dat alleen nieuwe berichten op een efficiënte manier kunnen worden toegevoegd. Je zou waarschijnlijk ook een globale lijst voor alle berichten toevoegen.