Quoting http://www.mongodb.org/display/DOCS/MapReduce#MapReduce-Parallelism
As of right now, MapReduce jobs on a
single mongod process are single
threaded. This is due to a design
limitation in current JavaScript
engines. We are looking into
alternatives to solve this issue, but
for now if you want to parallelize
your MapReduce jobs, you will need to
either use sharding or do the
aggregation client-side in your code.
Without parallelism, what are the benefits of MapReduce compared to simpler or more traditional methods for queries and data aggregation?
To avoid confusion: the question is NOT "what are the benefits of document-oriented DB over traditional relational DB"
The main reason to use MapReduce over simpler or more traditional queries is that it simply can do things (i.e., aggregation) that simple queries cannot.
Once you need aggregation, there are two options using MongoDB: MapReduce and the group command. The group command is analogous to SQL's "group by" and is limited in that it has to return all its results in a single database response. That means group can only be used when you have less than 4MB of results. MapReduce, on the other hand, can do anything a "group by" can, but outputs results to a new collection so results can be as large as needed.
Also, parallelism is coming, so it's good to have some practice :)
M/R is already parallel in MongoDB if you're running a sharded cluster. This is the main point of M/R anyway - to put the computation on the same node as the data.
super fast map/reduce is on the roadmap
it will not be in the 1.6 release (summer release)
so late this year likely
