3 ms·

I've tried to follow this blog post, but when it gets to the nitty gritty of the solution, it seems self-contradictory. There are constant claims that this pres

I've tried to follow this blog post, but when it gets to the nitty gritty of the solution, it seems self-contradictory. There are constant claims that this presents a solution to have all three items of CAP - exciting. But then the solution seems to only have consistency. First, there is no Availability, because the solution requires a centralized Interloper service. There is some handwaving that the Interloper is distributed, but all of the arguments about maintaining the three databases consistent with each other only work if the Interloper can be assumed to have (distributed) consistency. Which is of course obvious - if you've solved distributed consistency, you can use it to make other things consistent. But this doesn't explain how to solve distributed consistency in the slightest. Secondly, the described system doesn't actually offer partition tolerance: > If one of the databases becomes unavailable (e.g. if it loses power or its network connection creating a “partition”) no harmful misalignment can be observed by any client, because the interloper disallows reads until everything is reported to be back in sync. So if one database goes down/is disconnected, the whole system grinds to a halt. So, no partition tolerance. The paper has a different problem. It seems you are redefining the notion of consistency because you don't like the definition used in the CAP theorem. But you don't actually disagree that no system can display what the CAP theorem calls "consistency" at the same time as availability and partition tolerance, you just don't think it's necessary. This is a defensible position (and one often taken by many distributed databases), but there is no reason to undermine others' work instead of simply saying so. As more of a side note, the paper you wrote keeps referring to the CAP theorem as a conjecture, but it has in fact been formally proven in 2002 by Gilbert and Lynch. You don't seem to have a refutation of their proof, which you don't even cite.

andras_gerlits 3y ago
It's clear for everyone that if you define Consistency via Linearizability, CAP-like problems will apply, as you're necessarily creating original information on a potentially remote node. That's not the issue. The issue is that people in practice almost never use Linearizability for their Consistency, for example I don't know of a single SQL-implementation that does full linearizability (or Strict Serializable, same difference). So the industry already means something totally different from CAP's definition, and for those consistency-levels CAP doesn't apply. In fact, I present a technical series of arguments here how you can overcome these limits in practice: https://medium.com/p/5e397cb12e63 https://medium.com/p/5e397cb12e63 There's a specific section about CAP in the end, but I talk about node-loss. replication, strong consistency and all the others also.

andras_gerlits 3y ago

It's clear for everyone that if you define Consistency via Linearizability, CAP-like problems will apply, as you're necessarily creating original information on a potentially remote node. That's not the issue. The issue is that people in practice almost never use Linearizability for their Consistency, for example I don't know of a single SQL-implementation that does full linearizability (or Strict Serializable, same difference). So the industry already means something totally different from CAP's definition, and for those consistency-levels CAP doesn't apply. In fact, I present a technical series of arguments here how you can overcome these limits in practice: https://medium.com/p/5e397cb12e63 https://medium.com/p/5e397cb12e63 There's a specific section about CAP in the end, but I talk about node-loss. replication, strong consistency and all the others also.