Please correct me if read it wrongly.
If you can sacrifice consistency (causal instead of external), you can get EPaxos. If you can sacrifice more, you can get Single Paxos. Both of them can increase concurrency to some degree, and can improve availability over a leader based RSM system like Muti-paxos or Raft.
I believe there are other ways to make the trade-off, even making the trade-off dynamically. Hopefully, I can talk about it more soon.
I work on etcd/raft, which is a shared Raft implementation by TiDB(TiKV), Cockroachdb, etcd and many more.
What do you mean? Single Decree Paxos is linearizable so it's consistent. When the multi-key updates are necessary - they can be implemented with client-side transactions such as 2PC, RAMP or Percolator.
Even with Raft we in the same situation. Once the data overgrows the size of one machine we need to shard them. As a result some keys can live on different shards and we need cross shards transactions to do multi-key updates :)
If you choose things like Raft (or other RSM), you can get a consistent key space to do txn over keys.
For a metadata store like etcd, one RSM group is OK. Performance/availability is better than something requires 2PC.
For database systems, there are quite a few txns that can actually fall into one shard and can bypass 2PC.
Of course, it is highly depend on the workload and use cases.
1) The atomicity usually isn't a problem, it can be added on top of the sharded storage with 2PC, RAMP or Percolator transactions, or with Sagas.
2) With Raft you have to implement log compaction and snapshotting, with Bizur and Single-Decree Paxos it isn't the case
Bizur buckets can be very small (10s of kb), and the overhead for them is minimal (10s of bytes).
What would be the overhead of having a raft group for every 32KB? Would it be practical / a good use of the machine's resources?