221–230 of 456 posts
While everyone is puzzling over how Spanner seems to be claiming to be CA, I would like to take this opportunity to bring up PACELC[1]. The idea is that the A-or-C choice in CAP only applies during network partitions, so it's not sufficient to describe a distributed system as either CP or AP. When the network is fine, the choice is between low latency and consistency. In the case of Spanner, it chooses consistency ov…
Really a CP system but with the Availability being five 9s or better (less than one failure in 10^6) How: 1)Hardware - Gobs and Gobs of Hardware and SRE experience "Spanner is not running over the public Internet — in fact, every Spanner packet flows only over Google-controlled routers and links (excluding any edge links to remote clients). Furthermore, each data center typically has at least three independent fibers…
> with the Availability being five 9s or better (less than one failure in 10^6) Anyone know how exactly this is defined for them? (Time? Queries? Results?)
> Today, we’re excited to announce the public beta for Cloud Spanner, a globally distributed relational database service that lets customers have their cake and eat it too: ACID transactions and SQL semantics, without giving up horizontal scaling and high availability. This is a bold claim. What do they know about the CAP theorem that I don't? Separately, (emphasis mine): > If you have a MySQL or PostgreSQL system th…
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.
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-Sp... (written by Eric Brewer, who proposed CAP)
What is TrueTime really? Are their Distributed Systems 'sharing a global clock'?
https://stackoverflow.com/questions/18384883/why-is-googles-...
I suppose if you spent some serious effort with ntpd (maybe hook it up to a PCI ClockCard), you could get this approach to work.
Earlier quoted context omitted.
Amazon already has Aurora: https://aws.amazon.com/rds/aurora/details/ You're right that there's literally nothing else out there that has tight synchronization using atomic clocks, though.
Aurora is a toy compared to Spanner. Single region, limited backups and replication topologies, limited performances. There is yet to see if Spanner can achieve the expectations, if it does, it's a game changer.
It has for Google internally. No reason why they can't share the service externally.
> 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. It's somewhat ironic that Brewer, the original author of the CAP theorem, is making this sort of marketing-led bending of the CAP theorem terminology. I think what he really should be saying is something in more nuanced language like this: https://martin.kleppma…
> 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.
"What if you could have a fully managed database service that's consistent, scales horizontally across data centers and speaks SQL?" Looks like Google forgot to mention one central requirement: latency. This is a hosted version of Spanner and F1. Since both systems are published, we know a lot about their trade-offs: Spanner (see OSDI'12 and TODS'13 papers) evolved from the observation that Megastore guarantees - tho…
(Disclaimer: I work on Google's cloud.)
Earlier quoted context omitted.
> Trivially, by never allowing either half of a partition to make progress while the partition is in place. Doesn't availability mean getting a response on success or failure. If during a partition there is no response on success of failure how is the system available? It seems re-writing a term like "x will happen" to "x will happen after an infinite timeout" should not be valid
Aphyr covers the impossibility of practical CA systems here: https://aphyr.com/posts/325-comments-on-you-do-it-too Sometimes it's helpful to consider a distributed system through the lens of "harvest vs yield" where harvest is the proportion of information in a system reflected by a response, and yield which is the probability of receiving a response at all. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2…
Now I know it is Eric Brewer himself who wrote that announcement. So I make no claim disproving him or knowing better than, I am just struggling to understand the implications. That CA terms has caused a lot of confusion (at least to me) and so far from what I have read talking about CA systems doesn't make sense.
Never heard of harvest & yield that's an interesting perspective. Thanks for the link, I'll need to go and ponder that for a while. It seems to take a probabilistic approach to these constraints.
But even in that article the description of CA systems is confusing. They describe it it means system can work only in the absence of a partitions. Ok, but then what does it do in the case of partition? The system will presumably do something accept requests, refuse to reply, ... I don't see how it can be both C and A though. That is why I equate that choice with a statement of "I believe partitions will never happen", which I personally think is not realistic.