How good (or bad) does MongoDB handle map reduce in terms of performance? Do you really need a lot of machines to get acceptable performance?
MongoDB的Map / Reduce实现(从2.0.x开始)受到其对单线程SpiderMonkey JavaScript engine的依赖的限制.已经对v8 JavaScript engine进行了一些实验,并且改进的并发性和性能是整体设计目标.
新的Aggregation Framework是用C语言编写的,具有更加可扩展的实现,包括“管道”方法.每个管道当前都是单线程的,但您可以并行运行不同的管道.聚合框架目前不会替换可以在Map / Reduce中完成的所有作业,但确实简化了许多常见用例.
第三种选择是通过MongoDB Hadoop Connector将MongoDB与Hadoop结合使用.Hadoop目前具有更具可扩展性的Map / Reduce实现,并且可以通过Hadoop Connector访问MongoDB集合以进行输入和输出.
In terms of workflow, is it relatively easy to store and merge the incremental results generated by map reduce?
Map / Reduce有几个output options,包括将增量输出合并到先前的输出集合中或返回结果内联(在内存中).
How much of a performance improvement does the aggregation framework offer?
这实际上取决于Map / Reduce的复杂性.总体而言,聚合框架更快(在某些情况下,显着更快).您最好对自己的用例进行比较.
MongoDB 2.2尚未正式发布,但2.2rc0 release candidate自7月中旬开始供货.
Does the aggregation framework offer the ability to store results incrementally in a similar manner that the map/reduce functionality that already exists does.
聚合框架目前仅限于内联返回结果,因此您必须在返回结果时处理/显示结果.结果文档也仅限于MongoDB中的最大文档大小(目前为16MB).
有一个建议的$out管道命令(SERVER-3253),将来可能会添加更多输出选项.
一些可能感兴趣的进一步阅读: