Master/Slave doesn't have better throughput. In the 99th percentile, because of datastore latency spikes, high replication far outperforms master/slave.
I don't think there are plans to completely deprecate master/slave, but there's been serious talk of closing off the creation of new master/slave applications. -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Wed, Aug 17, 2011 at 5:24 AM, Joshua Smith <joshuaesm...@charter.net>wrote: > I certainly hope they don't deprecate M/S, unless/until the following > issues are addressed: > > 1) Ability to migrate without changing app ID. This is fundamental, and > we've never seen any *reason* why this is impossible. I suspect that this > is very hard, but not impossible. Changing the app ID causes problems > because: > > - External references to entity keys (not IDs) are pervasive in many apps > (such as google search links to deep pages, user bookmarks, or RSS feed > URLs) because the documentation encourages the use of these keys in URLs > > - Many users have keys wrapped up in properties that the migration tool > cannot recognize [this doesn't impact my app, but it's a common issue on > this list] > > As an alternative, the infrastructure could be fixed to recognize the case > of using the old app ID instead of the new app ID in a key, and quietly make > the substitution. > > 2) Migration of large data sets takes an extremely long time. Given that > we regularly see M/S downtimes in the couple of hours range, a couple of > hours is probably a reasonable amount of time to migrate. A couple of days > is much too much. [Note that I have not personally gotten far enough into a > migration to see this duration; I'm basing this on many user complaints I've > read on this list.] > > 3) The problem of transactional consistency needs to be addressed. It is > not acceptable for transactions to end in a "maybe this worked, maybe it > didn't" state. They should either succeed or fail. (Although the docs not > not say whether this problem is exclusive to HR, it seems to be, and > certainly it matters much more in HR since every put is implicitly > transactional.) > > 4) As Ikai said, there are some unresolved issues in HR that need to be > fixed, such as the current mystery in the 'Serious Problem: Rollback of data > on HRD' thread (which is eerily familiar: I think somebody else reported a > similar issue a while back). > > Even if all these are addressed, it would certainly be nice if M/S remained > an option. It makes different trade-offs than HR, which may be better > trade-offs for some applications. I will be very disappointed if they > decide to make HR a requirement for multi-threading Python, since the two > are completely orthogonal choices. From my reading, M/S seems to have > better throughput than HR, at the expense of more frequent downtime, and > spurious datastore timeouts. I'd like to have that option in a > multi-threaded app. > > -Joshua > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
