Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Cloud Spanner, a Global Database Service

cloudplatform.googleblog.com

Post reply on HN
Print view View original

131–140 of 456 posts

Re: Introducing Cloud Spanner, a Global Database Service

#131

Post by hueving »

ChuckMcM wrote: post #89

Congratulations to the Spanner team for becoming part of the Google public cloud! And for those wondering, this is why Oracle wants billions of dollars from Google for "Java Copyright Infringement" because the only growth market for Oracle right now is their hosted database service, and whoops Google has a better one now. It will be interesting if Amazon and Microsoft choose to compete with Google on this service. If…

>well that would be a lot of choice for the developers!

A sad choice though. The centralization of computation is likely not a good thing in the long run.

Re: Introducing Cloud Spanner, a Global Database Service

#132

Post by aamederen »

tedd4u wrote: 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

I'm reading the test results and had a question.

>> Cloud Spanner doesn't, however, support data manipulation language (DML) statements. DML includes SQL queries like INSERT and UPDATE. Instead, Spanner's interface definition includes RPCs for mutating rows given their primary key[21].

Does this mean I need to rewrite my application?

My application uses an ORM and it typically converts my logic to SQL statements and fires them off to Postgres. Would I need to change it such that it doesn't issue INSERT / UPDATE statements?

Re: Introducing Cloud Spanner, a Global Database Service

#133

Post by meddlepal »

elvinyung wrote: post #97

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…

It's not claiming CA. It's claiming CP with A strongly implied thanks to a massive amount of Google engineering and private networking.

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

Re: Introducing Cloud Spanner, a Global Database Service

#134

Post by elvinyung »

meddlepal wrote: post #133
elvinyung wrote: post #97

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…

It's not claiming CA. It's claiming CP with A strongly implied thanks to a massive amount of Google engineering and private networking. https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...

I said "seems to", since a lot of people seem to think it :P

Re: Introducing Cloud Spanner, a Global Database Service

#135

Post by sudhirj »

For those trying to compare this with AWS Aurora, Aurora is more a regular database (MySQL / Postgres) engine with a custom data storage plugin that's AWS/ELB/SSD/EFS-aware. Because of this the database engine can make AWS specific decisions and optimizations that greatly boost performance. It supports master-master replication in the same region, master-slave across regions.

Global Spanner looks like a different beast, though. It looks like Google has configured a database for master-master(-master?) replication, across regions and even continents. They seem to be pulling it off by running only their own fiber, each master being a paxos cluster itself, GPS, atomic clocks and lot of other whiz-bangery.

Re: Introducing Cloud Spanner, a Global Database Service

#136

Post by rattray »

snikch wrote: post #92
ChuckMcM wrote: post #89

Congratulations to the Spanner team for becoming part of the Google public cloud! And for those wondering, this is why Oracle wants billions of dollars from Google for "Java Copyright Infringement" because the only growth market for Oracle right now is their hosted database service, and whoops Google has a better one now. It will be interesting if Amazon and Microsoft choose to compete with Google on this service. If…

Amazon's Aurora databases seem to be solving the same problem, and are MySQL or Postgres compatible to boot.

While Aurora doesn't provide true horizontal scalability, the same-node scalability seems so strong it might allow many companies to stay single-node for quite a while.

For example, see this benchmark:

http://2ndwatch.com/wp-content/uploads/2016/09/Graph-3.jpg

from this article:

http://2ndwatch.com/blog/benchmarking-amazon-aurora/

Thoughts?

Re: Introducing Cloud Spanner, a Global Database Service

#137

Post by zzzcpan »

meddlepal wrote: post #133
elvinyung wrote: post #97

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…

It's not claiming CA. It's claiming CP with A strongly implied thanks to a massive amount of Google engineering and private networking. https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...

I think A is wrongly implied, tried to explain it here: https://news.ycombinator.com/item?id=13645925

Re: Introducing Cloud Spanner, a Global Database Service

#138

Post by hueving »

jedberg wrote: post #110

This release shows the different philosophies of Google vs Amazon in an interesting way. Google prefers building advanced systems that let you do things "the old way" but making them horizontally scalable. Amazon prefers to acknowledge that network partitions exist and try to get you to do things "the new way" that deals with that failure case in the software instead of trying to hide it. I'm not saying either system…

>and release products that let you do things "the old way" while hiding the details in an abstraction.

However, by 'abstracting' this away, you're not being forced to think about failure domains. If there is ever a massive country-wide connectivity break to the wider Internet (feasible for lots of people inside censored countries), you'll be pretty pissed when you can't use the DB services for your servers in the Google-local datacenter that you still have connectivity to because it can't get quorum.

Re: Introducing Cloud Spanner, a Global Database Service

#139

Post by inopinatus »

jedberg wrote: post #110

This release shows the different philosophies of Google vs Amazon in an interesting way. Google prefers building advanced systems that let you do things "the old way" but making them horizontally scalable. Amazon prefers to acknowledge that network partitions exist and try to get you to do things "the new way" that deals with that failure case in the software instead of trying to hide it. I'm not saying either system…

People used to make similar comparisons between the Russian and American space programs.

Re: Introducing Cloud Spanner, a Global Database Service

#140

Post by sudhirj »

sudhirj wrote: post #135

For those trying to compare this with AWS Aurora, Aurora is more a regular database (MySQL / Postgres) engine with a custom data storage plugin that's AWS/ELB/SSD/EFS-aware. Because of this the database engine can make AWS specific decisions and optimizations that greatly boost performance. It supports master-master replication in the same region, master-slave across regions. Global Spanner looks like a different bea…

From the technical blog post

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

Basically, the underlying system is CP, but A is so high (because of the custom fiber, paxos etc) that they're rounding it off to 100% and calling it CAP.

Post reply on HN