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/-/FHUqvBlr6gQJ. 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.
