Live data from Hacker News

Introducing Cloud Spanner, a Global Database Service

cloudplatform.googleblog.com

71–80 of 456 posts

Re: Introducing Cloud Spanner, a Global Database Service

#72
post #31

Given the CAP theorem I wonder what trade-offs they make and how much visibility they give you into these trade-offs. In any case this is much better than Amazon's offerings... when they actually ship it. :)

Check out this post mentioned in the original post:

https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...

Of note:

They say Spanner is "both consistent and highly available despite operating over a wide area". So not 100% availability but they've got it to "more than five 9s of availability (less than one failure in 1066)."

Re: Introducing Cloud Spanner, a Global Database Service

#73

> clients can do globally consistent reads across the entire database without locking How is this possible across data centres? Does it send data everywhere at once? Seems too good to be true of course but if it works and scales it might be worthwhile just not having to worry about your database scaling? Still I don't believe it ;-) EDIT: further info... > Spanner mitigates this by having each member be a Paxos group…

Check out the papers. They revealed Spanner a few years ago. Other commenters have provided links.

Re: Introducing Cloud Spanner, a Global Database Service

#74
post #60
post #34

Earlier quoted context omitted.

> 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…

I would expect more from Brewer. "CA except when there are partitions" is CP. It's not "effectively CA".

No, he's saying it's effectively CAP because the A downtime is so small.

It's one thing to do that for a key-value store. Entirely another to support joins on a globally distributed database. This ain't just one availability zone. Spanner is amazing.

It took them a few years to make it a service, but when they announced its use internally a few years ago, it seemed like the nail in the coffin for in-house database hosting.

Re: Introducing Cloud Spanner, a Global Database Service

#76
post #33

The team here at Quizlet did a lot of performance testing on Spanner with one of our MySQL workloads to see if it's an option for us. Here are the test results: https://quizlet.com/blog/quizlet-cloud-spanner

> We've eliminated most of the joins we do, so we haven't tested Cloud Spanner's join performance.

The join performance is by far the most interesting part of this to me. A more traditional NoSQL solution sounds like it would have worked just as well for you, sans all the atomic clock fanciness. Joining across geographically disparate data is a real trick, and it seems like there would be some physical performance limits?

Re: Introducing Cloud Spanner, a Global Database Service

#77
post #75

> This leads to three kinds of systems: CA, CP and AP, What is a distributed system that is CA? Can you build a distributed system which will never have a partition.

They answer your question just two lines under the one you are quoting:

> For distributed systems over a “wide area,” it's generally viewed that partitions are inevitable, although not necessarily common. If you believe that partitions are inevitable, any distributed system must be prepared to forfeit either consistency (AP) or availability (CP), which is not a choice anyone wants to make. In fact, the original point of the CAP theorem was to get designers to take this tradeoff seriously. But there are two important caveats: First, you only need to forfeit consistency or availability during an actual partition, and even then there are many mitigations. Second, the actual theorem is about 100% availability; a more interesting discussion is about the tradeoffs involved to achieve realistic high availability.

Re: Introducing Cloud Spanner, a Global Database Service

#78
post #75

> This leads to three kinds of systems: CA, CP and AP, What is a distributed system that is CA? Can you build a distributed system which will never have a partition.

Trivially, by never allowing either half of a partition to make progress while the partition is in place. Since the CAP theorem, by itself, doesn't put a cap(oof) on latency, it is valid to consider a system CA, if it if always available to listen to requests while partitioned, but never able to fulfill them.

This, of course, is effectively useless in practice, and is dependent on an infinite buffer of pending operations, etc.

https://brooker.co.za/blog/2014/07/16/pacelc.html

Re: Introducing Cloud Spanner, a Global Database Service

#79
Amazon likes to respond to Google with it's own price drops and product launches. It's telling that their announcements are orthogonal instead of direct competition with Spanner.

When Google announced Spanner back in 2012, I'm sure Amazon and Microsoft started teams to reproduce their own versions.

Spanner is not just software. The private network reduces partitions. GPS and atomic clocks for every machine help synchronize time globally. There won't be a Hadoop equivalent for Spanner, unless it includes the hardware spec.

Post reply on HN