IceFireDB VS ristretto

IceFireDB https://github.com/gitsrc/IceFireDB

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 .