3 ms·
As far as I can read into it, this is 95% metaphor and 5% "use a master database but call it a distributed system". > What replica sets using Paxos and Raft pr
by mrkeen 3y ago
As far as I can read into it, this is 95% metaphor and 5% "use a master database but call it a distributed system".
> What replica sets using Paxos and Raft propose is that you will literally deal with one master server and try to keep backup copies of an entire database aligned independently. When a master dies or fails, the clients try to decide on a new leader so that they are all talking to the same server. This leads to a delay in which no one can write.
No comment on Raft, but "a master" only exists in Paxos if you invent one. Any client can talk to any Proposer (which will then try to reach a quorum of Acceptors & Learners). Losing just one Paxos node will not result in a partition, so you can still operate happily with availability and consistency.
> There's no particular need to replicate a whole database if we only want to share a few records. Granularity is the answer to scalability and reliability.
Lots of data, lots of CAP tradeoff. Not much data, not much CAP tradeoff.
> In IT, correct values are assumed to be the latest values. It’s a race to be last, because the last value wins by overwriting and obliterating what came before. So if you have an evil demon flooding the system with nonsense, you’re in trouble.
Paxos itself does not allow for overwriting of values (Learners do not change their mind about the value of a given key.) In order for 'obliteration' to occur, you need to augment your key with a version number or timestamp - something that a downstream system could interpret to mean as "happened after".
- andras_gerlits 3y agoThe CAP argument falls apart as soon as you decouple consistency from wall-clocks. Consistent systems only suffer from CAP limitations if they need strict serializability. The point is that if you only look at the order of the data and not the wall-clock of some actor in the system, you can "calibrate" these separate ordering mechanisms together into a coherent whole and from that, you can build up all of the SQL guarantees. Linearizability makes systems suffer because it tries to enforce a Newtonian model in a relativistic world. Order will naturally emerge faster when you're closer to the data than if you're farther. Measuring these with the same clock is what causes CAP, not some inherent property of distributed consistency.
- heavenlyblue 3y agoThere's 0 relativity involved in distributed databases
- andras_gerlits 3y agoYes, that's exactly the problem with the existing models and why CAP was formalised.
- heavenlyblue 3y agoNope, that's not true, and you neither solved nor explained it in this message
- mrkeen 3y ago> The CAP argument falls apart as soon as you decouple consistency from wall-clocks Hogwash Five friends are seated at a restaurant, about to agree on a flavour of pizza via a simple majority quorum. Before they do so, the three girls excuse themselves to the restroom while the two boys remain at the table. The waiter arrives and asks what flavour pizza they'll have. Do the two boys answer on behalf of all five friends, or do they wait for the girls to return? No-one checked their own watch.
- andras_gerlits 3y agoCan I replicate people deterministically and control all their sensory inputs in this scenario?