Hi, You're building the keys correctly for strong consistency.
As far as speed goes, let me give you an example of speed in action. It takes me ~30 minutes to bike somewhere. I can also take the bus. The bus takes me 20 minutes when there are no disruptions. Unfortunately, there are disruptions several times a month. When there is a disruption, it takes me an hour to get somewhere. Is the bus faster, or is biking faster? Would you rather have a consistent 30 minute commute, or a 20 minute commute, that, several times a month, fluctuates to a one hour commute? Now pretend it randomly fluctuates to a 4 hour commute. You'd pick the bike commute every single time. That's what it's like to be on master/slave. I'd love to say it's not like that, but history will prove me wrong. While the work we've done has gone a long way in improving reliability overall, it doesn't change the fact that a single point of failure is subject to massive swings in performance. I remember seeing a presentation by Facebook engineering about how they engineer for predictability instead of pure speed. It's the same logic. Slow and steady is better than fast and unpredictable, especially in user facing applications. Another example is Azul System's design philosophy in pauseless GC. It's actually quite interesting. Their view is that the way GC works in Hotspot JVM (generational) optimizes the 99% use case, but in the 1% use case, GC pauses which pause the entire JVM (sometimes for a second or two, which is a deadly stall in real time applications), will exist, so their philosophy is to build a JVM that focuses on more predictability instead of prioritizing speed in the 99% use case. Disclosure: I still use Hotspot since JVM GC pauses don't affect the applications I write, but if they did, I would seriously look at their solution ( http://www.artima.com/lejava/articles/azul_pauseless_gc.html). A single unpredictable component is easy to use. When you have multiple unpredictable components, you see an exponential increase in complexity in handling wild performance swings, and you want to minimize the number of components whose reliability you cannot predict (URLFetch - you can't predict how someone else's system will perform). The datastore is, very often, at the absolute core of applications you will be building. It's very important for the performance of the datastore to be as predictable as possible. In addition to predictability, you also get much stronger protection against data loss to the point that it is a near statistical impossibility. There's no reason why you wouldn't want to use high replication. The next time someone says something is faster, ask why, because that's where you'll get the real answers. -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Mon, Aug 22, 2011 at 8:53 AM, thstart <[email protected]> wrote: > +Ikai Lan > > In my example: > > * > root = MyRoot.get_profile() > ** > skey = email > * > * > key = db.Key.from_path('MyList', > skey, > parent=root.key()) > profile = db.get(key) > > For HR are there a need to change the way these keys are formed? > > Does your data migration tool can transfer my database from M/S to HR > automatically? > Do my users need to re-enter their data again? > > > * > > -- > 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/-/CBRAyB0paHwJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
