Dafür gibt es mindestens 3 verschiedene Möglichkeiten, jede hat ihre eigenen Vor- und Nachteile.
Der erste Ansatz besteht darin, nichtatomare Ad-hoc-Scans des Baums zu verwenden, um die zweite Ebene des Baums (erster Satz von Anpassungen) zu identifizieren und ungültig zu machen (zu löschen). Verwenden Sie dazu ein hierarchisches Benennungsschema für die Felder Ihres Hashs und durchlaufen Sie sie mit HSCAN . Angenommen, der Schlüsselname Ihres Hashs ist die Produkt-ID (z. B. ProductA), würden Sie beispielsweise „0001:0001“ als Feldnamen für die erste Version der ersten Anpassung und „0001:0002“ für die zweite Version verwenden so weiter. In ähnlicher Weise wäre „0002:0001“ die 2. Anpassung, 1. Version usw. Suchen Sie dann alle Versionen der Anpassung 42, verwenden Sie HSCAN ProductA 0 MATCH 0042:* , HDEL die Felder in der Antwort, und wiederholen Sie den Vorgang, bis der Cursor auf Null steht.
Der entgegengesetzte Ansatz besteht darin, die Versionen jeder Anpassung proaktiv zu „indizieren“, damit Sie sie effizient abrufen können, anstatt den vollständigen Scan des Hashs durchzuführen. Der Weg, dies zu tun, ist die Verwendung von Redis-Sets - Sie behalten ein Set mit allen Feldnamen für eine bestimmte Produktversion. Versionen können entweder sequentiell sein (wie in meinem Beispiel) oder irgendetwas anderes, solange sie eindeutig sind. Die Kosten bestehen in der Pflege dieser Indizes – wann immer Sie die Anpassung und/oder Version eines Produkts hinzufügen oder entfernen, müssen Sie die Konsistenz mit diesen Sets aufrechterhalten. Die Erstellung einer Version würde beispielsweise wie folgt aussehen:
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"
SADD ProductA:0001 0001
Beachten Sie, dass diese beiden Operationen in einer einzigen Transaktion stattfinden sollten (d. h. verwenden Sie ein MULTI\EXEC block oder EVAL ein Lua-Skript). Wenn Sie dies eingerichtet haben, ist das Ungültigmachen einer Anpassung nur eine Frage des Aufrufs von SMEMBERS auf dem relevanten Set und löscht die darin enthaltenen Versionen aus dem Hash (und auch aus dem Set selbst). Es ist jedoch wichtig zu beachten, dass das Lesen aller Mitglieder aus einem großen Set zeitaufwändig sein kann - 1K-Mitglieder sind nicht so schlimm, aber für größere Sets gibt es SSCAN .
Schließlich könnten Sie erwägen, ein sortiertes Set anstelle eines Hash zu verwenden. Obwohl es in diesem Anwendungsfall vielleicht weniger intuitiv ist, können Sie mit dem Sorted Set alle erforderlichen Operationen ausführen. Der Preis für die Verwendung ist jedoch die erhöhte Komplexität von O(logN) zum Hinzufügen/Entfernen/Lesen im Vergleich zu O(1) des Hash, aber angesichts der Zahlen ist der Unterschied nicht signifikant.
Um die Leistungsfähigkeit des sortierten Sets freizusetzen, verwenden Sie eine lexikografische Reihenfolge, sodass alle Mitglieder des sortierten Sets dieselbe Punktzahl haben sollten (z. B. 0 verwenden). Jedes Produkt wird wie beim Hash durch ein Sorted Set dargestellt. Die Mitglieder des Satzes sind die Äquivalente des Hash-Felds, nämlich die Versionen der Anpassungen. Der "Trick" besteht darin, die Mitglieder so zu konstruieren, dass Sie Bereichssuchen (oder Level-2-Invalidierungen, wenn Sie so wollen) durchführen können. Hier ist ein Beispiel, wie es aussehen sollte (beachten Sie, dass hier der Schlüssel ProductA kein Hash, sondern ein sortiertes Set ist):
ZADD ProductA 0 0001:0001:<JSON>
Um eine Anpassungsversion zu lesen, verwenden Sie ZRANGEBYLEX ProductA [0001:0001: [0001:0001:\xff und trennen Sie den JSON von der Antwort und verwenden Sie ZREMRANGEBYLEX, um eine vollständige Anpassung zu entfernen .
