Live data from Hacker News

Introducing Cloud Spanner, a Global Database Service

cloudplatform.googleblog.com

431–440 of 456 posts

Re: Introducing Cloud Spanner, a Global Database Service

#431
post #200

I wonder how this will affect adoption of CockroachDB [1], which was inspired by Spanner and supposedly an open source equivalent. I'd imagine that Spanner is a rather compelling choice, since they don't have to host it themselves. As far as I know, CockroachDB currently does not support providing CockroachDB as a service (but it is on their roadmap) [2]. [1] https://www.cockroachlabs.com/docs/frequently-asked-questi…

Given that Spanner starts at $650/mo/node + storage costs, I think Cockroach could still see huge usage as a self-hosted alternative.

That's not very much given the capabilities and managed service. Anything cheaper probably means the single-node managed SQL offerings are more than enough.

Re: Introducing Cloud Spanner, a Global Database Service

#432

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.

We've already been through it. People eventually abandoned mainframes for everything they could. Many of the current customers are interested in better solutions but just stuck due to lock-in of piles of COBOL, etc.

Re: Introducing Cloud Spanner, a Global Database Service

#433
post #259

Earlier quoted context omitted.

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.

That's like being sad about the emergence of banks, because everybody's money is being kept in a small number of vaults instead of under each one's mattress.

That strategy resulted in the Great Depression and later 2008 crises. Damage was so high that country had to be rescued by the federal government. So, banking is a decent example of how such consolidation into private hands can go wrong. Now we just apply that to IT services and data.

Re: Introducing Cloud Spanner, a Global Database Service

#434

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 saying either system is better than the other, but doing it Google's way is certainly easier for Enterprises that want to make the move, and why Amazon is starting to break with tradition and release products that let you do things "the old way" while hiding the details in an abstraction."

No, they said this in the F1 RDBMS or Spanner papers. They originally did the NoSQL, eventual-consistency type of stuff. This had app developers required to do a lot of work to avoid problems that model can create. Apparently, even their bright people had enough problems with it that they decided to eliminate or simplify that situation with stronger consistency. Took some brilliant engineering but now they have a database easy to use as old model with advantages of newer ones.

If anything, they learned some hard lessons with a good solution to them. Now, they're offering it to others. I was hoping they'd do this instead of keep it internal only. F1 and Spanner are amazing tech that could benefit many companies.

Re: Introducing Cloud Spanner, a Global Database Service

#435

Earlier quoted context omitted.

> Its pretty much a monopoly, now that Google seems to have officially closed the book on ever supporting postgresql. Uh, how? I wouldn't be surprised to see a Cloud SQL-like managed Postgres service from Google. While there's obviously some overlap in the potential market for any relational datastore service, Spanner doesn't really overlap with a cloud Postgres service as much as Cloud SQL does.

I would be. its been years and google and has been building out various pieces of infrastructure around mysql - including cloud spanner. the issue is that the migration path of self hosted mysql to cloud sql to spanner is pretty well defined. I dont see postgresql being strategically important or relevant to google for anything. if I was a startup deciding on my database, there's a lot less compelling reasons to choo…

> its been years and google and has been building out various pieces of infrastructure around mysql - including cloud spanner.

What does Cloud Spanner have to do with MySQL? It's neither API nor SQL-dialect compatible with MySQL. If there are MySQL bits used somewhere in the implementation, they are well hidden, and irrelevant to users.

> the issue is that the migration path of self hosted mysql to cloud sql to spanner is pretty well defined.

So what? Were there a Cloud SQL-like Postgres offering, the same would be true; Spanner is no closer to MySQL than Postgres. (If anything, it's SQL dialect is a little closer to Postgres's dialect than MySQL's, though not so much that you'll get away without doing substantial conversion going from either.)

Re: Introducing Cloud Spanner, a Global Database Service

#436
post #199

Earlier quoted context omitted.

> Do you have a sense of what that limit is? Per their pricing page[1] it looks like the largest instance available is a "db.r3.8xlarge", which is a special naming of the "r3.8xlarge" instance type[2] which is 32 cpus and 244gb of memory. That's a hell of a lot of capacity to exhaust, especially if you're using read replicas to reduce it to only/mostly write workloads. Obviously it's possible to use more than this, b…

I disagree, the "sheer scale" argument is not flat. The fact that one can scale horizontally and the other can't is significant. Let me present a quote to you: 512 kb ram ought to be enough for everybody

You can disagree on that if you'd like, but note that I explicitly acknowledged the possibility of exceeding these limits. In my opinion, for most cases/workloads, it's highly unlikely that you will and designing for that from the outset is a waste of time and resources.

Re: Introducing Cloud Spanner, a Global Database Service

#437

Earlier quoted context omitted.

While I'm not familiar with Spanner's inner workings, I would guess that they recommend 3 instances for quorum establishment in case a region becomes unreachable. If that's the case, using fewer than 3 instances could cause major problems.

Since Spanner currently only supports single-region deployments, it clearly isn't recommended as protection against a region becoming unavailable. It may be recommended as protection against an availability issue on an instance, though, which is, after all, a big reason why you'd want a distributed DB in production.

I suppose the loss of a region doesn't apply (yet), but yes, the quorum requirement would still apply even if you only had instances in a single region.

Re: Introducing Cloud Spanner, a Global Database Service

#438
post #200

Earlier quoted context omitted.

Given that Spanner starts at $650/mo/node + storage costs, I think Cockroach could still see huge usage as a self-hosted alternative.

That's not very much given the capabilities and managed service. Anything cheaper probably means the single-node managed SQL offerings are more than enough.

But single node with unlimited room to grow is always a good value prop. Cockroach can market that, but Spanner can't.

Re: Introducing Cloud Spanner, a Global Database Service

#440

Oh this looks really compelling! Though I'm guessing this is targeted to companies? I'd love to use this for some personal projects but the pricing seems really high. Am I reading it right that a single node being used at least a tiny bit every hour is about $670 a month? Maybe I'm misunderstanding how the pricing works here. Any clarification would be highly welcomed :)

It's targeted to large datasets more than companies. There isn't really any advantage of a single node Cloud Spanner instance over Cloud SQL. Cloud Spanner becomes worthwhile when you have more data/throughput than a single node system can support, at which point the pricing is competitive with other options.

Fair enough. I just kinda wanted to play with it on my next project :)
Post reply on HN