Support field level expire/TTL for hash, set and sorted set

[xingbowang]

The problem/use-case that the feature addresses
My customer has a use case where each element within a Hash/Set/Sorted Set data type would have different TTL. Right now, it is done by manually write client side logic or lua script. It would be great if Valkey could support element level TTL, so the element get expired independently.

Description of the feature

Valkey would allow client to specific different TTL value at element level.

Alternatives you've considered

None.

Additional information

None.

[hpatro]

Historically this was never added due to the amount of complexity. If that still holds true, I think we should evaluate if this fits more as a separate command/modules to incorporate element level TTL for a key.

Note: Tair* has implemented some of these features in a module.

[zvi-code]

sounds like ideally the expiry logic should be embedded into the dict itself [and than can be easily reused for all dict users], have we evaluated such an option? [instead of the additional expiry dict]
we could add expiry existence bitmap on the dict buckets [bit for bucket] to have optimized iterator over volatile keys, at some small cost at rehashing, or even ttl range bitmap to group similar ttl keys

[madolson]

@zvi-code I documented a bit of that here: #169 (comment). Embedding the TTL into the dict itself is OK and allows you to do lazy expiration very fast. Active expiration is a lot more painful though, since you need some way to actively go find those values which only somewhat works.

[zvi-code]

Thanks @madolson for sharing, I'll take a look. I think with resonable assumptions it could be easier. The assumptions are about how tight do we want to be on eviction time, at least intuitively I feel, it's perfectly ok to be accurate at a multi second granularity[have grouping of some kind at a seconds granularity]. But I'll post my thoughts on the other thread, it looks very interesting!