3 ms·
CAP's A isn't a very useful thing at all. There's nothing stopping a database from being both Consistent and (common-sense definition) Available on the majority
by mjb 3y ago
CAP's A isn't a very useful thing at all. There's nothing stopping a database from being both Consistent and (common-sense definition) Available on the majority side of a network partition. It just can't be available on both sides, which is unfortunately the definition from the CAP proof from Gilbert and Lynch. The proof isn't wrong, but it is extremely misleading if you go into it expecting the common-sense definitions.
There's also nothing stopping systems from accepting commutative writes, and hence being available for writes on both sides. Similarly, if the system accepts no writes it can accept reads on both sides without breaking the law.
- opportune 3y agoI don’t agree with that characterization about availability, this is exactly what Spanner is designed for since replication can be cross-region for very good reasons (to improve latency, save on bandwidth, improve e2e availability) and you actually do want to maintain availability in the case of a network paritition between regions (which is a thing that actually happens)
- readams 3y agoSpanner does not give you availability in the case of a network partition between regions.
- opportune 3y agoI’m pretty sure it does give you read-availability, just not write availability? I could be wrong but I think it’s: To serve a read from a replica in region X, where the write replica is in region Y s.t. there is a partition between X and Y, I’m pretty sure in the normal case X does not need to wait for Y to tell it to let the read go. Instead Y locks X on-write to implement consistency. So in the case of a partition X still does not wait for Y to execute a read, but writes become unavailable.