Със сигурност е възможно да моделирате тези данни с Redis, но трябва да мислите по отношение на структурите от данни И пътищата за достъп. С Redis пътищата за достъп не се управляват имплицитно (както при индексите в RDBMS/MongoDB).
За предоставения пример можете да имате:
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
Добавянето/изтриването на съобщение би означавало поддържане на наборите *:sent и *:received, съответстващи на подателите и получателите, в допълнение към добавянето/изтриването на самия обект на съобщението.
Извличането на изпратени или получени съобщения за даден потребител е просто команда SMEMBERS или SORT, ако искате да извлечете и свойствата на съобщението по едно и също време:
# 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
За обосновката относно използването на сортиране вижте:
- Получаване на множество ключови стойности от Redis
- Имам нужда от помощ за концептуализиране в Redis/NoSQL
Забележка 1: с Redis е по-добре да използвате цели числа като ключове, а не UUID или хеш кодове (особено в набори), тъй като те се съхраняват по по-ефективен начин.
Забележка 2: ако трябва да поръчате съобщенията, тогава трябва да се използват списъци вместо набори. Резултатът е, че само най-старите съобщения могат да бъдат премахнати и само новите съобщения могат да се добавят по ефективен начин. Вероятно бихте добавили и глобален списък за всички съобщения.
