3 ms·
Assuming linearity is atomic multi-key updates: 1. There are tasks which don't require atomic multi-key updates 2. Atomic multi-key updates can be implemented
by rystsov 10y ago
Assuming linearity is atomic multi-key updates:
1. There are tasks which don't require atomic multi-key updates
2. Atomic multi-key updates can be implemented on the client side (see RAMP, Percolator transactions or the Saga pattern)
3. Once the data overgrow the size of one machine you need to shard the log and at this time you're in the same situation
- freels 10y agoFair enough, though at that point, you're layering on additional complexity and getting further away from the goal of simplicity. (And to point 3, while this is true, using a log means this problem can be dealt with a lot later, and there are solutions that don't involve giving up linearizability, such as a dedicated set of log replicas apart from data partitions, or implementing something like Calvin.) My main point was that the deficiencies of strong-leader-based consensus protocols are overstated, and despite a (minor IMO) level of additional starting complexity, a raft-like protocol is going to be quite a bit simpler than a paxos-based protocol of equivalent capability.