Google Cloud SQL

[scott]

Jeff,

Once you have had time to look into the new Google Cloud SQL service,
I would be interested in hearing your comments about it compared with
the datastore (and NoSql in general) andy Objectify.

I've been enlightened by you in the past and would welcome it again.

Thanks, scott

[Jon Stevens]

We've talked about it so I'll pipe in my thoughts cause we have slightly different opinions on it.

I think its a really cool thing to have as an option for a certain class of development. Namely people who want to be able to easily port their data/apps on/off GAE. Or people who want to prototype dev on GAE without having to a) spend money. b) run servers. That said, I question the reality of this. It feels more like one of those IT manager checkboxes rather than a real need. I mean, there are plenty of other services which offer hosted mysql (ie: AWS), why not just use those?

Jeff's worried it won't scale to google proportions. I think that the google engineers have done some magic here to allow multi-master and I'm betting the innodb backend is the datastore. But, unless someone from google wants to clarify here, it is all a guess. I do like the thought that 'this isn't my issue to deal with, it is googles.'

If you are worried about your application scaling, I'd just use the datastore. There is a lot that SQL can buy you in terms of querying / reporting, but most of that can be implemented in the application layer anyway. In terms of cross entity transactions, that's coming with the datastore soon anyway. In general, SQL is way more complicated than Ofy, I like simple. The datastore takes a different design thought pattern than sql, so that is hard for people to adjust to sometimes.

We have no plans for using it for our company at this time.

jon

[Jeff Schnitzer]

Heh, thanks... but there really isn't enough information online. I
can only speculate that the sql store is a single-instance with
master/slave replication to backup instances. Performance profile
will be quite different than the datastore - it's not going to scale
to high QPS loads, but that's ok. For many apps, this is all you
need.

I think the cloud sql stuff is an interesting adjunct to the
datastore. The datastore is great as an OLTP system but sucks for
doing data analysis. There are a lot of statistics I'd rather just
insert into a sql store (probably asynchronously) so I can do ad-hoc
joins and aggregation queries when I get curious about something.

Jeff

On Mon, Oct 10, 2011 at 11:24 AM, scott <sc...@scmlabs.com> wrote:

[Jeff Schnitzer]

Yeah, Jon and I have come to wildly differing speculations (as opposed
to conclusions) on what the backend might be.

I think the chance of G's MySQL being an exotic multi-master
replication system is pretty close to zero. That shit is hard, and if
they did create a system like that, they'd be at least as proud of it
as they are of the HRD.

I'm curious to know if the backend is a traditional innodb on the
filesystem or if they've written a custom backend that works with
BigTable. But it probably doesn't matter to us.

I'm willing to bet that Cloud SQL will perform about as well as an EC2
instance running MySQL. Which is to say, poorly. The current limit
of 5 QPS reinforces this expectation:

http://code.google.com/apis/sql/docs/developers_guide_java.html#access_limits

Also note that one of the Highlights you *don't* see in this list is
"Highly scalable":

http://code.google.com/apis/sql/

If you're looking for "I can build my big consumer app with Hibernate
on app engine!" I don't think this is going to be it. If you're
looking for a more convenient way to store and query OLAP data, this
could be a really useful tool. If you're building internal apps with
small user bases and a mix of OLTP & OLAP requirements, this might be
easier than using the datastore.

Jeff

[Jon Stevens]

Also, one more thing to think about. My last gig was at a company that didn't think about scalability from the start. That lack of fundamental design decision has really bitten them in the ass now that they've grown. It is nearly impossible to redesign an existing codebase to be scalable further down the line because you have production code running at full steam and that is hard enough to support as it is. Never mind the fact that you didn't write any unit tests. ;-) So, when you are sharding off onto $100k+ MySQL servers every time you need to add a big client, someone really should be thinking... is MySQL the right tool for this job? Could we be using a better technology for this? ;-)

In other words, if you start down the path of using something like CloudSQL with the intentions of scaling it in the future, you'd probably be better off just starting off with a better design.

As jeff says, small internal apps with a fixed user base sound like about all I'd use it for.

jon

[Jon Stevens]

Wasn't I just talking about designing for scalability? ;-)

jon

Link: http://slashdot.org/story/11/10/10/2152257/RIM-Server-Crash-Leaves-Millions-Without-BBM
Posted by: Soulskill, on 2011-10-10 22:05:00
   Several readers have sent word that "tens of millions of BlackBerry
  users in Europe, the Middle East and Africa have been [1]unable to
  receive or send emails and messages through their phones, following an
  outage at the server systems of parent company Research In Motion." RIM
  has confirmed that [2]they're aware of the problem and working to
  restore service. A former RIM employee said to The Guardian, "They
  didn't start looking at scalability until about 2007, when they had
  around 8M active devices. The attitude was, 'We're going to grow and
  grow but making sure our infrastructure can support it isn't a
  priority.' They have their own clunky infrastructure to do something
  that you don't really need a clunky infrastructure to do anymore."

References

  1. http://www.guardian.co.uk/technology/2011/oct/10/blackberry-outage-affects-bbm-services
  2. http://www.bbc.co.uk/news/technology-15243892

[Ikai Lan]

