Det finns minst tre olika sätt att göra det på, var och en har sina egna för- och nackdelar.
Det första tillvägagångssättet är att använda icke-atomär ad-hoc-skanning av trädet för att identifiera och ogiltigförklara (ta bort) trädets andra nivå (första uppsättningen anpassningar). För att göra det, använd ett hierarkiskt namnschema för dina Hash-fält och iterera genom dem med HSCAN . Om du till exempel antar att din Hashs nyckelnamn är produktens ID (t.ex. ProductA), skulle du använda något som "0001:0001" som fältnamn för den första anpassningens första version, "0001:0002" för dess andra version och så vidare. På samma sätt skulle '0002:0001' vara den 2:a anpassningen 1:a versionen, etc... Hitta sedan alla versioner av anpassning 42, använd HSCAN ProductA 0 MATCH 0042:* , HDEL fälten i svaret och upprepa tills markören nollställs.
Det motsatta tillvägagångssättet är att proaktivt "indexera" varje anpassnings versioner så att du kan hämta dem effektivt istället för att utföra Hashs fullständiga genomsökning. Sättet att gå tillväga är att använda Redis set - du behåller ett set med alla fältnamn för en given produktversion. Versioner kan antingen vara sekventiella (som i mitt exempel) eller något annat så länge de är unika. Kostnaden är att bibehålla dessa index – närhelst du lägger till eller tar bort en produkts anpassning och/eller version måste du bibehålla överensstämmelse med dessa set. Till exempel skulle skapandet av en version vara något i stil med:
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"
SADD ProductA:0001 0001
Observera att dessa två operationer bör vara i en enda transaktion (dvs. använd en MULTI\EXEC block eller EVAL ett Lua-manus). När du har den här inställningen är att ogiltigförklara en anpassning bara en fråga om att ringa SMEMBERS på den relevanta uppsättningen och ta bort versionerna i den från hashen (och själva uppsättningen också). Det är dock viktigt att notera att det kan vara tidskrävande att läsa alla medlemmar från ett stort set - 1K medlemmar är inte så illa, men för större set finns det SSCAN .
Slutligen kan du överväga att använda en sorterad uppsättning istället för en hash. Även om det kanske är mindre intuitivt i det här användningsfallet, låter den sorterade uppsättningen dig utföra alla operationer du behöver. Priset för att använda det är dock den ökade komplexiteten hos O(logN) för att lägga till/ta bort/läsa jämfört med hashens O(1), men givet siffrorna är skillnaden inte signifikant.
För att frigöra kraften i den sorterade uppsättningen använder du lexikografisk ordning så att alla medlemmar i den sorterade uppsättningen ska ha samma poäng (t.ex. använd 0). Varje produkt kommer att representeras av en sorterad uppsättning, precis som med hashen. Medlemmarna i uppsättningen är motsvarigheter till Hash-fältet, nämligen anpassningarnas versioner. "Knepet" är att konstruera medlemmarna på ett sätt som gör att du kan utföra intervallsökningar (eller nivå-2 ogiltigförklaringar om du så vill). Här är ett exempel på hur det ska se ut (observera att nyckeln ProductA här inte är en hash utan en sorterad uppsättning):
ZADD ProductA 0 0001:0001:<JSON>
För att läsa en anpassningsversion, använd ZRANGEBYLEX ProductA [0001:0001: [0001:0001:\xff och dela JSON från svaret och för att ta bort en hel anpassning, använd ZREMRANGEBYLEX .