Mention something I can think of.

I think there are the following difficulties in implementing hash with expiration in redis:

Existing commands are difficult to extend the expire parameter, such as HSET key field value EX seconds or HINCRBY key field increment EX seconds cannot be realized. If new commands such as HEXPIRE field seconds are added, the user will have to use the pipeline method to combine HSET and HEXPIRE to reduce network overhead.
In order to support this feature, the expire information must be stored inside the hash structure, which will cause the RDB encoding format inside to change, and it will no longer be forward compatible.
We also need to consider the memory overhead brought by the introduction of expire, especially when our active expiration is not efficient
The hash structure supports OBJ_ENCODING_LISTPACK and OBJ_ENCODING_HT two encoding formats in the memory. In order to support expire, they need to be big modified or compromised.
Active expiration efficiency is also a problem. At present, redis uses scan to implement the active expiration of the main key. If the hash still does not support the field sorting according to expiration, it is conceivable that the field-level active expiration efficiency will be worse, but the advantage is that it is relatively simple to implement.
If we want to improve the expiration efficiency, a sorting structure such as min heap/ziplist/sort tree, etc. is necessary, but this will lead to the complexity of index maintenance. At the same time, in order to reduce the memory overhead caused by the field copy, only the pointer of the field should be used in the index, which will cause the hash to not use the OBJ_ENCODING_LISTPACK compression encoding format.
There may be other problems I didn't expect. But I think it might be a better choice to support a completely new data type.

Insisting on allow hash field expiration #6620

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions