dgraph-io / ristretto

A high performance memory-bound Go cache

Home Page:https://dgraph.io/blog/post/introducing-ristretto-high-perf-go-cache/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support TTL and reloadData

tuanpavn opened this issue · comments

Please add TTL and loadData function into config so it can auto reload an item if it is expired.

Ttl eviction is highly valuable!

We can do TTL based expiry. But load on TTL seems like a cumbersome design.

Agreed, just invalidate items due to TTL and let the client decide.

hello, could I ask when would you plan to add the ttl feature? I think it is necessary

commented

Yes we need ttl

commented

For example, I want than 1 key living 10second and after reload

Will be working on this over the next few days.

commented

Will be working on this over the next few days.
May I ask when the master can join the ttl function?

commented

If I may join the discussion... It might be worth considering adding automated purging of expired items.

Ristretto currently seems to be focusing on a scenario where there is a huge amount of data, only a portion of which can be stored in pre-defined size of cache, and it is stored forever (i.e. MaxCost is reached quickly; some additional keys are tracked - NumCounters).

However, many use-cases require a TTL-driven cache, whereby you have to / are happy to cache everything as long as ... e.g. it is max 5 minutes old (e.g. for operations which tend to always be resolved within 1-2 minutes). Hence you would expect the MaxCost to be large (just in case ever needed) but the average cache size would be minimal. A go routine checking expiry times and deleting entries would be needed - and highly appreciated.

I would be happy to help with coding this. Currently it seems like karlmcguire and caofengl are already on it, but feel free to reach out to me if some extra help is needed.

I think this was the original intent. wasn't it?

commented

My understanding was that the original intention was to merely add TTL as an eviction criterion, i.e. to remove expired items only when, and only to the extent that a space needs to be made for, a new item. But if a routine cleanup is already being considered then great.

@karlmcguire any update on this?

@barkanido This was just merged recently. See PR #122

Re-opening since only the TTL part is done. I am not sure what the status of the reload function is.

Just noticed that Manish didn't agree with the need of a reload function. I think it's a bad idea too. If you need to reload an item immediately after it's expired the client should handle it.