+1 On Fri, Mar 4, 2011 at 1:48 PM, Jeff Schwartz <jefftschwa...@gmail.com>wrote:
> 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. > -- 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.
