Tracking Issue: Towards a more redis-compatible database

[PragmaTwice]

In order to be more compatible with redis, here are commands that exist in Redis (excluding Redis Stack) but are not supported in Kvrocks:

• Add support of the command RESET #1944
• Add support of the command COPY #1945
• Add support of the command DUMP #1946
• Add support of the command EXPIRETIME #1947
• Add support of the command PEXPIRETIME #1948
• Add support of the command MIGRATE #1949
• Add support of the command MOVE #1950
• Add support of the command RENAMENX #1951
• Add support of the command SORT and SORT_RO #1952
• Add support of the command BITFIELD_RO #1954
• Add support of the command LCS #1955
• Add support of the command SSUBSCRIBE and SUNSUBSCRIBE #1958
• Add support of the command SMISMEMBER #1959
• Add support of the command ZINTER and ZINTERCARD #1983
• Add support of the command ZDIFF and ZDIFFSTORE #1984
• Add support of the command ZRANDMEMBER #1985
• Add support of the command READONLY & READWRITE #2166
• Add support of the command ASKING #2168
• Add support of the command CLUSTER RESET #2185
• ... (maybe not fully listed)

We very much welcome anyone to claim the tasks and start to contribute to Kvrocks. If you need any help during the contribution process, you can leave a message under the corresponding issue.

Also, the parts of existing commands that are incompatible with redis are worthy of attention and welcome any contribution.

• BITPOS doesn't support BIT option #1212
• Add BIT option support for BITCOUNT command #2006
• Improve the implementation of SRANDMEMBER #2014
• ... adding more

It succeed #595.

[tisonkun]

Test suite in other client impl can help.

We writes C++ unit tests and Golang cases with redis-go. IIRC redis-go runs regression tests for Kvrocks also.

I tried Redisson but still have some troubles - #1912

Perhaps also other clients in https://redis.io/resources/clients/

[jihuayu]

We can add support for BITOPS command BIT/BYTE option

• BITPOS doesn't support BIT option #1212

[git-hulk]

@jihuayu done

[judahrand]

One command which would be amazing to have would be: CLIENT TRACKING (https://redis.io/docs/latest/commands/client-tracking/). redis-py just added support for easily setting up a cache which is automatically invalidated by Redis and it would be incredible if KvRocks could do this too.

[PragmaTwice]

One command which would be amazing to have would be: CLIENT TRACKING (https://redis.io/docs/latest/commands/client-tracking/). redis-py just added support for easily setting up a cache which is automatically invalidated by Redis and it would be incredible if KvRocks could do this too.

Yeah client-side caching is in our roadmap. cc @git-hulk

[git-hulk]

Yes, one obstacle we need to overcome is knowing if a key has expired.

[PragmaTwice]

Yes, one obstacle we need to overcome is knowing if a key has expired.

For me I think we can move the responsibility of expiration detection from the server to clients. i.e. clients should store the key-value cache as well as the TTL.

[git-hulk]

Yes, one obstacle we need to overcome is knowing if a key has expired.

For me I think we can move the responsibility of expiration detection from the server to clients. i.e. clients should store the key-value cache as well as the TTL.

For Redis client-side caching, it will send an invalid message notification once it's expired or evicted due to the memory policy. I'm not sure whether most SDKs will add a default TTL for keys or not. If yes, it should be fine. Or it should be a problem since the expiration needs to depend on the compaction timing.

[PragmaTwice]

Yes, one obstacle we need to overcome is knowing if a key has expired.

For me I think we can move the responsibility of expiration detection from the server to clients. i.e. clients should store the key-value cache as well as the TTL.

For Redis client-side caching, it will send an invalid message notification once it's expired or evicted due to the memory policy. I'm not sure whether most SDKs will add a default TTL for keys or not. If yes, it should be fine. Or it should be a problem since the expiration needs to depend on the compaction timing.

It's hard for kvrocks to send notifications on expiration, but for any other writing we can notify, of course. We need to state this point to client implementations to let them store the TTL.

It's also recommended in the Redis documentation for client implementation hints:

Handling TTLs: make sure you also request the key TTL and set the TTL in the local cache if you want to support caching keys with a TTL.

[git-hulk]

It's also recommended in the Redis documentation for client implementation hints:

Yes, that makes sense. I will go through the Redis server and its SDK implementation for client-side caching when I get time. And then propose a discussion or design.