I get that indexes are "just bigtable rows too," and that the normal replication rules we all know and love apply, so I guess this boils down to indexes being written separately from the entity. Does the index write apply to the same nodes, or possibly to different nodes?
Alfred, your next project idea: write some type of low-level high-performance batcher providing crazy high write-rates to a single entity group. Perhaps with that you (or we) could come up with a higher performance way to maintain global indexes. ;) Robert Oh, for those wondering what this thread is about... we're just making up words / phrases. On Tue, Sep 20, 2011 at 15:28, Alfred Fuller <arfuller+appeng...@google.com> wrote: > Ikai is correct to think about replication in this case. In a single replica > you could have one of three states: > Applied - fully visible > Committed - has the log entry, but has yet to apply it > Missing - the log entry has yet to be replicated > Only in the first case is it visible to a global query. When you write > something, the log is committed to at least a majority of replicas. The > datastore returns success, then immediately tries to apply the write > everywhere it committed the log entry. It usually takes a couple hundred ms > to apply. This is why the majority of cases take O(100 ms) to become > visible. For a very small % of writes, the write either cannot commit to the > local replica or cannot be applied after the commit. In these cases the > datastore will still return success, but the write won't be visible until a > background process picks it up and applies it. In these case it can take > O(minutes) to be picked up and replicated/applied. If there is something > wrong in the replica you are querying (for example replication is backed up > or the bigtabale is unavailable or the background processes in that replica > are having issues), then it could take a deal longer (this becomes very very > unlikely very quickly, but not impossible). There really is no hard upper > bounds because distributed systems will have pieces that fail (and are > designed to still function when they do). > - Alfred > On Tue, Sep 20, 2011 at 10:10 AM, Ikai Lan (Google) <ika...@google.com> > wrote: >> >> Well, indexes are just Bigtable rows, so replication lag does apply to >> them as well. >> -- >> Ikai Lan >> Developer Programs Engineer, Google App Engine >> plus.ikailan.com | twitter.com/ikai >> >> >> On Tue, Sep 20, 2011 at 7:42 AM, Mike Wesner <mbwes...@gmail.com> wrote: >>> >>> And then I went and used the word replication... i meant index lag. >>> >>> On Sep 20, 9:40 am, Mike Wesner <mbwes...@gmail.com> wrote: >>> > I don't think Ikai read your post... >>> > >>> > Robert and I wanted to write a little HRD status site to track this >>> > and get real data, but we haven't done so yet. I have never seen the >>> > replication take more than about 1s. I think 1s will cover about four >>> > 9's, but that is just an educated guess. Until we (the users) >>> > actually measure this over time I don't think we can know for sure. >>> > >>> > -Mike >>> > >>> > On Sep 19, 7:16 pm, Jeff Schnitzer <j...@infohazard.org> wrote: >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > I know that an index update in the HRD will typically be visible >>> > > within a couple seconds. That's the average case. What is the >>> > > worst-case? >>> > >>> > > Assuming something in the datacenter goes wacky, how long might it >>> > > take for an index to update? Tens of seconds, minutes, hours, days? >>> > >>> > > Thanks, >>> > > Jeff >>> >>> -- >>> 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. > -- 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.
