Určitě je možné tato data modelovat pomocí Redis, ale musíte myslet z hlediska datových struktur A přístupových cest. S Redis nejsou přístupové cesty spravovány implicitně (jako u indexů v RDBMS/MongoDB).
Pro uvedený příklad byste mohli mít:
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
Přidání/smazání zprávy by znamenalo udržování sad *:odeslané a *:přijaté odpovídající odesílatelům a příjemcům, navíc k přidání/smazání samotného objektu zprávy.
Načítání odeslaných nebo přijatých zpráv pro daného uživatele je pouze příkaz SMEMBERS nebo SORT, chcete-li současně získat také vlastnosti zprávy:
# 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
Zdůvodnění použití řazení naleznete na adrese:
- Získání více klíčových hodnot z Redis
- Potřebuji pomoc s konceptualizací v Redis/NoSQL
Poznámka 1: s Redis je lepší používat jako klíče celá čísla spíše než UUID nebo hash kódy (zejména v sadách), protože jsou uloženy efektivněji.
Poznámka 2: pokud potřebujete seřadit zprávy, musíte místo sad použít seznamy. Důsledkem je, že lze odstranit pouze nejstarší zprávy a efektivně přidávat pouze zprávy s novinkami. Pravděpodobně byste také přidali globální seznam pro všechny zprávy.