Es ist sicherlich möglich, diese Daten mit Redis zu modellieren, aber Sie müssen in Datenstrukturen UND Zugriffspfaden denken. Bei Redis werden die Zugriffspfade nicht implizit verwaltet (wie bei Indizes in RDBMS/MongoDB).
Für das bereitgestellte Beispiel könnten Sie Folgendes haben:
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
Das Hinzufügen/Löschen einer Nachricht würde bedeuten, dass zusätzlich zum Hinzufügen/Löschen des Nachrichtenobjekts selbst die Sätze *:gesendet und *:empfangen beibehalten werden, die den Absendern und Empfängern entsprechen.
Das Abrufen gesendeter oder empfangener Nachrichten für einen bestimmten Benutzer ist nur ein SMEMBERS-Befehl oder ein SORT, wenn Sie gleichzeitig auch die Eigenschaften der Nachricht abrufen möchten:
# 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
Zur Begründung der Verwendung von sort siehe:
- Mehrere Schlüsselwerte von Redis erhalten
- Benötigen Sie Hilfe bei der Konzeptualisierung in Redis/NoSQL
Anmerkung 1: Bei Redis ist es besser, Integer als Schlüssel zu verwenden als UUID oder Hash-Codes (insbesondere in Sets), da diese effizienter gespeichert werden.
Anmerkung 2: Wenn Sie die Nachrichten ordnen müssen, müssen Listen anstelle von Sätzen verwendet werden. Die Konsequenz ist, dass nur die ältesten Nachrichten entfernt werden können und nur neuste Nachrichten effizient hinzugefügt werden können. Sie würden wahrscheinlich auch eine globale Liste für alle Nachrichten hinzufügen.
