MongoDB aggregate data to generate 'latest activity'

I have a mongodb collection that has documents like the ones below:

[
  {
  :event => {:type => 'comment_created'}, 
  :item  => {:id => 10},
  :created_at => {:t => '11:19:03 +0100 2010', :d=> 'Fri, 19 Nov 2010'}
  }

,
  {
  :event => {:type => 'vote_created'}, 
  :item  => {:id => 10},
  :created_at => {:t => '11:19:03 +0100 2010', :d => 'Fri, 19 Nov 2010'}
  }
]

What I need is to build a 'dashboard' aggregating latest activity (on current day) for each item. The result should be something like:

{
:item_id => 10,
:events => {
  :vote_created => [.开发者_JS百科. ordered list with latest 3 vote_created events/documents],
  :comment_created => [.. ordered list with latest 3 comment_created events/documents ],
  }
}

The result would be used to construct a 'Facebook-style' syntax like: 'Mike, John and 3 others added comments on your item today.'

How can I aggregate this data using a group or a map-reduce function?

---

OK, there are two ways to do this:

Method #1: Map-Reduce

So first, you'll want to run a map-reduce, not a group.

Use Map-Reduce with the "out" variable which will generate a new collection. You'll then be able to run the summary queries against that new collection.

The reason you'll do this is that you're asking for an expensive query, so it's much more reasonable to access it in "not-quite" real-time.

Method #2: Double-writes

You can basically maintain two collections "details" (top one) and "summary" (bottom one). Whenever you do a write to the details, also perform an update to the summary.

MongoDB has several array methods ($push, $pull, $slice), that should make it possible to keep the "vote_created" array up-to-date.

Preferences

The method you select completely depends on the type of architecture you have and the user experience that you want. Personally, I would just use Method #2 and just keep appending to the "vote_created" array. I would put the 'Mike, John and 3 others...' syntax somewhere on the view, b/c it's really view logic not DB logic.

Yes method #2 takes more space, but it also gives you quick answers to the questions you ask alot. So you're going to have to sacrifice space to get that speed.

---

http://rickosborne.org/download/SQL-to-MongoDB.pdf