Redis: Implement Expire on hash

Created on 28 Oct 2011  ·  44Comments  ·  Source: redis/redis

Hello, I would like to know if it's possible to set a expire time on keys of a hash ?
For example, i would like to have the list of connected members in a hash with an expiration of 5 minutes on each key.

Is it possible?

Thanks, and sorry in advance for my english.

Regards, Max

Most helpful comment

Well, I almost never want to expire an entire hash at once. So really, you're suggesting breaking up a hash into a bunch of keys. That works, but the same argument could be used to ask why you need a hash at all? There's immense value in grouping all your logically related keys together. Otherwise, you need to do that accounting through some set that stores your keys and you run into referential integrity issues. It's all doable, but it feels like a pretty big omission in redis to not support expiring individual keys in a hash. And I'm not convinced there's any value in having N different people solve it M different ways.

All 44 comments

Hi, it is not possible, either use a different top-level key for that specific field, or store along with the filed another field with an expire time, fetch both, and let the application understand if it is still valid or not based on current time.

redis 127.0.0.1:6379> hset expire:me name tom
(integer) 0
redis 127.0.0.1:6379> hget expire:me name
"tom"

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

...
...
...

redis 127.0.0.1:6379> ttl expire:me
(integer) -1
redis 127.0.0.1:6379> hget expire:me name
(nil)

so it works

I believe the request is to expire individual fields. Expiring the entire hash is the same as expiring any other key.

Yes, I've also met this requirement. Is it possible to expire individual fields?

Is there a specific problem with creating multiple hashes with different expiration times?

Well, I almost never want to expire an entire hash at once. So really, you're suggesting breaking up a hash into a bunch of keys. That works, but the same argument could be used to ask why you need a hash at all? There's immense value in grouping all your logically related keys together. Otherwise, you need to do that accounting through some set that stores your keys and you run into referential integrity issues. It's all doable, but it feels like a pretty big omission in redis to not support expiring individual keys in a hash. And I'm not convinced there's any value in having N different people solve it M different ways.

Thanks Kevin Menard & Johan Bergström. Actually I met the same scenario described here:https://github.com/antirez/redis/issues/242, and I have read comments given by Salvatore.
If I split all the fields to keys like this: hashkey:field1, hashkey:field2,.. It is difficult to manage these keys as a collection. such as querying all the fields, KEYS 'patten' is required...

Regards,
Dengchunping

This is very problematic. The reason I want to expire specific keys inside a hash is because I'm storing cached settings in the hash. I want to expire the keys automatically after I set them. at the same time, I need to be able to kill the whole hash if all of my settings have been updated. So I need the ability to get these settings in the list, and kill the list. without finding all instance of settings:whatever.

Have same problem with bjoshuanoah, now, i am using key with ttl instead of hash, e.g:
Hash: Hashname A - Key B - Value C
Key-Value: Key A_B - Value C

Is lack of this feature technically not possible or is it choice of design?

The choice of design lead to an implementation that doesn't allow an implementation.

:+1:

redis itself does not support , this function is too useful.

Until today redis did not plan to implement this functionality :-(

redis 127.0.0.1:6379> hset expire:me name tom
(integer) 0
redis 127.0.0.1:6379> hget expire:me name
"tom"

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

...
...
...

redis 127.0.0.1:6379> ttl expire:me
(integer) -1
redis 127.0.0.1:6379> hget expire:me name
(nil)

so it works

there is only one field in the hashtable, what about multiple fieleds? It would not work correly!

@oylz - I believe that the original intent of this feature request is allowing the expiry of specific fields inside the hash, not the entire key.

@itamarhaber
how aboule like this?:
hset expire:me name1 tom1
hset expire:me name2 tom2
hset expire:me name3 tom3

ttl expire:me 10

The entire hashtable(expire:me) will be expired.

@oylz We know complete hash will be expire. its working but here we are talking about one single field of any hash (as @itamarhaber explained you already). e.g In your case how can you expire name1 field after 5s, name2 after 10 and name 3 after 15 seconds ? I hope now its clear what use-case is under discussion here.

@nomi-ramzan
do you really understand? as @itamarhaber said:" I believe that the original intent of this feature request is allowing the expiry of specific fields inside the hash, not the entire key."

@nomi-ramzan
sorry, I replied to you wrong at the begin, I should reply @wheelq .
e.g:
_redis 127.0.0.1:6379> hset expire:me name tom
(integer) 0
redis 127.0.0.1:6379> hget expire:me name
"tom"

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

...
...
...

redis 127.0.0.1:6379> ttl expire:me
(integer) -1
redis 127.0.0.1:6379> hget expire:me name
(nil)

so it works_

This is 2020, Redis should look in to this

our Company has implement expire hash field function
it base redis 4.0

Providing this feature natively will be very much helpful.
Thanks.

I'm still waiting for this

unbelievable! Redis still hasn't implemented it!

the same here, would be awesome to have the ability to set expire to hash fields

+1

unbelievable! Redis still hasn't implemented it!

+1 for this feature

Having discovered the Redis world, I imagined storing the cache in this form:
1) Each hash table - is my api method
2) Rows in hash tables - a hash function of the input parameters of the method and the value is the response of the method

+1 for this feature

+1 for this feature

+1

+1

+1

+1

Is there specific reason expiring keys in hashes is not implemented ?

The reason this was never implemented yet is due to the increased complexity of time (CPU) and space (RAM) that this feature would require. That said, never say never.

Is time complexity going in the order of polynomial time ? What makes it RAM intensive though, cloning for any purpose?

I'm sure if this feature was implemented redis would get a huge boost in popularity

+1 for this feature

+1

+1

Was this page helpful?
0 / 5 - 0 ratings

Related issues

elog08 picture elog08  ·  3Comments

zerthimon picture zerthimon  ·  3Comments

mapreferee picture mapreferee  ·  3Comments

ET-CS picture ET-CS  ·  4Comments

steadyrun picture steadyrun  ·  4Comments