Kvrocks: Redis-compatible distributed key value NoSQL database(kvrocks.apache.org)
kvrocks.apache.org
Kvrocks: Redis-compatible distributed key value NoSQL database
https://kvrocks.apache.org/
16 comments
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.
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.
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.
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.
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
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.
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.
The list of supported commands looks quite impressive https://kvrocks.apache.org/docs/supported-commands#script-co...
The GitHub Readme seems easier to understand: https://github.com/apache/kvrocks?tab=readme-ov-file
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
Also, RocksDB? Why? Your data is just going to go there to vanish forever, never to be seen again
> 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.
If you're storing anything in Redis or a Redis-like database that you can't recover from loosing, you're using Redis wrong.
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)
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)
Kronotop: Redis-compatible, transactional document store backed by FoundationDB
- https://news.ycombinator.com/item?id=42771403
> 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++.
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 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.
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.
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.
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.
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.
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.