cmo
ostinelli
The library behind it,
ra, implements raft consensus algorithm so it’s consistent.
The decision is consistent, but the data still needs to propagate to the cluster if I’m understanding this correctly. If so, wouldn’t this make it eventual consistent?
ostinelli
It’s an on-disc database if I’m not mistaken.
fabriziosestito
The decision is consistent, but the data still needs to propagate to the cluster if I’m understanding this correctly. If so, wouldn’t this make it eventual consistent?
No, because Raft will wait for the majority of nodes to have replied to the append entry call prior acking to the client. If nodes cannot reach a majority it will not handle the write request.
ostinelli
majority ≠ all. The question is whether, during a transaction, some nodes might be updated and others not yet when a read operation takes place. If reads can temporarily return different values while waiting for propagation, it would be eventually consistent, not strongly consistent. This has nothing to do with the decision mechanism which provides consistency, but with the propagation (eventual vs strong).
I simply don’t know what is the mechanism Raft implements to avoid such a case, hence my question.
fabriziosestito
The read and writes always pass through the leader, raft ensures the strongest form of consistency (linearizability).
I can only suggest to read the Raft paper and see if it fits whatever use-case scenario you have in mind.
ostinelli
Ok then, that’s the answer: Raft uses leader election for both writes and read operations. It’s a choice. 
IvanR
@ostinelli is it a bad idea to ask you to run Yahoo! Cloud Serving Benchmark (YCSB) Home · brianfrankcooper/YCSB Wiki · GitHub on Ram to compare with other solutions (like Redis, etc)?
Like this one Benchmark (YCSB) numbers for Redis, MongoDB, Couchbase2, Yugabyte and BangDB - High Scalability -
sebp
If it can help for inspiration, other people invested a lot of time building databases on top of Raft to provide performances, scale and consistency: Cockroach DB folks did a good job at explaining their design. They organize the data in “ranges”, stored within Raft member groups (the idea is to not have a single group for all the data, to spread the impact of members joining or leaving to only subsets of data), it also spreads the load to many raft leaders (one leader for each range) to distribute the load.
You can read more about in their docs Replication Layer (all that range thing is described with more details in the cockroach University learning modules)
It’s not Elixir/Erlang, but these ideas are language agnostic.
ostinelli
Are all of the database in this benchmark strongly consistent? It feels a little like comparing apple and peers. For instance BangDB has a tunable consistency. My simple library requires 100% confirmation, and also copies all of the data on every node, which of course comes with a cost.