有玩 mongo 的 mapreduce 的吗, 请教个问题。

阿里的ODPS就是这样建议的

用数据库做mr就是zuo si的节奏，更何况是mongo

如果mongo足够大，写入之后立刻查询，得到的基本是写入前的结果。
mongo适合记录一些初始数据，然后跑脚本在后台处理成你想要的数据。
mongo的数据要展示到前台，最好是提前处理好的。
与用户实时交互的数据，一般不能使用mongo。

@gt11799 这个mongo默认写入是非安全模式的，有可能会出现这种情况，你打开安全不可以解决这个问题么？

最好不要，mongo的速度受内存影响大；分区后mr没有优势；通常mr是单线程的（除非自己构造数据）；repair的时候会锁住等等一系列毛病…要是在线使用，很容易服务中断

我以前是定时跑mr,然后把结果放到表里

如果是聚合需求的话，基本上count、distinct、aggregate就完成绝大多的处理功能，而且mongodb本身也对这些方法进行了很好的优化，效率很高，能用这些就不要用mapReduce，虽然mapReduce能实现上述几种聚合方法的功能，但是因为没有进行优化，所以非常慢。通常的建议是，如果你有即时的聚合查询需求，不要用mapReduce。

mapReduce是mongodb早期设计了，采用内置的js引擎来实现统计汇总，因此还有js引擎独占锁的问题。从输出方式也能看出来是不建议直接前台用的：要么inline方式输出一个结果集（有大小限制），要么用结果插入一张表，插入表的方式是比较建议的。
aggregation是新的设计，通过流水线实现统计汇总，写起来更难理解，但是性能上面好多了。从输出方式来看，支持游标方式输出，能直接在线输出很大的结果集。
ps，mapReduce的两个函数如果写不好（例如死循环了）是可以把整个服务器拖死的；从2.6的权限模型看，mongodb已经开始尽量限制服务器端脚本的应用，所以还是用aggregation更好。

@sujin190 如果是在复制集（replication set）中，总不能要求等所有节点都写入了才返回吧，那样随便挂掉一个节点，前台服务就卡死了。如果只要求一两个节点，和非安全写入在上面那个问题的感受上没啥区别。
而且ReadReference一般建议是找最近或者最快的非写入节点，以降低写入节点的压力，这个情况下写入之后要有一个间隔才会读到。

@notxx 这个是mongo的问题么？mysql主从也有这个问题啊，当遇到这个问题时，说明你上层没设计好

@sujin190 可能不是所有人都熟悉这个状况啊，而且我主要的点还是WriteConcern其实不是为了这个用的。

@notxx 因为看到好多做监控的提到了mongo，是说也是用mongo来进行存储一些组件的运行情况。他只是适合用来存实时性不那么强的数据？觉得监控应该实行性还行的吧。
当然我操作mongo的时候用的是异步客户端Motor。

@no13bus 其实我觉得@sujin190 说的没错，更重要的是设计本身。以我的经验来看，如果你能设计出来适合mongodb的数据结构，那么从各个角度（性能、使用弹性和服务弹性）都是很好的。但是反过来来说，如果出现了反设计（或者仅仅是不适合mongodb的设计）就很麻烦了。
或者简单来说，优化mongodb部署的时候你可以要求实时写入，也可以要求实时读取，但是读写都实时，而且要求不会脏读，恐怕不是能够实现的。