Support Redict instead of Redis

[captainepoch]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
Redis has been relicensed to an issue that could cause problems in the future.

Describe the solution you'd like
I propose to support redict instead of Redis as soon as the 7.3.0 release is available to everyone, after the forking process is completed. This will ensure that FOSS is always used into Nextcloud.

Describe alternatives you've considered
No alternative besides Redict.

Additional context
No additional context is needed.

[solracsf]

Just for the record:

[captainepoch]

I'm aware, but since this change was just out of the blue, I don't trust Redis anymore. Thus, suggesting this.

Nevertheless, thank you for putting it for the record, @solracsf :D

[solracsf]

Sure! If i read correctly, Redict is a fork of actual Redis (7.2.4) so, basically, it will comunicate the same way, using the same (actual) commands : GET, DEL, AUTH, KEYS... so, basically, anything, Nextcloud included, that actually communicates with Redis, will also be compatible with Redict, am I wrong?

Just like Dragonfly or KeyDB, for example. Nextcloud doesn't (offically) supports these, but they work with Nextcloud, because they use the same protocol and commands than Redis does.

\EDIT/ confirmed here: https://redict.io/docs/redis-compat/

[captainepoch]

I was about to reply that you're right, it's a fork of the 7.2.4 version. However, as stated at the announcement, it will diverge from the Redis codebase, and also from other Redis' forks. Also, and I quote:

No effort will be made to remain compatible with future versions of Redis® SAL.

Redict announcement, section "Future changes".

Also, it's worth it to note the relation with other forks.

[J0WI]

I'd rather support more caching backends than just removing Redis in favour of another.

Some more implementations:

• https://aerospike.com/
• https://docs.keydb.dev/
• https://dragonflydb.io/
• https://kvrocks.apache.org/
• https://microsoft.github.io/garnet/
• https://redict.io/
• https://valkey.io/

[AlexStocks]

PikiwiDB(Pika): Forever Partners of Redis

Since March 20th, in response to Redis's announcement to adopt SSPL and RSAL for protecting its commercial interests, a series of projects such as KeyDB, Dragonfly, Valkey, Redict, and Garnet have voiced their intentions to become alternatives to Redis.

Since 2015, as one of the first projects to open-source on Redis protocol built on RocksDB, PikiwiDB (formerly known as Pika) has explicitly stated its intention not to replace Redis but to serve as a vital complement. It actively seeks to establish a good cooperative relationship with Redis. Additionally, PikiwiDB remains open to collaboration with other projects claiming to be the "best alternatives to Redis."

PikiwiDB(Pika) Product Matrix

• Due to trademark issues, the Pika project will be promoted under the name PikiwiDB(Pika) in the future, with its official repository located at https://github.com/OpenAtomFoundation/pika.

• The PikiwiDB project, with its repository at https://github.com/OpenAtomFoundation/pikiwidb, is built on the Raft protocol, compatible with the Redis protocol. It is a large-scale key-value storage database suitable for scenarios requiring strong consistency, such as storing metadata of up to 10TiB.

Solutions to Redis Challenges

When Redis's memory usage exceeds a specific threshold (such as 16GiB), issues such as limited memory capacity, single-threaded bottlenecks causing blocking, long startup and recovery times, and high memory hardware costs may arise. PikiwiDB(Pika) continues to focus on the "disk-enhanced Redis" direction, enhancing product performance around the following technical points:

• Large Capacity Storage: Even with data exceeding 1TiB, high availability is maintained, with PikiwiDB(Pika) based on disk storage.
• High-Level Data Security: Ensuring real-time data writes to disk, providing reliable data persistence.
• Efficient Space Utilization: Implementing a mixed storage scheme for separating hot and cold data, improving storage space utilization.
• Strong Consistency: Through the Raft consensus algorithm, data consistency is ensured.
• Outstanding Elastic Scalability: Developing a Serverless version to achieve features such as compute and storage separation, multi-tenancy, ensuring data replicas can rapidly scale up or down in seconds.

Community

The PikiwiDB(Pika) open-source community invites your participation and support. For any questions, feedback, or suggestions, please contact us through the following channels:

• Telegram discussion group: https://t.me/+gMlTzNacOF1iMTM1
• WeChat community: Search for "PikiwiDB" and add it as a friend, and it will invite you to join the community WeChat group.

[captainepoch]

I'd rather support more caching backends than just removing Redis in favour of another.

Some more implementations:

* https://aerospike.com/

* https://docs.keydb.dev/

* https://dragonflydb.io/

* https://kvrocks.apache.org/

* https://microsoft.github.io/garnet/

* https://redict.io/

* https://valkey.io/

I also see this as a good idea, to be honest, so users can have more options!