Q: MongoDB query for time ordered updates to a sum I am attempting to set up a time ordered query for a sum of the value of multiple updates. At any time a value may be added to, with any query returning the documents ordered according to the changed total (delta) of that value for a time range specified.
In this specific case, a long is kept within the document and is added to for any reasonable amount at any time. I would like to retrieve the documents, ordered by the sum of all updates to the long since a specified time. The times will be a small list of options, such as one hour previously, or a day, month, year etc. The document structure can be modified to suit these needs, or other collections etc.
A solution must be suitable for use in a REST api, which is relevant only in that both the updates and queries may be very frequent. However, the accuracy does not need to be perfect, so approximations of the sum changed within an approximate time period is acceptable.
I am thinking a possible solution would be to set up a singleton to aggregate the data from events storing the update information in a separate collection into smaller time intervals and retrieved from a simple query, IE sum the total into hourly totals and updating this total every 5 minutes or so, with updates less frequently for longer time periods (hourly for daily queries, daily for monthly etc) as necessary for performance. With this solution, the data in this embedded document would look like
{
  _id: ObjectId,
  total: long, // used for all time query
  hour: long, // aggregated every 5 min
  day: long, // aggregated every hour
  month: long, // aggregated every day
  year: long, // aggregated every week
}

and individual events would be something like
{
  _id: ObjectId,
  reference: ObjectId, // matches documents of type above
  updateTime: Date, // used by aggregator
  amount: long, // added to total
}

and a query could be made as 
db.collection.find({$query:{},$orderBy:{hour:-1}})
The added advantage of this is that the update events could be archived for use if there is ever a need to query for updates within a specific range, although this is not necessary in a solution
What are some alternatives to this, and what would be advantages/disadvantages by comparison?
It seems be to be related to MongoDB MapReduce update in place how to with a similar solution. Are there any obvious problems, such as scaling, that can be avoided with a different solution?
edit: I should have stated more explicitly, the order itself is what's important, only the total value, regardless of when it is updated and can be separately maintained, is relevant to the API. Approximate ordering is acceptable as well.

A: What you are trying to implement is referred to as 'time series'.
There are a lot of good posts and presentations on that subject on the 'mongodb.com' site, starting with:
http://blog.mongodb.org/post/65517193370/schema-design-for-time-series-data-in-mongodb
Have a look at those, it will help you design your solution.
Some things I can say from your description.
You want to use the aggregation framework instead of map/reduce, if you can. It is much easier, and most of the time more performant.
Using 2 collections, one for your data and one that acts as your 'data warehouse' is usually a good design. That way you can either prune the data when you want, or use a capped collection that will do it automatically. A TTL collection is also another option to let some data expire.
Running regular aggregation to compute 5 mins, hour, day, ... stats is a good pattern. If you don't have performance issues, you probably want to keep it that way. If you have scarce resources, you can reduce the frequency of the runs, or design a more complex scheme to only compute the deltas. For example, instead of always calculating the results for the last day every hour, only calculate stats the last hour, keep 24 data points, and combine that data to give you the 'day' value. But again, this is a much more complex scheme and design and you may not need it.
In summary, look for some existing presentations on 'time series' because this is a common pattern for which MongoDB is used.
