Thanks Ikai,
I totally agree with you about prohibit new M/S applications.
Thanks and let's getting better always. I really trust on Google.
--
Atenciosamente(thanks),
Renan Franca
-----
Presidente
____
- Renan Mobile ltda: http://renanmobile.com - Soluções em Dispositivos
Móveis (Smartphones) com integração via web.
- Soluções em:
Android (Smartphones);
Google Web Toolkit (Web);
Em 17/08/2011 13:36, "Ikai Lan (Google)" <ika...@google.com> escreveu:
> 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.
>
--
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.
