5 ms·

Theoretically it means they are giving up on being Partition Tolerant. There was a popular post a while ago about how the P can't be sacrificed. Because if it i

Theoretically it means they are giving up on being Partition Tolerant. There was a popular post a while ago about how the P can't be sacrificed. Because if it is... everything else will fail. Being Google they are probably prideful enough to think their servers could never have an outage. Which yes, I agree with you, that is a very scary claim.

CobrastanJorji 10y ago
This is thoroughly wrong. Cloud Spanner sacrifices the "A", not the "P." The cool thing being accomplished here is that the sacrifice to the A is greatly reduced (five or more 9s). There are several documents on the subject linked right off that page and elsewhere in these same comments, like this one: https://cloud.google.com/spanner/docs/whitepapers/SpannerAndCap.pdf https://cloud.google.com/spanner/docs/whitepapers/SpannerAnd...
xapata 10y ago
The "choose two" of the CAP theorem is a bit misleading. By creating a distributed system, you've chosen P. So it's really choose one: A or C.
wsh91 10y ago
To wit: In terms of CAP, Spanner claims to be both consistent and highly available despite operating over a wide area, which many find surprising or even unlikely. The claim thus merits some discussion. Does this mean that Spanner is a CA system as defined by CAP? The short answer is “no” technically, but “yes” in effect and its users can and do assume CA. The purist answer is “no” because partitions can happen and in fact have happened at Google, and during some partitions, Spanner chooses C and forfeits A. It is technically a CP system. However, no system provides 100% availability, so the pragmatic question is whether or not Spanner delivers availability that is so high that most users don't worry about its outages. For example, given there are many sources of outages for an application, if Spanner is an insignificant contributor to its downtime, then users are correct to not worry about it. https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Spanner-and-the-CAP-Theorem.html https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp... (written by Eric Brewer, who proposed CAP)

CobrastanJorji 10y ago

This is thoroughly wrong. Cloud Spanner sacrifices the "A", not the "P." The cool thing being accomplished here is that the sacrifice to the A is greatly reduced (five or more 9s). There are several documents on the subject linked right off that page and elsewhere in these same comments, like this one: https://cloud.google.com/spanner/docs/whitepapers/SpannerAndCap.pdf https://cloud.google.com/spanner/docs/whitepapers/SpannerAnd...

xapata 10y ago

The "choose two" of the CAP theorem is a bit misleading. By creating a distributed system, you've chosen P. So it's really choose one: A or C.

wsh91 10y ago

To wit: In terms of CAP, Spanner claims to be both consistent and highly available despite operating over a wide area, which many find surprising or even unlikely. The claim thus merits some discussion. Does this mean that Spanner is a CA system as defined by CAP? The short answer is “no” technically, but “yes” in effect and its users can and do assume CA. The purist answer is “no” because partitions can happen and in fact have happened at Google, and during some partitions, Spanner chooses C and forfeits A. It is technically a CP system. However, no system provides 100% availability, so the pragmatic question is whether or not Spanner delivers availability that is so high that most users don't worry about its outages. For example, given there are many sources of outages for an application, if Spanner is an insignificant contributor to its downtime, then users are correct to not worry about it. https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Spanner-and-the-CAP-Theorem.html https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp... (written by Eric Brewer, who proposed CAP)