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.
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
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)
> 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++.
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.
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.