Hey Stephen, Yeah that last sentence looks like an incorrect, or at least seriously misleading, statement to me; there is a chance that an eventually consistent get will not see the most recent data (it also will not initiate a catch-up cycle if it finds stale data). Hopefully Ikai will get a chance to fix that. ;)
Robert On Fri, Jul 8, 2011 at 11:37, Stephen Johnson <onepagewo...@gmail.com> wrote: > Hi Robert, > This is what I kind of thought but I didn't want to go that far in a > statement without official clarification. If that is the case then I think > the documentation should clarify this then because under the Usage Notes of > http://code.google.com/appengine/docs/java/datastore/hr/overview.html The > last sentence which I've bolded below makes it seem that a get which I'm > assuming is by key will see the most recently written data even under > Eventual consistency. Also, many times when people have asked about this it > has always been responded that the queries are eventually consistent but > that get by key is strongly consistent (at least that has been my > impression). I do believe you're right but IMHO this should be better > documented. > Stephen > With eventual consistency, more than 99.9% of your writes are available for > queries within a few seconds. The goal is to find a caching solution for > your application that provides the data for the current user for the period > of time in which they're posting to your app. The caching solution might > involve memcache, a cache in a cookie, some state you put in the URL, or > something else entirely. The point is that, if the solution provides the > data for the current user in context of their posts, it will likely be > sufficient to make the eventual consistency of High Replication completely > acceptable. Remember, if you do a get(), put(), or a transaction, you will > always see the most recently written data. > > On Fri, Jul 8, 2011 at 3:35 AM, Robert Kluin <robert.kl...@gmail.com> wrote: >> Hi, >> This is because doing a strongly consistent fetch by key uses a >> transaction -- which means you'll always get the latest version. If >> you fetch a bunch of keys, these transactions are currently done >> serially which significantly slows the request. An eventually >> consistent fetch goes to the fastest datastore node and returns >> whatever version it has. >> >> >> Robert >> >> >> >> On Thursday, July 7, 2011, Stephen Johnson <onepagewo...@gmail.com> wrote: >>> Hi Pete, >>> Yes, I've also tested this and the speed improvement is VERY >>> noticeable. With the way that the documentation explains the >>> difference between the HR datastores STRONG and EVENTUAL settings you >>> would assume that getting by the key value would be the same speed >>> because according to the documentation gets always return the most >>> recent data. You would assume that queries on the other hand would be >>> the thing that would have the time difference because queries with the >>> EVENTUAL setting can use the replicas (unless an ancestor query) and >>> could have stale results. So something else is going on here that >>> hasn't been explained. It seems due to the speed increase with >>> EVENTUAL consistency on that gets by key are using the replicas (or >>> possibly master if that's the closest datastore) to return the entity >>> instead of the master, so what it could be is that with STRONG >>> consistency on you always use the master for all datastore operations >>> even when doing a get by key even though it could be handled by a >>> nearby replica and with EVENTUAL consistency you always use the >>> closest datastore which could be a replica or the master. Or it could >>> be something entirely else. Hopefully an informed Googler could >>> explain the subtle differences a little better. >>> Stephen >>> >>> On Tue, Jul 5, 2011 at 10:51 AM, Peter Murray <yarrumre...@gmail.com> >>> wrote: >>>> >>>> Greetings, >>>> In a small test retrieving 100 independent (non entity-group'd) entities >>>> by >>>> key (e.g. ds.get(keys) ) in an HR datastore, we found that the >>>> ReadPolicy >>>> significantly affected performance - with Consistency.STRONG set, the >>>> entities were returned in about 500ms (plus or minus), with >>>> Consistency.EVENTUAL set the entities were returned in about 50ms. >>>> Could >>>> someone please describe the practical differences between the two >>>> settings >>>> under an HR datastore? I had thought, from the I/O talk on the subject, >>>> that essentially in an HR environment you were not guaranteed strong >>>> consistency under any circumstances unless the entities are in the same >>>> entity-group. Of course, something is taking 10x longer - the question >>>> is, >>>> what am I getting for the 10x? >>>> Best, >>>> pete >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "Google App Engine" group. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msg/google-appengine/-/apsAu6MR-BoJ. >>>> 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. >>> >>> >> >> -- >> ------ >> Robert Kluin >> Ezox Systems, LLC >> >> -- >> 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.
