On Mar 5, 9:10 am, Chris <cskjoldb...@gmail.com> wrote: > Right now you guys have to make GAE _both_ reliable and fast. > That's what we expect. It may very well be next to impossible > to do both but you have to keep trying...and having a bunch of > hard-core GAE engineers continously trying will probably land > us all in a pretty happy place a year or two down the line ;-)
On Mar 18, 2:33 am, Jan Z <jan.zawad...@gmail.com> wrote: > By making distinctions such as this one, you're fundamentally shifting > your direction away from what ought to be (and has been?) a key design > principle. unfortunately, hard tradeoffs are at the core of most serious engineering. it may be cliched, but there's generally no free lunch. are you hungry enough to pay for that lunch? or would you rather save the money instead? there's no single right answer to that question; it depends on the person and the situation. choices like this are similar. i discussed this in detail in http://code.google.com/events/io/sessions/TransactionsAcrossDatacenters.html ; see slide 33 for the executive summary. in essence, you're fighting against things like the speed of light and queueing in core backbone routers in major internet peering points, which are difficult to impossible to change. specifically, 1) the only known distributed consensus protocol is paxos, 2) paxos requires two round trips, and 3) getting packets between datacenters in different physical locations takes time. multiply that time by four (for the two round trips), add in disk seeks on either end, and your writes will always be significantly slower than local writes in only one datacenter. there isn't really any way around that. at least, not until maybe quantum computing, or wormholes. :P this is an important general lesson that we've learned in the developer group at google. tradeoffs like these are inherent in engineering, and there's usually no one size fits all. one choice is right for some apps, but not for the others. given that, the interesting question isn't whether to offer the option. we have to. the interesting question - if any - is what the default should be. (also see my post on synchronous replication vs. eventually consistent reads, http://groups.google.com/group/google-appengine/browse_thread/thread/ca31fe630d73c3d3#d4e0651cd8051c63 ) -- 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-appeng...@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.
