Redis: Implémenter Expire sur hachage

Salut, il n'est pas possible, soit d'utiliser une clé de niveau supérieur différente pour ce champ spécifique, soit de stocker avec le fichier un autre champ avec une date d'expiration, de récupérer les deux et de laisser l'application comprendre si elle est toujours valide ou non basée sur heure actuelle.

redis 127.0.0.1:6379> hset expire:me nom tom
(entier) 0
redis 127.0.0.1:6379> hget expire:me nom
"à M"

redis 127.0.0.1:6379> expire expire:me 10
(entier) 1
redis 127.0.0.1:6379> ttl expire:me
(entier) 8

...
...
...

redis 127.0.0.1:6379> ttl expire:me
(entier) -1
redis 127.0.0.1:6379> hget expire:me nom
(néant)

donc ça marche

Je crois que la demande est d'expirer des champs individuels. L'expiration de l'intégralité du hachage est identique à l'expiration de toute autre clé.

Oui, j'ai également satisfait à cette exigence. Est-il possible d'expirer des champs individuels ?

Existe-t-il un problème spécifique avec la création de plusieurs hachages avec des délais d'expiration différents ?

Eh bien, je ne veux presque jamais expirer un hachage entier à la fois. Donc vraiment, vous suggérez de diviser un hachage en un trousseau de clés. Cela fonctionne, mais le même argument pourrait être utilisé pour demander pourquoi vous avez besoin d'un hachage ? Il y a une immense valeur à regrouper toutes vos clés logiquement liées ensemble. Sinon, vous devez effectuer cette comptabilité via un ensemble qui stocke vos clés et vous rencontrez des problèmes d'intégrité référentielle. Tout est faisable, mais cela ressemble à une assez grosse omission dans Redis de ne pas prendre en charge l'expiration des clés individuelles dans un hachage. Et je ne suis pas convaincu qu'il y ait une quelconque valeur à ce que N personnes différentes le résolvent de M différentes manières.

Merci Kevin Ménard et Johan Bergström. En fait, j'ai rencontré le même scénario décrit ici : https://github.com/antirez/redis/issues/242, et j'ai lu les commentaires donnés par Salvatore.
Si je divise tous les champs en clés comme ceci : hashkey:field1 , hashkey:field2 ,.. Il est difficile de gérer ces clés comme une collection. comme l'interrogation de tous les champs, KEYS 'patten' est requis...

Salutations,
Dengchunping

C'est très problématique. La raison pour laquelle je veux faire expirer des clés spécifiques dans un hachage est que je stocke les paramètres mis en cache dans le hachage. Je veux faire expirer les clés automatiquement après les avoir définies. en même temps, je dois pouvoir tuer tout le hachage si tous mes paramètres ont été mis à jour. J'ai donc besoin de la possibilité d'obtenir ces paramètres dans la liste et de tuer la liste. sans trouver toutes les instances de paramètres : peu importe.

J'ai le même problème avec bjoshuanoah, maintenant, j'utilise key avec ttl au lieu de hash, par exemple:
Hash : Hashname A - Clé B - Valeur C
Clé-Valeur : Clé A_B - Valeur C

L'absence de cette fonctionnalité est-elle techniquement impossible ou s'agit-il d'un choix de conception ?

Le choix de conception conduit à une implémentation qui ne permet pas une implémentation.

https://github.com/antirez/redis/issues/1042#issuecomment-143109286

:+1:

redis lui-même ne prend pas en charge , cette fonction est trop utile.

Jusqu'à aujourd'hui, redis n'avait pas prévu d'implémenter cette fonctionnalité :-(

redis 127.0.0.1:6379> hset expire:me nom tom
(entier) 0
redis 127.0.0.1:6379> hget expire:me nom
"à M"

redis 127.0.0.1:6379> expire expire:me 10
(entier) 1
redis 127.0.0.1:6379> ttl expire:me
(entier) 8

...
...
...

redis 127.0.0.1:6379> ttl expire:me
(entier) -1
redis 127.0.0.1:6379> hget expire:me nom
(néant)

donc ça marche

il n'y a qu'un seul champ dans la table de hachage, qu'en est-il des champs multiples ? Cela ne fonctionnerait pas correctement !

@oylz - Je pense que l'intention initiale de cette demande de fonctionnalité est d'autoriser l'expiration de champs spécifiques à l'intérieur du hachage, pas la clé entière.

@itamarhaber
comment aboulé comme ça?:
hset expire:moi nom1 tom1
hset expire:me name2 tom2
hset expire:moi nom3 tom3

ttl expire:moi 10

La table de hachage entière (expire:me) sera expirée.

@oylz Nous savons que le hachage complet expirera. cela fonctionne mais nous parlons ici d'un seul champ de n'importe quel hachage (comme @itamarhaber vous l'a déjà expliqué). Par exemple, dans votre cas, comment pouvez-vous expirer le champ name1 après 5s, name2 après 10 et name 3 après 15 secondes ? J'espère que maintenant il est clair quel cas d'utilisation est en cours de discussion ici.

@nomi-ramzan
comprenez-vous vraiment ? comme l'a dit @itamarhaber : " Je pense que l'intention originale de cette demande de fonctionnalité est d'autoriser l'expiration de champs spécifiques à l'intérieur du hachage, pas la clé entière ."

@nomi-ramzan
désolé, je vous ai mal répondu au début, je devrais répondre @wheelq .
par exemple:
_redis 127.0.0.1:6379> hset expire:me nom tom
(entier) 0
redis 127.0.0.1:6379> hget expire:me nom
"à M"

redis 127.0.0.1:6379> expire expire:me 10
(entier) 1
redis 127.0.0.1:6379> ttl expire:me
(entier) 8

...
...
...

redis 127.0.0.1:6379> ttl expire:me
(entier) -1
redis 127.0.0.1:6379> hget expire:me nom
(néant)

donc ça marche_

Nous sommes en 2020, Redis devrait s'en occuper

notre société a mis en œuvre la fonction de champ de hachage d'expiration
il base redis 4.0

Fournir cette fonctionnalité nativement sera très utile.
Merci.

j'attends toujours ça

incroyable! Redis ne l'a toujours pas implémenté !

la même chose ici, ce serait génial d'avoir la possibilité de définir expirer sur les champs de hachage

+1

incroyable! Redis ne l'a toujours pas implémenté !

+1 pour cette fonctionnalité

Ayant découvert le monde Redis, j'ai imaginé stocker la cache sous cette forme :
1) Chaque table de hachage - est ma méthode api
2) Lignes dans les tables de hachage - une fonction de hachage des paramètres d'entrée de la méthode et la valeur est la réponse de la méthode

+1 pour cette fonctionnalité

+1 pour cette fonctionnalité

+1

+1

+1

+1

Y a-t-il une raison spécifique pour laquelle l'expiration des clés dans les hachages n'est pas implémentée ?

La raison pour laquelle cela n'a encore jamais été mis en œuvre est due à la complexité accrue en temps (CPU) et en espace (RAM) que cette fonctionnalité nécessiterait. Cela dit, ne dites jamais jamais.

La complexité temporelle est-elle de l'ordre du temps polynomial ? Qu'est-ce qui le rend gourmand en RAM, le clonage à quelque fin que ce soit ?

Je suis sûr que si cette fonctionnalité était implémentée, redis gagnerait en popularité.

+1 pour cette fonctionnalité

+1

+1