È certamente possibile modellare questi dati con Redis, ma è necessario pensare in termini di strutture dati E percorsi di accesso. Con Redis i percorsi di accesso non vengono gestiti in modo implicito (come con gli indici in RDBMS/MongoDB).
Per l'esempio fornito, potresti avere:
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
Aggiungere/eliminare un messaggio significherebbe mantenere gli insiemi *:sent e *:received corrispondenti a mittenti e destinatari, oltre ad aggiungere/eliminare l'oggetto messaggio stesso.
Recuperare i messaggi inviati o ricevuti per un determinato utente è solo un comando SMEMBERS, oppure un SORT se vuoi recuperare anche le proprietà del messaggio contemporaneamente:
# 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
Per la logica dell'utilizzo dell'ordinamento, vedere:
- Ottenere più valori chiave da Redis
- Hai bisogno di aiuto per concettualizzare in Redis/NoSQL
Nota 1: con Redis è meglio usare numeri interi come chiavi piuttosto che UUID o codici hash (soprattutto nei set), poiché sono memorizzati in modo più efficiente.
Nota 2: se è necessario ordinare i messaggi, è necessario utilizzare gli elenchi al posto degli insiemi. La conseguenza è che solo i messaggi più vecchi possono essere rimossi e solo i nuovi messaggi possono essere aggiunti in modo efficiente. Probabilmente aggiungeresti anche un elenco globale per tutti i messaggi.