I can't remember who said it but it went something like, "The greatest failure is to not see the opportunities that come from failing!" Oh, wait, I said it he he he.
Ikai, you and all the other Googlers have nothing to feel defensive about. HR is obviously the chosen path and to ignore that is, well, foolish. Perhaps we don't say it often enough and you guys and gals (Googlers) don't get to hear it often enough and maybe we should say it more often but we are grateful for all the great technologies that you are enabling and allowing us to participate in and personally I just want to say thank you and tell you all how grateful I am. Jeff On Fri, Mar 4, 2011 at 2:06 PM, Ikai Lan (Google) <ika...@google.com> wrote: > I'd like to highlight that we're not stubborn enough to admit we were right > all along, because we weren't. It's unrealistic to think that someone gets > something right the first time, and we're no different. High replication is > our admission that the problem isn't that we can't get the average error > rate down, the problem is that we can bring it down but we can't eliminate > datastore latency spikes. > > As far as eventual consistency goes, our users that are on high replication > have not seen any issues. If we weren't always fussing about transparency, > we would probably have been able to not even bring it up, and it's unlikely > anyone would have noticed - we just figured it'd make more sense to > communicate it, though now we are seeing that users are overreacting a bit. > Did you know index creation is also asynchronous? That is, when you save a > property, it returns before indexes have been created? Technically, this > constitutes a consistency issue, but it has no real world impact because it > is instantaneous. We documented eventual consistency issues because they are > an order of magnitude slower than asynchronous index creation, so in some > small cases of "write an entity then do a cross entity group query" the > query results will be off. If you've run any kind of SQL service at scale > that replicates to a read-slave, you should be used to this pattern of > persistence. > > We plan on setting High Replication as the default for all new > applications. It's not quite removing it, but perhaps we will explore that > direction, though we are current hesitant to do so. > > We also plan on having some guest blog posts ... soon. If we had the > manpower, we would work with each and every one of you to migrate over, then > help you benchmark. Unfortunately, we can't. We can, however, try to publish > as much data as we have as it comes in. I think the most useful data here > will be data from third-parties. As far as our tests go, everything seems > alright, but I'm pretty sure you'll all have more confidence in the results > if they're being written by users whose entire businesses depend on the > reliability and performance of App Engine. > > Spines: Please link me to where the documentation says that master/slave is > the best option so we can fix it. To answer your question: yes, High > Replication mitigates the impact of datastore spikes, and provides a path > for us to pretty much eliminate them altogether. > > Lastly, I want to apologize if I came off as irate. I'm usually quick to > respond emotionally, and the damn "undo send" button went away too quickly > in my gmail. I don't mean to shut down any kind of joking around, but do > remember that this group is internationally read. Sarcasm doesn't come off > well in email, and it comes off 10x more confusing for non-native English > speakers. If there's any chance any of you guys are coming to Pycon in > Atlanta next week, Wesley and I will be there. Let's smooth things over with > some drinks/food =). > > Ikai Lan > Developer Programs Engineer, Google App Engine > Blog: http://googleappengine.blogspot.com > Twitter: http://twitter.com/app_engine > Reddit: http://www.reddit.com/r/appengine > > > > On Thu, Mar 3, 2011 at 6:37 PM, Darien Caldwell <darien.caldw...@gmail.com > > wrote: > >> I'm kind of disappointed with Google's recent attitude change. When >> master/slave was all there was, it was deemed 'production worthy'. Now >> suddenly it's " If you are running a production service, you should >> not use Master/Slave datastore. Ever." >> >> Given that the HR datastore has some pretty big problems from a user >> perspective (costs 3 times more, only supports Eventual consistency), >> it's not really feasable to use for production code in *every* >> instance. So I'm very disappointed to hear these kinds of comments >> coming from Google. You shouldn't make something, then complain when >> people use it. If you don't want people using Master/Slave, maybe you >> should remove it. >> >> To berate customers for preferring an option you *provide* is just >> mind blowing. >> >> -- >> 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. > -- *Jeff Schwartz* http://jefftschwartz.appspot.com/ http://www.linkedin.com/in/jefftschwartz follow me on twitter: @jefftschwartz -- 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.
