Existem pelo menos 3 maneiras diferentes de fazer isso, cada uma tem seus prós e contras.
A primeira abordagem é usar a varredura ad-hoc não atômica da árvore para identificar e invalidar (excluir) o 2º nível da árvore (1º conjunto de personalizações). Para fazer isso, use um esquema de nomenclatura hierárquica para os campos do seu Hash e itere através deles usando
HSCAN . Por exemplo, supondo que o nome da chave do seu Hash seja o ID do produto (por exemplo, ProductA), você usaria algo como '0001:0001' como o nome do campo para a primeira versão da primeira personalização, '0001:0002' para sua segunda versão e assim por diante. Da mesma forma, '0002:0001' seria a 2ª customização 1ª versão, etc... Então, encontre todas as versões de customização 42, use HSCAN ProductA 0 MATCH 0042:* , HDEL os campos na resposta e repita até o cursor zerar. A abordagem oposta é "indexar" proativamente as versões de cada personalização para que você possa buscá-las com eficiência, em vez de executar a verificação completa do Hash. A maneira de fazer isso é usar os conjuntos do Redis - você mantém um conjunto com todos os nomes de campo para a versão de um determinado produto. As versões podem ser sequenciais (como no meu exemplo) ou qualquer outra coisa, desde que sejam exclusivas. O custo é manter esses índices - sempre que você adicionar ou remover a personalização e/ou versão de um produto, você precisará manter a consistência com esses Conjuntos. Por exemplo, a criação de uma versão seria algo como:
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"
SADD ProductA:0001 0001
Observe que essas duas operações devem estar em uma única transação (ou seja, use um
MULTI\EXEC bloquear ou EVAL um script Lua). Quando você tiver isso configurado, invalidar uma personalização é apenas uma questão de chamar SMEMBERS no Set relevante e excluindo as versões nele do Hash (e do próprio Set também). É importante notar, no entanto, que ler todos os membros de um grande conjunto pode ser demorado - 1K membros não é tão ruim, mas para conjuntos maiores há SSCAN . Por fim, você pode considerar usar um conjunto classificado em vez de um hash. Embora talvez menos intuitivo neste caso de uso, o Sorted Set permitirá que você execute todas as operações necessárias. O preço para usá-lo, no entanto, é o aumento da complexidade de O(logN) para adicionar/remover/ler em comparação com o O(1) do Hash, mas dados os números a diferença não é significativa.
Para liberar o poder do Conjunto Ordenado, você usará a ordenação lexicográfica para que todos os membros do Conjunto Ordenado tenham a mesma pontuação (por exemplo, use 0). Cada produto será representado por um Conjunto Ordenado, assim como no Hash. Os membros do Set são os equivalentes do campo do Hash, ou seja, versões de customizações. O "truque" é construir os membros de uma forma que lhe permita realizar pesquisas de intervalo (ou invalidações de nível 2, se você preferir). Aqui está um exemplo de como deve ser (observe que aqui a chave ProductA não é um Hash, mas um Conjunto Ordenado):
ZADD ProductA 0 0001:0001:<JSON>
Para ler uma versão de personalização, use
ZRANGEBYLEX ProductA [0001:0001: [0001:0001:\xff] e divida o JSON da resposta e para remover uma personalização inteira, use ZREMRANGEBYLEX . 
