里面執(zhí)行是否是單線程我不知道， 但是， 如果是生產(chǎn)環(huán)境的話， 最好還是別每次直接去訪問mapReduce 的結(jié)果，根據(jù)數(shù)據(jù)量的大小，還是會花費一定的時間的。我們的數(shù)據(jù)是千萬級別， 每次執(zhí)行mapReduce，大概需要5-6秒時間， 還好我們的應用不是對實時性很高。 所以基本上是緩存2個小時的數(shù)據(jù)， 然后在去執(zhí)行mapReduce 獲取最新的結(jié)果。

之前使用MapReduce做過類似的事情，因為耗時，后來修改成使用聚合查詢做統(tǒng)計，具體示例如下：

> db.user.findOne()
{    "_id" : ObjectId("557a53e1e4b020633455b898"),    "accountId" : "55546fc8e4b0d8376000b858",    "tags" : [        "金牌會員",        "鉆石會員",        "鉑金會員",        "高級會員"
    ]
}

基本的文檔model如上，我在accountId和tags上做了索引

db.user.ensureIndex({"accountId":1, "tags":1})

現(xiàn)在要求統(tǒng)計用戶下面的tags，MapReduce設計如下：

var mapFunction = function() {   if(this.tags){       for (var idx = 0; idx < this.tags.length; idx++) {           var tag = this.tags[idx];
           emit(tag, 1);
       }
   }
};var reduceFunction = function(key, values) {    var cnt=0;   
    values.forEach(function(val){ cnt+=val;});  
    return cnt;
};


db.user.mapReduce(mapFunction,reduceFunction,{out:"mr1"})    //輸出到集合mr1中

結(jié)果：

> db.mr1.find().pretty()
{ "_id" : "金牌會員", "value" : 9000 }
{ "_id" : "鉆石會員", "value" : 43000 }
{ "_id" : "鉑金會員", "value" : 90000 }
{ "_id" : "銅牌會員", "value" : 3000 }
{ "_id" : "銀牌會員", "value" : 5000 }
{ "_id" : "高級會員", "value" : 50000 }

看似達到我們的效果, 我只是拿少量的數(shù)據(jù)10W做的上面的測試, 執(zhí)行的過程中,它會輸出:

> db.mapReduceTest.mapReduce(mapFunction,reduceFunction,{out:"mr1"}){    "result" : "mr1",    "timeMillis" : 815,                   //耗時多久
    "counts" : {        "input" : 110000,             //掃描的文檔數(shù)量
        "emit" : 200000,              //mongo執(zhí)行計算的次數(shù)
        "reduce" : 2001,        "output" : 6
    },    "ok" : 1}

因為我mock的數(shù)據(jù)比較簡單有規(guī)律，可以看出它的計算次數(shù)幾乎是掃描的文檔數(shù)量的二倍，后來使用隨機的數(shù)據(jù)做測試，發(fā)現(xiàn)結(jié)果更糟糕，果斷放棄MapReduce的實現(xiàn)，改用其他實現(xiàn)。