Ci sono almeno 3 modi diversi per farlo, ognuno ha i suoi pro e contro.
Il primo approccio consiste nell'utilizzare la scansione ad hoc non atomica dell'albero per identificare e invalidare (eliminare) il 2° livello dell'albero (1° set di personalizzazioni). Per farlo, usa uno schema di denominazione gerarchico per i campi del tuo hash e scorreli usando HSCAN . Ad esempio, supponendo che il nome della chiave del tuo hash sia l'ID del prodotto (ad es. ProdottoA), useresti qualcosa come "0001:0001" come nome del campo per la prima versione della prima personalizzazione, "0001:0002" per la sua seconda versione e così via. Allo stesso modo, '0002:0001' sarebbe la seconda personalizzazione 1a versione, ecc... Quindi, trova tutte le versioni di personalizzazione 42, usa HSCAN ProductA 0 MATCH 0042:* , HDEL i campi nella risposta e ripetere finché il cursore non si azzera.
L'approccio opposto consiste nell'"indicizzare" in modo proattivo le versioni di ciascuna personalizzazione in modo da poterle recuperare in modo efficiente invece di eseguire la scansione completa dell'hash. Il modo per farlo è usare i set di Redis:mantieni un set con tutti i nomi dei campi per una determinata versione del prodotto. Le versioni possono essere sequenziali (come nel mio esempio) o qualsiasi altra cosa purché siano uniche. Il costo è il mantenimento di questi indici:ogni volta che aggiungi o rimuovi la personalizzazione e/o la versione di un prodotto, dovrai mantenere la coerenza con questi set. Ad esempio, la creazione di una versione sarebbe qualcosa del tipo:
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"
SADD ProductA:0001 0001
Nota che queste due operazioni dovrebbero essere in un'unica transazione (ovvero utilizzare un MULTI\EXEC blocco o EVAL uno script Lua). Quando hai impostato questa impostazione, invalidare una personalizzazione è solo questione di chiamare SMEMBERS sul Set pertinente ed eliminando le versioni in esso contenute dall'Hash (e anche dal Set stesso). È importante notare, tuttavia, che leggere tutti i membri di un Set di grandi dimensioni potrebbe richiedere molto tempo:1.000 membri non sono poi così male, ma per Set più grandi c'è SSCAN .
Infine, potresti prendere in considerazione l'utilizzo di un set ordinato invece di un hash. Anche se forse meno intuitivo in questo caso d'uso, il set ordinato ti consentirà di eseguire tutte le operazioni di cui hai bisogno. Il prezzo per usarlo, tuttavia, è la maggiore complessità di O(logN) per aggiungere/rimuovere/leggere rispetto a O(1) di Hash, ma dati i numeri la differenza non è significativa.
Per liberare il potere dell'Insieme Ordinato, utilizzerai l'ordinamento lessicografico in modo che tutti i membri dell'Insieme Ordinato dovrebbero avere lo stesso punteggio (ad es. usa 0). Ogni prodotto sarà rappresentato da un Set Ordinato, proprio come con l'Hash. I membri del Set sono gli equivalenti del campo Hash, ovvero le versioni delle personalizzazioni. Il "trucco" è costruire i membri in un modo che ti permetta di eseguire ricerche di intervallo (o invalidazioni di livello 2 se vuoi). Ecco un esempio di come dovrebbe apparire (nota che qui la chiave ProductA non è un hash ma un set ordinato):
ZADD ProductA 0 0001:0001:<JSON>
Per leggere una versione di personalizzazione, usa ZRANGEBYLEX ProductA [0001:0001: [0001:0001:\xff e dividi il JSON dalla risposta e per rimuovere un'intera personalizzazione, usa ZREMRANGEBYLEX .
