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

151–160 of 456 posts

Re: Introducing Cloud Spanner, a Global Database Service

#151

Post by jedberg »

hueving wrote: post #138
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 Goo…

Exactly my point. I would say I personally prefer the Amazon way of forcing you to think about these things.

Re: Introducing Cloud Spanner, a Global Database Service

#152

Post by jedberg »

u320 wrote: post #148
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…

The "old way" was sacrificing functionality such as transactions and joins to get scalability (BigTable, DynamoDB). Google tried that a decade ago and found it lacking, this is why Spanner exists in the first place.

Well, I'd say the "old way" is SQL with joins and schemas and transactions, and the "new way" is KV with eventual consistency.

Re: Introducing Cloud Spanner, a Global Database Service

#153

Post by dpweb »

runeks wrote: post #27

I wonder why they charge a minimum of $0.90 per node-hour when they offer VMs for as little as $0.008/hr. This is hugely useful even for single-person startups, so why charge a minimum of ~$8,000 per year?

Noticed that too, this is not for 'one guy mini-startup', but 'one guy' can already run small loads for almost free in vps.

Having your database problem solved however, one less thing to worry about, if you're bigger.

Re: Introducing Cloud Spanner, a Global Database Service

#154

Post by jedberg »

takeda wrote: post #145
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…

I'm not sure if what you said applies, they have severe restrictions and spanner offers subset of MySQL functionality which is already bare compared to other databases. Changes can be done by primary key only, so it almost feels like a KV store that can do joins... I don't think it's easy to port existing applications to use it and in the end you will still need to accommodate shortcomings in your application.

That's a fair assessment. But I'm assuming they will make it do more "SQL" things in the future. I could be wrong though.

Either way, they are trying to abstract away having to think about eventual consistency with this offering.

Re: Introducing Cloud Spanner, a Global Database Service

#155

Post by craigkerstiens »

kornish wrote: post #129
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…

> It will be interesting if Amazon and Microsoft choose to compete with Google on this service. If we get to the point where you have databases, compute, storage, and connectivity services from those three at equal scale, well that would be a lot of choice for the developers! There are also plenty of choices evolving for developers who aren't looking for hosted solutions (which can sometimes be a showstopper for ente…

Craig from Citus here. Thanks for the kind words. We've seen a lot of people scale-out transactional workloads with Citus as well. In particular, we've seen a lot of multi-tenant apps that need to keep scaling beyond a single node when they're running into memory or compute issues.

If you are looking for something that is more Postgres flavored (meaning we're just an extension to it so you get all the good stuff of Postgres such as JSONB, PostGIS, etc.) then we hope we'd be a good fit. And we run a managed service on top of AWS as well (https://www.citusdata.com/product/cloud) built by the team that built Heroku Postgres. If curious on pricing you can find it at https://www.citusdata.com/pricing/

Re: Introducing Cloud Spanner, a Global Database Service

#156

Post by abalone »

xapata wrote: post #115
abalone wrote: post #106

How does this compare to AWS Aurora in terms of pricing and performance? With Aurora the basic instance is $48/month and they recommend at least two in separate zones for availability, so it's about $96/month minimum. Storage is $.10/GB and IO is $.20 per million requests. Data transfer starts at $.09/GB and the first GB is free.[1] Spanner is a minimum of $650/mo (6X the Aurora minimum), storage is $.30/GB (3X), and…

Aurora replicas appear to be read-only, according to that link.

Sure, but to compare accurately we should look at where that impacts performance in practice. How many writes can Aurora's largest instance handle? What's the write latency from other parts of the globe?

Re: Introducing Cloud Spanner, a Global Database Service

#157

Post by emersonrsantos »

jonstokes wrote: post #111
emersonrsantos wrote: post #104

Thomas Watson in 1943 amd his famous quote: “I think there is a world market for about five computers". If he was alive, he could say these computers are Google, Apple, Microsoft, Amazon and Facebook.

I beat you by 7 years :) https://arstechnica.com/civis/viewtopic.php?f=21&t=1109206

You win :D

Re: Introducing Cloud Spanner, a Global Database Service

#158

Post by ocdtrekkie »

scarmig wrote: post #146
hueving wrote: post #131

Earlier quoted context omitted.

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

The absolute level of computation available isn't changing at the consumer level. What's happening for the next decade is the destruction of businesses hosting their own IT infrastructure and moving it to a couple of core centers. So, the computational "Gini index" is increasing, but no one is being thrown into computational poverty.

The parent comment doesn't seem to specify "consumer level" and the loss of businesses having their own infrastructure is equally troubling. Everyone is putting a lot of eggs in a very small number of baskets.

Re: Introducing Cloud Spanner, a Global Database Service

#159

Post by takeda »

sudhirj wrote: post #140
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 essentially a marketing buzz. "It's always available because we spent a lot of money to make it available"

CAP is about how the system deals with partitions not whether it has partitions or not.

Re: Introducing Cloud Spanner, a Global Database Service

#160

Post by dietrichepp »

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…

This isn't entirely accurate. BigTable was Google's earlier cloud database, and it's certainly non-traditional, and you have to build your application without traditional consistency guarantees, the way you describe.

Spanner doesn't exactly hide the details, but it lets you make transactions that span multiple shards. You still eat the cost of the transaction, you're just free from having to implement it at the application level, which is a more difficult and error-prone way of doing things. The bottom line is that if you need consistency, it needs to be implemented somewhere in your stack. If you don't need consistency (analytics workloads come to mind) then you have more flexibility with your database.

Disclosure: Google employee, reconstructing what I know from published information.

Post reply on HN