Should I Optimize Around Reads Or Cpu Time In Google App Engine

I'm trying to optimize my design, but it's really difficult to put things in perspective. Say I have the following cases: A. A User has 1,000 status updates. These updates are stor

Solution 1:

Design A is superior.

In design A GAE will use the date to perform a keyed query. What this means is, that Appengine will automatically create an index for you on the Status table sorted by the date. Since it has an index, it will read and fetch only the records after the date you specify. This will save you a large number of reads.

In Design B you basically will have to do the indexing work yourself. Since you will need to fetch each Status and then compare its date you will have to do more work, both in terms of CPU (is cost) as in terms of performance.

EDIT

If your data is accessed as frequently as this, you may have other design options as well.

First you could consider combining the Status objects into StatusUpdatesPerDay. For each day you create a single instance and then append status updates to that object. This will reduce hundreds of reads into a couple of reads.

Second, since the status updates will be accessed very frequently, you can cache the Status in memcache. This will give reduce costs and latency.

Third, even if you do not optimize as above, I believe ndb has built in caching. I have never used this feature, but your actual read counts may be lower than in your calculations.

A fourth option is avoid displaying all status updates at once. Maybe the user wants to see only the last few. Then you can use query cursors to get the remainder when (and if) the user requests them.