mongodb - Mongo 映射/减少大型集合的减速

Question

我们有一个看似简单的 map/reduce 作业，它每天都要处理日志记录数据。在开发服务器上，我们可以对大量文档(约 1M)运行此作业，大约需要一分钟，没有任何问题。我们将作业移至生产服务器，即 Amazon EC2 服务器，该作业将以非常快的速度处理大约 50% 的行，然后爬取其余数据。浏览数十万份文件可能需要数小时，而不是预期的一两分钟。所以我希望我们在 map/reduce 作业中犯了一个明显的错误。

这是一个示例输入文档:

{    "_id" : ObjectId("4f147a92d72b292c02000057"),    "cid" : 25,    "ip" : "123.45.67.89",    "b" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7",    "r" : "",    "l" : "en-US,en;q=0.8",    "ts" : ISODate("2012-01-16T19:29:22Z"),    "s" : 0,    "cv" : "4f143a5fd72b292d7f000007",    "c" : ""}

我们只查询一系列 _id。

这是 map 代码:

function() {     var browser = {}    ,referrer = {};    browser[this.b] = {        'count': 1    };    referrer[this.r] = {        'count': 1    };    var objEmit =  {        'count': 1        ,'browsers' : browser        ,'referrers' : referrer    };    var date = this._id.getTimestamp();    date.setHours(0);    date.setMinutes(0);    date.setSeconds(0);    emit({'cv' : this.cv, 'date' : date, 'cid' : this.cid }, objEmit);};

这里是reduce代码:

function (key, emits) {    var total = 0    ,browsers = {}    ,referrers = {};    for (var i in emits) {        total += emits[i].count;        for (var key in emits[i].browsers) {            if (emits[i].browsers.hasOwnProperty(key)) {                !(browsers[key]) && (browsers[key] = { count : 0 });                browsers[key].count +=  emits[i].browsers[key].count;            }        }        for (var key in emits[i].referrers) {            if (emits[i].referrers.hasOwnProperty(key)) {                !(referrers[key]) && (referrers[key] = { count : 0 });                referrers[key].count += emits[i].referrers[key].count;            }        }    }    return {'count' : total, 'browsers' : browsers, 'referrers' : referrers}};

没有最终确定，我们将 map/reduce 作业输出到现有集合，并将“merge”选项设置为 true。

非常感谢任何帮助。

Answer 1

由于它是在开发和生产中运行的相同代码，并且您在非常大的集合上在开发中运行它并且返回速度非常快，您怀疑您的代码可能有问题的任何特定原因是什么？

您是否有可能在微型实例上运行？如果您不知道，Micro instances cap average CPU usage这可能会导致大量数据在不允许处理的情况下建立起来，从而损害您的 Map-Reduce 事件(I/O 没有以相同的方式受到限制，因此不断进入，然后 Linux 内核大部分时间都在管理它并使事情变得更糟)。

从 Micro 切换到 Small，即使 CPU 速度较低，也可能对您有所帮助，因为您有一个恒定的 CPU 周期“流”来工作(就像普通机器一样)并且 MongoDB 的内部调度可能会更好地适应。

这在以前可能不是问题，因为正常的查询“尖峰”持续时间不足以导致 CPU 限制开启。