ristretto VS theine-go

1. Unfortunately, ristretto has been showing hit ratio around 0 on almost all traces for a very long time now and the authors don't respond to this in any way. Vitess for example has already changed it to another cache. Here are two issues about it: https://github.com/dgraph-io/ristretto/issues/346 and https://github.com/dgraph-io/ristretto/issues/336. That is, ristretto shows such results even on its own benchmarks. You can see it just by running hit ratio benchmarks on a very simple zipf distribution from the ristretto repository: https://github.com/dgraph-io/ristretto/blob/main/stress_test.... On this test I got the following:

That's exactly how Userify[0] used to work. (when it was Python; now that it's a Go app, we do the caching in memory using Ristretto[1]).

0. https://userify.com (team ssh key management/sudo authz)

1. https://github.com/dgraph-io/ristretto

I also do some hit ratio benchmarks and Theine's results are much better than Ristretto. See results in README: https://github.com/Yiling-J/theine-go#hit-ratios

If you know Caffeine(Java)/Ristretto(Go)/Moka(Rust), you know what Theine is. Python deserves a good in-memory cache library.

Thanks for sharing. There are a lot of options for embedded in-memory caches: https://github.com/dgraph-io/ristretto https://awesome-go.com/caches/ Do you have any comparisons or details on how your project has a different approach?

I made Cacheme years ago, which support redis and synchronous API only. Then I switch to Go and found that there are some awesome cache projects in Go(ristretto, gocache...), I also made my own Cacheme go version: cacheme-go. After trying asyncio and type hint, I think it's time to rewrite my old Cacheme.

zcached is an in-memory key-value cache exposing a memcached ASCII protocol-compatible interface, built on pluggable cache engines like Ristretto and freecache [0].

It's not performance-competitive with memcached, especially at higher thread counts. That said, it achieves about 1.1M ops/s, but at significantly higher P99 and P999 latency (as measured by memtier). See [1] and [2] for benchmark results from my 7950x-based workstation.

Disclaimer: This is a hobby project created for fun while hacking over the holidays. zcached is not a commercial product and never will be. Don't use it in production; consider this a technology demo more than anything.

I don't expect the source code to build outside of my environment, but for those interested in playing with it, binary artifacts are available at [3]. Try `zcached --address tcp:localhost:11211`.

[0] https://github.com/dgraph-io/ristretto, https://github.com/coocood/freecache

While I never used dgraph, I do use badger and ristretto and am similarly in a bind over their long-term survival (moreso badger than ristretto)...

There are also different packages used as a wrapper on top of the Go map based on what your requirements are (storing a lot of data) https://github.com/allegro/bigcache or (need performance) https://github.com/dgraph-io/ristretto. For basic use-cases, the standard Go map should be enough. Just keep in mind whether you need concurrent access to your data structure, in which case you should guard your map with a mutex .

In fact, lock-free queues have several problems at once, which prompted me to give up on them almost immediately.

1. Yes, S3-FIFO can be implemented using lock-free queues, but the problem is that each write to a filled cache using this design will cause a large number of additional atomic operations not friendly to the processor's cache, while bp-wrapper on the contrary amortizes this load. And reading with frequency update on hot entries can have a bad effect on performance. In many ways this is exactly what the last posts in my discussion with Ben are about (not really about this, but the current problem with otter read speed is caused by a similar problem). https://github.com/Yiling-J/theine-go/issues/29#issuecomment...

2. But the main problem for me is not even that. Lock-free queues work fine as long as you only need to support Get and Set operations, but as soon as you want to add features to your cache, the complexity of the implementation starts to increase, and some features are very hard to add to such a structure. Also, improving the eviction policy is under a big question mark, because not only do you have to think about how to improve the eviction policy, but also how to avoid locks while doing so or how not to slow down the implementation with your improvements. BP-Wrapper has no such problems at all, allows you to use any eviction policy and focus on improving different parts of your cache independently of each other.

CacheStore is an interface so I can use a different local cache instead? For example my adaptive cache package Theine, I think the hit ratio will be much higer than the default LRU one.

0.2.0 add removal callback and loading cache(with thundering herd protection), take a look: https://github.com/Yiling-J/theine-go

Theine: https://github.com/Yiling-J/theine-go