Kvrocks: Redis-compatible distributed key value NoSQL database
16 comments
·January 21, 2025hivacruz
mnutt
I’ve been testing kvrocks as a replacement for a Scylla use case where we have TBs of data and uniform TTLs. In many of these LSM dbs, compaction is the thing that really kills throughput, making TTLs (or really any updates/deletes) difficult.
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.
hipadev23
As this is backed by RocksDB, does that mean it’s disk-based? I’ve been looking for a way to utilize Redis but with hot (memory) and warm (nvme disk) mechanisms to boost my capacity affordably.
mnutt
Yes, there are a bunch of redis+disk projects out there, one big consideration is the size of your values: some must hold all keys in memory and only offload values to disk, while others (kvrocks, other rocksdb dbs) can offload both keys and values to disk, with some other tradeoffs.
ChocolateGod
Yes it is only limited by disk usage but it does have an in-memory cache.
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.
italodev
There are several redis-compatible disk backed solutions, https://github.com/OpenAtomFoundation/pika is the first that comes to mind but im positive there are others
tbarbugli
The list of supported commands looks quite impressive https://kvrocks.apache.org/docs/supported-commands#script-co...
williamstein
The GitHub Readme seems easier to understand: https://github.com/apache/kvrocks?tab=readme-ov-file
DiabloD3
It seems to be written in C++. Did some corporation just dump this on Apache so they could write this off on their taxes?
Also, RocksDB? Why? Your data is just going to go there to vanish forever, never to be seen again
ChocolateGod
> 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.
dang
Related. Others?
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)
throwaway_031
Kronotop: Redis-compatible, transactional document store backed by FoundationDB - https://news.ycombinator.com/item?id=42771403
ruby_react_
> Status Execute(engine::Context &ctx, Server srv, Connection conn, std::string *output)
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++.
qwertox
I am confused. "key value NoSQL". Is it a key-value store (that is obviously not SQL), which is capable of doing some rudimentary JSON store/retrieve operations like RedisJSON? Because for me a NoSQL database is a document-based, schema-less database like MongoDB.
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.
hivacruz
I don't think it is "focused" on the JSON part of Redis, they have added a lot of commands from Redis, not only JSON. They are also working on storing vectors too for instance.
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.
lucianbr
So DynamoDB would not fit your definition of NoSQL? I think it would, for most people. It's just a much larger category than Mongo and things like it.
We use it for a year now in production and so far so good. We couldn't handle anymore having huge instances with a lot of RAM to hold data in Redis.
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.