RedisRaft: I haven’t watched talk yet (busy hacking and it’s Enterprise only feature), one question keeps bugging me after seeing the title. Why do you need Raft in Redis ecosystem? you already have gossip protocol as part of cluster, would not it be better to use something like https://substrate.dev/docs/en/pre-v2.0-3e65111/overview/glossary#grandpa and have “internal blockchain” which will act like CMDB (Configuration Management Database) and take care of resilience, security and compliance? You would not need to vote as your would have up to date state of the system (I think you already do it something similar in redis cluster) and penalize nodes for underperformace or lack of storage.
@AlexMikhalev The goal with RedisRaft (which will be open source, not an Enterprise-only featue) is to provide strong consistency (strict serializability) across a set of Redis servers.
I’m not familiar with GRANDPA but from a quick look it addresses a different set of problems. In our case, we have no byzantine actors and require neither accountability nor a probabilistic approach (due to scale).
Thank you for your answer.
My understanding Raft will be ideal and performant for nodes <1000. I have a scenario in mind where I would like to deploy Redis on Edge - may be embed into product (app or device, or IoT device) and link to central Redis cluster. This is a direction of travel for Coachbase and Mongo (with Realm). Number of nodes very easily can reach hundreds or thousands.
In this instance from app perspective I would like to be able to find out:
- number of most stable masters in my region/vicinity
- be able to audit node presence - when they were online/offline, so I can investigate cause, by narrowing down time and to node to be investigated: part of resilience/security concerns, if node went offline and then back online, has it been tampered with? Can I trust the data this node sends?
Traditional solution for (1) is to use some form of Placement Driver https://github.com/pingcap/pd, but I don’t think it will scale to scenario above.
Raft (and comparable algorithms) is typically deployed across an ever smaller number of nodes (generally even less than 10).
What you describe sounds like an interesting and challenging scenario, but indeed very different than what RedisRaft was created for.
@AlexMikhalev, Refer below link you may find it interesting:
RedisEdge from Redis Labs is a purpose-built, multi-model database for the demanding conditions at the Internet of Things (IoT) edge. It can ingest millions of writes per second with <1ms latency and a very small footprint (<5MB), so it easily resides in constrained compute environments. It can run on a variety of edge devices and sensors ranging from ARM32 to x64-based hardware. RedisEdge bundles open source Redis (version 5 with Redis Streams) with the RedisAI and RedisTimeSeries modules, along with RedisGears for inter-module communication.