Google Cloud SQL now available with an SLA, 500 GB databases, and encryption
googlecloudplatform.blogspot.com
googlecloudplatform.blogspot.com
Does Mysql lend itself innately to scalability at Amazon/Google scale that is hard to do with Postgres ?
Disclaimer: I'm a developer on Cloud SQL.
In fact, I would say that you would have a large segment of people/startups interested in leveraging postgresql on the cloud without the headache of managing replication,etc.
The goal of Cloud is to provide the building blocks so people can make great products. The quickest way to making good stuff is to use the same tools that everyone is already familiar with, and I think that's why Cloud SQL exists. If you want more "touch" on the database for more power, there's Cloud Datastore [1]. But we support companies like Costco on Cloud SQL, so it's good for a lot of folks.
http://aws.amazon.com/rds/postgresql/details/
Also I think it is just because MySQL is generally more popular than PG, so it is deployed first in most cases, with PG support being added later.
I dont know why the situation is so bad. Rackspace, for all its much-vaunted "fanatical support", refuses to touch Postgres.
They probably don't want to take on the operational burden adding a 2nd DB would entail vs. the added revenue it might generate.
No, quite the opposite actually. Mysql scales poorly with high concurrency, and replication suffers from "oops I stopped working and you have to manually intervene now" syndrome.
They use mysql because it is what most customers want.
The keys are managed by Google and obviously this won't protect against them getting at your data. And any external attacker who gets into Google's infrastructure could (in theory at least) get the keys as well. It presumably protects against someone stealing the hard drives from the data centre, but that doesn't seem like a significant threat.
Amazon has a similar feature on S3 - they will encrypt your data on upload, and automatically decrypt it when you read it [1]. From a security perspective, this appears to be useless [2].
I suppose it might be useful if you're at an organisation with a rule saying "all data must be encrypted at rest" where the rule cannot be changed, but does not have to be implemented in an effective or useful manner.
[1] http://aws.typepad.com/aws/2011/10/new-amazon-s3-server-side... [2] http://security.stackexchange.com/questions/8765/what-does-a...
It's technically true, and it does offer protection against a minute range of threats, but it's mostly dangerous snake oil that'll end up with people who think they have protection when they don't.
They also talk about in-network encryption, which does directly speak to the NSA issues.
All of it is under the auspices of "network security", which is a growing concern because of the NSA debacle. And to answer ohm's comment, yes many people who know tangentially about the NSA accessing data don't really know that much about the practical applications of security. Something like this absolutely helps them drop a bullet point declaring security to bolster their cloud strategy.
http://www.cleardb.com/store/azure
On an ability to plug things in and get things working Azure still wins. I would stick to AWS or Azure.
I get the feeling Google is only offering the same as its in house services to the public so they can get free troubleshooting/bug fixing and stop their support staff from growing complacent.
I know that Google as a whole has a rep for support which isn't great. However, I also know that Cloud is trying really hard to show that isn't the case with Cloud products (as is the company as a whole, my personal experience with support phone lines at Google Play, for example, have been really good). We have Stack Overflow (which we as devs check in on to see if there are problems we can help with e.g. [1]), we have support packages which have real live human beings on the other end [2].
I know everyone here in my dev team is 110% behind support being great, but it's one of those things where we'll be judged by execution rather than words (as it should be).
[1] http://stackoverflow.com/questions/21774738/google-cloud-sql... [2] https://cloud.google.com/support/
It seems a waste of talent to have developers picking up the phone when I call developer support, but it would be nice if that team could run stuff by developers when they need to. They also need better training on typical things that developers might call about. (Eg. "Sandbox seems to be down, can you confirm and provide an ETA on the fix?")
https://developers.google.com/cloud-sql/docs/mysql-client
It's showing 5.5 -- 5.6 went General Availability over a year ago, and it's not even a recent build of 5.5 at that, so you're seemingly missing out on nearly a year's worth of bugfixes and security patches. I know Google is applying a lot of custom patches to MySQL here, but I would really worry that the work they're doing to customize MySQL is causing them to lag behind the official version in terms of features and fixes.
I have been thinking of giving AppEngine, etc. another chance but I have been spoiled by very good customer support at RimuHosting, and the knowledge that some support for AWS would be available if I ever had any problems. Google needs to crank up their customer support efforts. I guess that the fact that Google makes relatively little money from PaaS services worries me. All that said, I really enjoyed using Google internal infrastructure during a brief consulting gig at Google, so using AppEngine, etc. is appealing to me out of nostalgia - for for the general public they might not be a great choice.
In shared services one interesting topic is how the various limits are implemented. Is there some hard timeouts that prevent complex queries? Is there throttling? Do you get some kind of penalties for running queries that are not optimal? Do you need to implement some specific retry-logic?
- "Downtime" means more than a twenty percent Error Rate. Downtime is measured based on server side Error Rate.
- "Error Rate" means the number of Valid Requests to open a connection that fail to open a connection, divided by the total number of Valid Requests during that period.
You can buy a package (reserved capacity?) or pay per-use.
This is a bit confusing, I'll file a bug to get it cleaned up. Thanks for the spot.
We offer two different ways of working with Cloud SQL: synchronous and asynchronous writes. With the synchronous writes, you'll get an OK back when you update the database, which lets you know that the write completed successfully and is replicated. If something bad happens, you'll get an exception back and can keep the data in memory until the database is live and accepting connections again.
A faster method is asynchronous, which performs the writes every second or so, so you're not waiting for replication to complete. If something dies during that second, you could lose data during that period and not know it.
Does this help?
Disclaimer: I'm a developer on Cloud SQL.
Latency is the same as if you were running MySQL on any other platform AFAIK. If the database is cold, yes, the DB is spun down. An incoming connection will cause the DB to spin up, and in most languages the common MySQL connector will block until it's ready, so it doesn't require special coding around. Databases almost always come up in a matter of seconds.
On top of that, the fragmented (seek dominated) nature of typical database IO, and the fact this only happens only on cache misses...
I'd expect this to be implemented by hardware encryption, probably at the storage layer, with minimal speed impact.