Expiring keys

[olanod]

Anyone building caches or a similar stores where it makes sense to add a time to live to the entries would benefit from this. Also a way to refresh the expiration would be nice if one wants to delete things that have been inactive for a determined amount of time.

[spacejam]

This is one of the more common feature requests that I don't believe is something that should be included in the core of sled itself.

The reason is that it adds significant space and compute overhead. Even if it's just one extra byte for a non-present expiration when every key is stored on disk, that could still be quite a significant cost at higher scales. When keys are known to be temporary, the effort to evict them can be pretty expensive. Only a small subset of use cases benefit from expiring keys, and I feel it's more appropriate to implement this as a layer on top of sled by adding your own optional timers as a prefix or suffix to your values. You can use IVec::subslice to avoid copying the rest to a new vec or something for use in your application.

When I managed large numbers of redis instances, key expiration was a constant source of pain. It seems like something that they are still twiddling with today. https://blog.twitter.com/engineering/en_us/topics/infrastructure/2019/improving-key-expiration-in-redis.html (still not merged into main branch)

I think I do need to add a "features we do not support" section though that explains this in a more visible place.