これらのデータを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： メッセージを注文する必要がある場合は、セットの代わりにリストを使用する必要があります。その結果、削除できるのは最も古いメッセージのみであり、効率的な方法で追加できるのは新しいセットのメッセージのみです。おそらく、すべてのメッセージのグローバルリストも追加するでしょう。