FWIW, I don't like sharded counters for this application either.  But
it boils down to two questions:

1) How up-to-date do you need the count to be?
2) How accurate does the count need to be?  Can you afford losing a
few counts now and then?

One solution is simply log access records yourself, each as a separate
entity in its own EG.  Then run a batch process every night (or hour,
or whatever) that rolls up the data and (optionally) deletes the old
records.  This gives you very robust tracking but at the cost of
significant delay.  It's not cheap, either.  Or you could download
logs as you say.  This is certainly cheap.

Another solution is to use memcache increment() and periodically sync
diffs to the datastore.  This is less reliable but much cheaper.  A
variation on this is to use a backend instead of memcache.

Unless each customer downloads more than one thing per second, you
won't need to shard the customer "number of things" downloaded number.
 So that's not too unreasonable.  And even if you do get a burst, you
can push the actual count update to the task queue so it won't hurt
the UX.  The # will just lag a little.

Jeff

-- 
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.

Reply via email to