4

With HRD and BigTable, you are forced to deal with eventual consistency for all queries that are not ancestor queries. Your code has to be robust enough to cope with the fact that the results may be stale.

With Google's launching of Cloud SQL, they put in a disclaimer: ( https://developers.google.com/cloud-sql/faq#hrapps ) 

"We recommend that you use Google Cloud SQL with 
High Replication App Engine applications. While you can use use 
Google Cloud SQL with applications that 
do not use high replication, doing so might impact performance."

What does this mean? Does this mean that there are the same eventual consistency issues using SQL with HRD? There is no concept of entity groups in SQL, however could this mean that particular SQL queries in particular circumstances deliver stale results?

This would mean that Google's implementation of the SQL atomic transactional contract would be broken and SQL would not function as users of relational databases would expect. If this is not the case, what are the concerns for having a master/slave or HRD model with SQL and why would Google give you the option of choosing a model with poorer performance?

jsg
  • 143
  • 8

2 Answers2

5

(from forum)

The Cloud SQL and Data store systems are independent. You can use one or both as you see fit for your app.

We recommend using HRD apps because that type of app will be colocated with Cloud SQL. Master slave apps are served from a different set of datacenters where cloud sql does not have presence. It will work but it will be slower.

Rob
  • 176
  • 4
0

Quotes from documentation:

"Google Cloud SQL is, simply put, a MySQL instance that lives in the cloud. It has all the capabilities and functionality of MySQL"

TO answer your question, the high replication/master-slave options for a relational DB are not to do with consistency but with other factors like latency at peak loads and availability for write when there is a planned maintenance. For a high replication datastore the latency is low even if load spikes, and they are available for write even while there is a maintenance planned. Check the comparison at http://code.google.com/appengine/docs/java/datastore/hr/

And second part of question as to why would google offer a master-slave option which is not full proof. Answer is so that people who don't need complete uptime and want to try out GAE can use it.

Vishal Biyani
  • 4,297
  • 28
  • 55
  • Thanks for the response. Much appreciated. Personally, I think that if the only disadvantage of the HRD for SQL is slighter slower write time during synchronized write, then casual users who don't care about maintenance downtime aren't going to care about a slightly slower write either. I think Google would be well-advised to remove the master/slave option as even the decision causes confusion. – jsg Mar 14 '12 at 20:30
  • If u think answer is what you looking for, you can vote up/mark as correct answer :) – Vishal Biyani Mar 14 '12 at 20:31
  • If you could confirm that my intuition of my comment makes sense, then I'll mark the answer as correct, alternatively, could you highlight additional cases for keeping the master/slave option? (Sorry, don't have enough reputation points to vote up answers. :-( ) – jsg Mar 14 '12 at 20:34
  • 1
    The main reason master/slave is still an option is to support older application code that still uses it. As you noted, M/S has different consistency guarantees than HR, so migrating to the latter sometimes involves careful consideration of the code, and can't be done automatically. All developers of new apps are strongly encouraged to use the HR datastore, and that's why it's the default for new apps and required by new features such as the Python 2.7 and Go runtime environments. – Dan Sanderson Mar 14 '12 at 23:24
  • Hi Dan. Your answer explains why M/S is required for BigTable legacy apps, but does not explain why it is needed for SQL legacy as there appears to be no consistency issues with SQL??? – jsg Mar 15 '12 at 12:20