Il existe au moins 3 façons différentes de le faire, chacune ayant ses avantages et ses inconvénients.
La première approche consiste à utiliser une analyse ad hoc non atomique de l'arborescence pour identifier et invalider (supprimer) le 2e niveau de l'arborescence (1er ensemble de personnalisations). Pour ce faire, utilisez un schéma de nommage hiérarchique pour les champs de votre hachage et parcourez-les à l'aide de HSCAN . Par exemple, en supposant que le nom de la clé de votre hachage est l'ID du produit (par exemple, ProductA), vous utiliserez quelque chose comme '0001:0001' comme nom de champ pour la première version de la première personnalisation, '0001:0002' pour sa deuxième version et ainsi de suite. De même, '0002:0001' serait la 2ème personnalisation 1ère version, etc... Ensuite, trouvez toutes les versions de personnalisation 42, utilisez HSCAN ProductA 0 MATCH 0042:* , HDEL les champs de la réponse, et répétez jusqu'à ce que le curseur se mette à zéro.
L'approche inverse consiste à "indexer" de manière proactive les versions de chaque personnalisation afin que vous puissiez les récupérer efficacement au lieu d'effectuer l'analyse complète du hachage. La façon de procéder consiste à utiliser les ensembles de Redis - vous conservez un ensemble avec tous les noms de champs pour la version d'un produit donné. Les versions peuvent être séquentielles (comme dans mon exemple) ou autre tant qu'elles sont uniques. Le coût est de maintenir ces indices - chaque fois que vous ajoutez ou supprimez la personnalisation et/ou la version d'un produit, vous devrez maintenir la cohérence avec ces ensembles. Par exemple, la création d'une version ressemblerait à :
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"
SADD ProductA:0001 0001
Notez que ces deux opérations doivent être en une seule transaction (c'est-à-dire utiliser un MULTI\EXEC bloquer ou EVAL une écriture Lua). Lorsque vous avez configuré cette configuration, l'invalidation d'une personnalisation consiste simplement à appeler SMEMBERS sur l'Ensemble concerné et en supprimant les versions qu'il contient du Hash (ainsi que l'Ensemble lui-même). Il est important de noter, cependant, que la lecture de tous les membres d'un grand ensemble peut prendre du temps - 1K membres n'est pas si mal, mais pour les grands ensembles, il y a SSCAN .
Enfin, vous pouvez envisager d'utiliser un ensemble trié au lieu d'un hachage. Bien que peut-être moins intuitif dans ce cas d'utilisation, l'ensemble trié vous permettra d'effectuer toutes les opérations dont vous avez besoin. Le prix de son utilisation, cependant, est la complexité accrue de O(logN) pour ajouter/supprimer/lire par rapport à O(1) de Hash, mais étant donné les chiffres, la différence n'est pas significative.
Pour libérer la puissance de l'ensemble trié, vous utiliserez l'ordre lexicographique afin que tous les membres de l'ensemble trié aient le même score (par exemple, utilisez 0). Chaque produit sera représenté par un ensemble trié, tout comme avec le hachage. Les membres du Set sont les équivalents du champ du Hash, à savoir les versions des personnalisations. Le "truc" consiste à construire les membres d'une manière qui vous permet d'effectuer des recherches de plage (ou des invalidations de niveau 2 si vous voulez). Voici un exemple de ce à quoi cela devrait ressembler (notez qu'ici la clé ProductA n'est pas un hachage mais un ensemble trié) :
ZADD ProductA 0 0001:0001:<JSON>
Pour lire une version de personnalisation, utilisez ZRANGEBYLEX ProductA [0001:0001: [0001:0001:\xff et séparez le JSON de la réponse et pour supprimer une personnalisation entière, utilisez ZREMRANGEBYLEX .
