There was a discussion of this in an I/O session last year. I don't remember if it was the "more 9s please" or the "life in production" session. In the Q&A I asked if the HRD affects this limit, and IIRC the answer was that the limit would effectively be multiplied by the number of data centers that receive the writes. So if you are writing across 3 data centers, the limit would be approximately 3X the master/slave limit.
Google doesn't disclose the actual number of data centers in operation (other than "more than 2") so it's hard to guess what this number really is. Jeff On Mon, May 7, 2012 at 10:02 AM, Michael Hermus <michael.her...@gmail.com> wrote: > Mike: You are absolutely right, testing is essential, and I have not yet > performed any. However, I would love some insight (without the effort > associated with setting up adequate test scenarios) before making certain > design choices. > > I am not 100% sure if indexed values have the same limitation, or if it > exists only with keys. My thought is that index rows would have the same > issues with hot tablets at some point. Also, I think Brett Slatkin's > pipeline presentation referenced this issue in regards to an indexed value > (as opposed to a key). > > On Monday, May 7, 2012 9:39:38 AM UTC-4, Mike Wesner wrote: >> >> I'd also like to know if this is any different on high replication than it >> was on master slave. (I know its a lower level bigtable side effect, but >> does hrd/paxos deal with it differently?) >> >> >> Are you planning on writing these entities at hundreds of qps? Most of >> the conversations I have had about this revolve around the entity key rather >> than the indexes, but I suppose you could create a similar problem there. >> >> Have you done any tests? This might be one thing that is better to >> actually test even if you get a solid answer here. >> >> Mike >> >> >> On Monday, May 7, 2012 8:01:14 AM UTC-5, Michael Hermus wrote: >>> >>> All, >>> >>> I have read in several places that using a monotonically increasing >>> value for a key or in an index is a bad thing, primarily because of >>> the way Big Table manages the process of splitting overloaded tablets. >>> In a few comments, I have read that it really isn't an issue unless >>> you hit around 300 QPS. >>> >>> There are many cases where I would like to use timestamp in an index >>> (to order or limit query results based on creation time, for example). >>> So, my questions are: >>> >>> 1) Is there a definitive issue with throughput when using a timestamp >>> in an index? >>> 2) If yes, what is the approximate QPS threshold where it becomes an >>> problem? >>> 3) What can we expect after exceeding this threshold? >>> >>> Thanks in advance! >>> > -- > 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/-/9VrhgQ8J23QJ. > > 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.
