Well, those are the tradeoffs, I suppose. The question is, where do you want the system to do more work, and where do you want it to do less?
If you discover a pattern that causes 10-20 second queries, please post your findings. If you notice that it's specific entities, or you can deterministically reproduce the slowness, it'll give us a starting point to figure out what's going on. On Tue, May 4, 2010 at 9:02 PM, Philip Tucker <[email protected]> wrote: > On May 4, 3:28 am, "Ikai L (Google)" <[email protected]> wrote: > > Query performance is generally a function of how many objects have to be > > returned in the simple case, which seems to be what you are doing here. > How > > many PlayerGameStates exist per User? > > No more than 10 so far. Like I said, it was only 5 in this case. > > > Are PlayerGameStates child entities of a User? > > No. They contain a userKey, which is the field on which I'm querying > them. > > > The reason I mentioned "denormalizing" is because the concept of > > normalization doesn't make as much sense with App Engine's datastore. We > > don't provide referential integrity, for instance, and transactions exist > > around entity groups, not globally. You don't pay a penalty for storing > data > > that is sparse - some User entities can be huge, some can be tiny. You > > should optimize for reads. Doing multiple writes and the risk of data > > getting out of sync can suck, but as long as it is recoverable you should > be > > okay. Contrast the performance of the query above with storing > > PlayerGameStates inside User. You'd do this: > > But then I'd have to run a separate query to fetch the game. Unless I > duplicate the game state and move all those fields into > PlayerGameState, which perhaps is what you're suggesting. But then I'd > have to fetch both users every time, right (to update the duplicate > game state), which means every player needs to contain the userKey of > everyone they're playing. > > Most of my reads are by gameKey. There's only one case where I'm > fetching all the games for a user. I don't really need this case to be > optimized: 2-3 seconds would be acceptable. 80-90% of the time it's ~1 > second. But these occasional 10-20 second fetches are crazy. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine-java%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- Ikai Lan Developer Relations, Google App Engine Twitter: http://twitter.com/ikai Delicious: http://delicious.com/ikailan ---------------- Google App Engine links: Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
