views:

43

answers:

1

I've been going round in circles with what must be a very simple challenge but I want to do it the most efficient way from the start. So, I've watched Brett Slatkin's Google IO videos (2008 & 2009) about building scalable apps including http://www.youtube.com/watch?v=AgaL6NGpkB8 and read the docs but as a n00b, I'm still not sure.

I'm trying to build an app on GAEJ similar to the original 'hotornot' where a user is presented with an item which they rate. Once they rate it, they are presented with another one which they haven't seen before.
My question is this; is it most efficient to do a query up front to grab x items (say 100) and put them in a list (stored in memcache?) or is it better to simply make a query for a new item after each rating.
To keep track of the items a user has seen, I'm planning to keep those items' keys in a list property of the user's entity. Does that sound sensible?

I've really got myself confused about this so any help would be much appreciated.

A: 

I would personally do something like:

When a user logs in, create a list of 100 random IDs that they have not seen. Then as they click to the next item, do a query to the datastore and pull back the one at the front of the list.

If this ends up too slow you can try to cache, but it is really hard to memcache you entire database. Even loading the 100 guys they need will be hard (as the number of users scale out). Pulling back 1 entry for 1 webpage load is not slow. Each click will be post 1 comment and pull 1 item back. Simple, only a few MS from the datastore. Doing the 100 random IDs they haven't seen can be slow, so that makes sense to do ahead of time and keep around (in their request or session depending on how you are doing that...)

bwawok
@bwawok thanks so much for your answer. Working on my own, it's good to know that I'm heading in the right direction. Thinking about it a bit more (after some sleep!) I reckon there's not really any need to grab a bunch of id's in a batch up front. I think I'll just keep it simple and grab a random ID that the user hasn't seen. After they submit their rating, then just grab another one using the merge-join technique explained in the Google IO presentation linked above. I'm assuming that the cost of making this kind of read is negligible and will scale OK as user numbers increase. Thanks.
James