I'm still working on understanding hosted SQL. I think there are a lot of benefits to an application that is hybrid datastore/hosted SQL with most of the important data residing in the datastore. There are some things you might want to do in the datastore that are just incredibly difficult that are fairly simple in SQL. In addition, you should have the ability (once everything is released) to requisition as many SQL instances as you need, so from a scalability perspective, horizontal scalability shouldn't be an issue - of course, once you start going down that route, you might wonder why you didn't look at datastore to begin with.

The current limit in preview mode is something like 5 requests a second. I don't know if that's reads or writes. I can't confirm the DB engine, but I'm pretty sure it's not MyISAM. Hopefully I'll have the answers for all of these questions and more soon.

My worry is that with a SQL option, people aren't even going to try to solve their problem using the datastore first, and it'll be all SQL all day long. I'm worried that SQL being available means that every person in the App Engine groups that has mentioned "struggling to wrap my head around a denormalized datastore" when they started (and came away a better developer for it) will give up at the first sign of trouble.

--

Ikai

[Jon Stevens]

#1. feature request humor... join across instances. ;-)

jon

[scott]

This discussion has been most informative.

I am leading a large rewrite of a major retailer's operational systems
targeting GAE using the datastore. And Objectify of course :-) We
are almost done after 6 months(~3 more to go). Objectify/Datastore
has been the best persistence solution I have ever used. And I am one
of those 30 yr. grizzeled IT veterans who has spent most of their
career in SQL. But I think your concern is very valid, Ikai. There
is a vast army of corporate IT staff who make architecture decisions
(whether they should or not) that consider the datastore "broken" and
will only use SQL. This will give them ammo in their misguided
attempts to use SQL for everything. And make it harder to introduce
the datastore where it really should be used :-(

But don't get me wrong, I think adding sql as an additional tool for
use in the cases Jeff mentioned is a good thing.

scott

> >http://slashdot.org/story/11/10/10/2152257/RIM-Server-Crash-Leaves-Mi...

> > Posted by: Soulskill, on 2011-10-10 22:05:00
> >    Several readers have sent word that "tens of millions of BlackBerry
> >   users in Europe, the Middle East and Africa have been [1]unable to
> >   receive or send emails and messages through their phones, following an
> >   outage at the server systems of parent company Research In Motion." RIM
> >   has confirmed that [2]they're aware of the problem and working to
> >   restore service. A former RIM employee said to The Guardian, "They
> >   didn't start looking at scalability until about 2007, when they had
> >   around 8M active devices. The attitude was, 'We're going to grow and
> >   grow but making sure our infrastructure can support it isn't a
> >   priority.' They have their own clunky infrastructure to do something
> >   that you don't really need a clunky infrastructure to do anymore."
>
> > References
>
> >   1.

> >http://www.guardian.co.uk/technology/2011/oct/10/blackberry-outage-af...
> >   2.http://www.bbc.co.uk/news/technology-15243892

>
> > On Mon, Oct 10, 2011 at 12:21 PM, Jon Stevens <latch...@gmail.com> wrote:
>
> >> Also, one more thing to think about. My last gig was at a company that
> >> didn't think about scalability from the start. That lack of fundamental
> >> design decision has really bitten them in the ass now that they've grown. It
> >> is nearly impossible to redesign an existing codebase to be scalable further
> >> down the line because you have production code running at full steam and
> >> that is hard enough to support as it is. Never mind the fact that you didn't
> >> write any unit tests. ;-) So, when you are sharding off onto $100k+ MySQL
> >> servers every time you need to add a big client, someone really should be
> >> thinking... is MySQL the right tool for this job? Could we be using a better
> >> technology for this? ;-)
>
> >> In other words, if you start down the path of using something like
> >> CloudSQL with the intentions of scaling it in the future, you'd probably be
> >> better off just starting off with a better design.
>
> >> As jeff says, small internal apps with a fixed user base sound like about
> >> all I'd use it for.
>
> >> jon
>

> >> On Mon, Oct 10, 2011 at 12:04 PM, Jeff Schnitzer <j...@infohazard.org>wrote:
>
> >>> Yeah, Jon and I have come to wildly differing speculations (as opposed
> >>> to conclusions) on what the backend might be.
>
> >>> I think the chance of G's MySQL being an exotic multi-master
> >>> replication system is pretty close to zero.  That shit is hard, and if
> >>> they did create a system like that, they'd be at least as proud of it
> >>> as they are of the HRD.
>
> >>> I'm curious to know if the backend is a traditional innodb on the
> >>> filesystem or if they've written a custom backend that works with
> >>> BigTable.  But it probably doesn't matter to us.
>
> >>> I'm willing to bet that Cloud SQL will perform about as well as an EC2
> >>> instance running MySQL.  Which is to say, poorly.  The current limit
> >>> of 5 QPS reinforces this expectation:
>

> >>>http://code.google.com/apis/sql/docs/developers_guide_java.html#acces...

>
> >>> Also note that one of the Highlights you *don't* see in this list is
> >>> "Highly scalable":
>
> >>>http://code.google.com/apis/sql/
>
> >>> If you're looking for "I can build my big consumer app with Hibernate
> >>> on app engine!" I don't think this is going to be it.  If you're
> >>> looking for a more convenient way to store and query OLAP data, this
> >>> could be a really useful tool.  If you're building internal apps with
> >>> small user bases and a mix of OLTP & OLAP requirements, this might be
> >>> easier than using the datastore.
>
> >>> Jeff
>

> >>> On Mon, Oct 10, 2011 at 11:49 AM, Jon Stevens <latch...@gmail.com>