On Friday, January 7, 2011 12:04:36 AM UTC, Ikai Lan (Google) wrote: > > Stephen, > > The times I gave earlier were estimates of how much replication delay is > introduced in each replication scheme. The "eventually consistent" flag is > for reads only and dictates whether or not you care to read from the > "Master" datastore - reads will go to a slave if there are issues reaching > the master. >
Ah, I misread your original answer as relating only to the high replication datastore - thanks. This is kind of a surprising answer: replication between data centres (hi-rep) takes 100ms; replication within a data centre (M/S) takes 3000-10000ms. I suppose this is a trade-off: because the default for MS is strong consistency you can sacrifice replication lag for higher throughput...? After I asked the question I came across the original blog announcement for the EVENTUALLY_CONSISTENT option, and it already contains the answer: http://googleappengine.blogspot.com/2010/03/read-consistency-deadlines-more-control.html "The secondary location may not have all of the changes made to the primary location at the time the data is read, but it should be very close. In the most common case, it will have all of the changes, and for a small percentage of requests, it may be a few hundred milliseconds to a few seconds behind." Which is somewhat different than an avg of 3000ms and up to 10000ms. The figures from the blog post suggests to me that a query with the EVENTUALLY_CONSISTENT flag is basically not-quite-transactional, where as the latest figures of 3-10mins sounds more like stale results. Is this a policy change? Regardless, it would be good to have these figures directly in the docs to help folks decide when they can use this feature and to decide between hi-rep and m/s. Couple of other questions related to this: - What percentage of reads block due to unavailability of a primary? That is, how often is setting the EVENTUALLY_CONSISTENT flag likely to make any difference at all? - For reads which do block, what is the average wait time for successful waits and the failure rate for reads which timeout (without an explicitly set deadline)? - And, how is unavailability of a primary determined? Is it a time out, and if so, how long? (I would use this figure to help determine a suitable deadline for queries which I want to fail over with eventual consistency.) Thanks. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
