Certamente é possível modelar esses dados com o Redis, mas você precisa pensar em termos de estruturas de dados E caminhos de acesso. Com o Redis, os caminhos de acesso não são gerenciados implicitamente (como nos índices no RDBMS/MongoDB).
Para o exemplo fornecido, você poderia ter:
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
Adicionar/excluir uma mensagem significaria manter os conjuntos *:sent e *:received correspondentes aos remetentes e destinatários, além de adicionar/excluir o próprio objeto de mensagem.
Recuperar mensagens enviadas ou recebidas para um determinado usuário é apenas um comando SMEMBERS, ou um SORT se você deseja recuperar também as propriedades da mensagem ao mesmo tempo:
# 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
Para o raciocínio sobre o uso de classificação, consulte:
- Como obter vários valores de chave do Redis
- Precisa de ajuda para conceituar em Redis/NoSQL
Observação 1: com o Redis, é melhor usar inteiros como chaves em vez de UUID ou códigos hash (especialmente em conjuntos), pois eles são armazenados de maneira mais eficiente.
Observação 2: se você precisar ordenar as mensagens, as listas devem ser usadas em vez de conjuntos. A consequência é que apenas as mensagens mais antigas podem ser removidas e apenas as mensagens do novo conjunto podem ser adicionadas de maneira eficiente. Você provavelmente também adicionaria uma lista global para todas as mensagens.