2023 Planning(Want your feedback)

[git-hulk]

Hello everyone, Kvrocks community starts the 2023 planning now. We are very eager to listen to the voice of the community.

Can help to leave your thoughts(ideas/feature requests/...) here, the community will also publish the roadmap of 2023 according to your feedback in GitHub later.

[DenizPiri]

Adding WATCH support to the roadmap would be very nice. #315
This would allow transactional work to be done on single or multiple keys via optimistic concurrency.

[git-hulk]

Thanks for your feedback.

[PragmaTwice]

From my side, some of the most popular features:

• k8s support
• kvrocks controller
• JSON support
• HyperLogLog support

[mapleFU]

What do you mean by "JSON support", can you give me some example? Like https://redis.io/docs/stack/json/ ?

[PragmaTwice]

Yeah, you are right.

[mapleFU]

Thanks, that would be flexible and useful! (But maybe would introduce some library like jsonb)

[git-hulk]

Yes, JSON structure is very useful for many users. RedisJSON is also the most popular(download) module in the Redis community: https://redis.com/blog/index-and-query-json-docs-with-redis. Thanks for @ShooterIT reference.

[git-hulk]

I'm looking forward to the below features from myself:

• k8s support
• better controller
• JSON
• watch/unwatch support

[jjz921024]

Support semi-sync like mysql or min-slaves-to-write like redis or min.insync.replicas like kafka for consistency

[git-hulk]

Thanks for your feedback

[adulau]

Maybe it's a bit too much but I would love to see RedisBloom in kvrocks and similar data structures.

The one really missing for me is zinter to return the intersection directly to the client without storing it ;-)

[git-hulk]

Thanks, @adulau

[imfantuan]

client cache 🙋🏻‍♀️

[git-hulk]

Thanks for your feedback. It makes sense even though this feature may involve massive work like supporting the RESP3.

[git-hulk]

Client caching doesn't have to depend on RESP3, thanks for @PragmaTwice correcting this. Refer: https://redis.io/docs/manual/client-side-caching/

[usrtax]

resp3 support （ and resp3 support in lua script ）

[git-hulk]

Thanks for your feedback.

[usrtax]

Function commands

[kesavkolla]

functions using wasi so that we can write fubnctions using any web assembly.

[git-hulk]

Sure, thanks for your feedback. Already added it into roadmap's backlog: Kvrocks 2025 Roadmap

[kesavkolla]

RedisGraph support in kvrocks

[aleksraiden]

In my mind, with great support by @torwig we do:

• 64-bit support in INCR/DECR command
• 64-bit support of Hash / Stream length
• RedisTimeSeries module porting with some extensions above an original
• Very glad to support WebAssembly usage from this thread (@kesavkolla )
• Port of Redis module TariHash/TariZset (multi-dimension hash and sorted set)
• RedisRaft
• Support all of major RocksDB release and other dependency

[GoodManWEN]

Although kvrocks is still being intensively updated and does not seem to claim to be a ‘mature’ product, there have been no crashes or bugs during a month of my use and stress testing. In my opinion, it may already be quite mature. I think a friendly configuration document (stating common configurations and usage notes, as well as detailed API interfaces) would be of great help in promoting the product.

[git-hulk]

Yes, many companies are using Kvrocks in production for years, and even more than 10,000 instances AFAIK. So I think the Kvrocks is already production-ready many years ago.

I think a friendly configuration document (stating common configurations and usage notes, as well as detailed API interfaces) would be of great help in promoting the product.

Kvrocks API is expected to be compatible with Redis, so I think https://redis.io/ is enough. For the configuration and usage notes, welcome to create a discussion to share what you want to know. And contribute docs or blogs to https://kvrocks.apache.org is always welcome, repository is: https://github.com/apache/incubator-kvrocks-website.

[GoodManWEN]

For example, I think it would be good to remind in the configuration document that “please use an x509 certificate with a length of 2048 bits or more to enable TLS” (because I tried to reduce the length of the certificate to get some slight performance improvement. In my local area network scenario, I only need the feature of TLS to ensure that the connection is not wrong, and I don’t have too much requirement for its security feature. However, reducing the length makes my service unable to start). In addition, it would be better if there were some examples of row cache configuration items. These are some problems I have encountered in configuration recently. I think it would be better if there were explanations in the document.

[qrdl]

I would be nice to have TLS for replication

[git-hulk]

Sure, thanks for your feedback. Have added it to the backlog and will convert it to an issue when someone has time to take this.

[gofort]

@git-hulk can you suggest any other ways of secure replication while TLS is not supported?

[PragmaTwice]

I think there is hardly an elegant way to make replication communicate securely without TLS. And I think it is not hard to support since we have already support TLS for client connections. If there is no one want to take this, I will do it (but maybe a bit later).

[tisonkun]

@git-hulk @ShooterIT @PragmaTwice it's close to the end of year. Let's revisit this thread, make a conclusion and prepare for the next year.

[git-hulk]

@tisonkun Thanks for your kind reminder. I will prepare the roadmap retrospection at the beginning of December.

[git-hulk]

Summary of 2023

For more details, please visit https://kvrocks.apache.org/blog/kvrocks-2023-in-review. Thanks for @PragmaTwice @mapleFU review and improvements.

The key progresses in 2023:

• JSON data structure
• BloomFilter data structure
• Watch/Unwatch command
• Lua Functions
• Replication with TLS
• Allow to enable 64-bit expiration time (precision is in milliseconds instead of seconds), and the length of List/Hash/Set/ZSET/Stream can also be extended from 32 to 64 bits.
• Allow to use LOAD RDB command to load the Redis RDB file
• Allow to adjust the number of Worker threads dynamically
• Enable Namespace replication
• Support RESTORE command

What we are still working on:

• RESP3 protocol, more information can be found in Tracking issue: Support RESP3 in Kvrocks
• Kvrocks in Kubernetes, kvrocks-operator is ready to test now but still needs more work to make it production-ready
• Controller to manage the cluster, the API part of kvrocks-controller is finished, but we believe it's not enough users before the UI part is ready

What is still in the backlog:

• Allow to use the Raft protocol for replication
• HyperLogLog
• RedisGraph, no plan to support since the Redis community deprecates it
• Semi-sync replication
• Client-side caching