It looks like a normal database to me: disk storage for most of the data, and some cache in memory to speed up read queries. Everything is customizable.
I'm still waiting for a nice way to deploy it in a Kubernetes cluster, like a Helm Chart to easily setup a cluster with primaries and replicas. Also, the lack of keys eviction like LRU is problematic for us in some cases, it would be a nice addition.
KVRocks doesn’t expose it directly right now so it requires code changes, but so far I have had good success with FIFO compaction. When an sstable gets old enough, it just gets dropped.
I tested kvrocks about a year ago and don't have the benchmarks to hand anymore, but if I remember correctly kvrocks had a ~60% performance penalty compared to Redis, but depends on your disk speeds.
Also, RocksDB? Why? Your data is just going to go there to vanish forever, never to be seen again
If you're storing anything in Redis or a Redis-like database that you can't recover from loosing, you're using Redis wrong.
Redis Alternative at Apache Software Foundation Now Supports RediSearch and SQL - https://news.ycombinator.com/item?id=40812879 - June 2024 (3 comments)
Show HN: Kvrocks – High Performance SSD Redis which supports replication and HA - https://news.ycombinator.com/item?id=20827111 - Aug 2019 (3 comments)
curious why they did pointer in-out param instead of references here. They could also just return these values as well? in-out param style is something I'd expect in C but not in modern C++.
I tried finding some examples but they don't even have an `examples` directory on GitHub.
So I just assume that this is RedisJSON + per namespace passwords?
Also no info on drivers, so does this mean that drivers compatible with Redis should be used with this?
If it is focused on the JSON part of Redis, then I might start using it as a replacement.
As for the drivers compatible, if you mean "clients", in our case we use the official Python Redis client with Kvrocks and it works perfectly with the commands we use.
