3 ms·

This (like a sharded Raft group) is somewhat correct :P. If you can sacrifice consistency (causal instead of external), you can get EPaxos. If you can sacrific

This (like a sharded Raft group) is somewhat correct :P. 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.

rystsov 10y ago
> If you can sacrifice more, you can get Single Paxos 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 :)
- ideal0227 10y ago
  Well... Why do you need 2PC if nothing is sacrificed? :) 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.