Thanks Robert, I suspected you'd come across it. I was re-reading Itai's post and just thinking about the shard suggestion.
(Jeff, definitely not going to pre-optimize, but I reckon one benefit of working with GAE is that we get to learn about designing for apps at scale. So...thought experiment.) It seems obvious that fewer shards allow you to query across the full answer set with the least amount of queries. E.g. if you'll often query across users for a single multi-user customer, best would be to have a prefix that is shared for that customer, rather than one user. That way you don't have to sew the result sets together. (Does using a namespace handle this automatically or does it only affect keys? Where are the 'built-in' shard-points? Accounts must be sharded, otherwise the tablet covering the "current" timestamp would explode.) One approach might be to change the data format (or store the value in an unindexed field) to just dump the data with minimal contention, and then later process it via a task to index it correctly. You get safer insert and can fix indexing when you can manage the process more carefully. Using this method you don't have to do anything different until you near huge write counts, and then adjust your app slightly to delay indexing. Richard -- 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/-/6MTdrvQ5icsJ. 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.
