Er zijn minstens 3 verschillende manieren om dat te doen, elk heeft zijn eigen voor- en nadelen.
De eerste benadering is het gebruik van niet-atomaire ad-hocscanning van de boom om het 2e niveau van de boom (1e set aanpassingen) te identificeren en ongeldig te maken (verwijderen). Om dat te doen, gebruikt u een hiërarchisch naamgevingsschema voor uw hash-velden en doorloopt u ze met behulp van HSCAN . Als u er bijvoorbeeld van uitgaat dat de sleutelnaam van uw hash de product-ID is (bijv. ProductA), gebruikt u zoiets als '0001:0001' als veldnaam voor de eerste versie van de eerste aanpassing, '0001:0002' voor de tweede versie en enzovoort. Evenzo zou '0002:0001' de 2e aanpassingsversie zijn, enz... Zoek vervolgens alle versies van aanpassing 42, gebruik HSCAN ProductA 0 MATCH 0042:* , HDEL de velden in het antwoord en herhaal totdat de cursor op nul staat.
De tegenovergestelde benadering is om de versies van elke aanpassing proactief te "indexeren", zodat u ze efficiënt kunt ophalen in plaats van de volledige scan van de hash uit te voeren. De manier om dat te doen is door Redis' Sets te gebruiken - u houdt een Set bij met alle veldnamen voor de versie van een bepaald product. Versies kunnen sequentieel zijn (zoals in mijn voorbeeld) of iets anders, zolang ze maar uniek zijn. De kosten zijn het onderhouden van deze indices - wanneer u de aanpassing en/of versie van een product toevoegt of verwijdert, moet u de consistentie met deze sets behouden. Het maken van een versie zou bijvoorbeeld zoiets zijn als:
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"
SADD ProductA:0001 0001
Merk op dat deze twee bewerkingen in een enkele transactie moeten plaatsvinden (d.w.z. gebruik een MULTI\EXEC blok of EVAL een Lua-script). Als je dit hebt ingesteld, is het ongeldig maken van een aanpassing gewoon een kwestie van SMEMBERS . aanroepen op de relevante Set en het verwijderen van de versies erin uit de Hash (en ook de Set zelf). Het is echter belangrijk op te merken dat het lezen van alle leden van een grote set tijdrovend kan zijn - 1K leden is niet zo slecht, maar voor grotere sets is er SSCAN .
Ten slotte zou je kunnen overwegen om een Sorted Set te gebruiken in plaats van een Hash. Hoewel het in dit geval misschien minder intuïtief is, kunt u met de gesorteerde set alle bewerkingen uitvoeren die u nodig hebt. De prijs voor het gebruik ervan is echter de toegenomen complexiteit van O(logN) voor het toevoegen/verwijderen/lezen in vergelijking met de Hash's O(1), maar gezien de cijfers is het verschil niet significant.
Om de kracht van de gesorteerde set te ontketenen, gebruik je lexicografische volgorde, zodat alle leden van de gesorteerde set dezelfde score moeten hebben (gebruik bijvoorbeeld 0). Elk product wordt vertegenwoordigd door een Sorted Set, net als bij de Hash. De leden van de set zijn de equivalenten van het hash-veld, namelijk de aanpassingsversies. De "truc" is om de leden zo te construeren dat u zoekopdrachten op bereik kunt uitvoeren (of niveau-2-invalidatie als u wilt). Hier is een voorbeeld van hoe het eruit zou moeten zien (merk op dat hier de belangrijkste ProductA geen hash is maar een gesorteerde set):
ZADD ProductA 0 0001:0001:<JSON>
Om een aanpassingsversie te lezen, gebruikt u ZRANGEBYLEX ProductA [0001:0001: [0001:0001:\xff en splits de JSON van het antwoord en gebruik ZREMRANGEBYLEX om een volledige aanpassing te verwijderen .