MongoDB虽然不像我们常用的mysql，sqlserver，oracle等关系型数据库有group by函数那样方便分组，但是MongoDB要实现分组也有3个办法：
Mongodb三种分组方式：
1、group(先筛选再分组，不支持分片，对数据量有所限制，效率不高) http://php.net/manual/zh/mongocollection.group.php
2、mapreduce(基于js引擎，单线程执行，效率较低，适合用做后台统计等)
3、aggregate(推荐) (如果你的PHP的mongodb驱动版本需>=1.3.0，推荐你使用aggregate，性能要高很多，并且使用上要简单些，不过1.3的目前还不支持账户认证模式，可以通过http://pecl.php.net/package/mongo查看更新日志和Bug) http://php.net/manual/zh/mongocollection.aggregate.php
操作系统：CentOS 5.X
源服务器：192.168.21.129
目标服务器：192.168.21.127，192.168.21.128
目的：把源服务器上/home/www.osyunwei.com目录实时同步到目标服务器的/home/www.osyunwei.com下
在前面的博文中，我讲到过利用rsync实现数据的镜像和备份，但是要实现数据的实时备份，单独靠rsync还不能实现，本文就讲述下如何实现数据的实时备份。
与传统的cp、tar备份方式相比，rsync具有安全性高、备份迅速、支持增量备份等优点，通过rsync可以解决对实时性要求不高的数据备份需求，例如定期的备份文件服务器数据到远端服务器，对本地磁盘定期做数据镜像等。
随着应用系统规模的不断扩大，对数据的安全性和可靠性也提出的更好的要求，rsync在高端业务系统中也逐渐暴露出了很多不足，首先，rsync同步数据时，需要扫描所有文件后进行比对，进行差量传输。如果文件数量达到了百万甚至千万量级，扫描所有文件将是非常耗时的。而且正在发生变化的往往是其中很少的一部分，这是非常低效的方式。其次，rsync不能实时的去监测、同步数据，虽然它可以通过linux守护进程的方式进行触发同步，但是两次触发动作一定会有时间差，这样就导致了服务端和客户端数据可能出现不一致，无法在应用故障时完全的恢复数据。基于以上原因，rsync+inotify组合出现了！
下面文章转载自火丁笔记，原作者描述了一次MongoDB数据迁移过程中遇到的性能问题及其解决方案，中间追查问题的方法和工具值得我们学习。下面是其原文：
最近忙着把一个项目从MySQL迁移到MongoDB，在导入旧数据的过程中，遇到了些许波折，犯了不少错误，但同时也学到了不少知识，遂记录下来。
公司为这个项目专门配备了几台高性能务器，清一色的双路四核超线程CPU，外加32G内存，运维人员安装好MongoDB后，就交我手里了，我习惯于在使用新服务器前先看看相关日志，了解一下基本情况，当我浏览MongoDB日志时，发现一些警告信息：
WARNING: You are running on a NUMA machine. We suggest launching mongod like this to avoid performance problems: numactl –interleave=all mongod [other options]
当时我并不太清楚NUMA是什么东西，所以没有处理，只是把问题反馈给了运维人员，后来知道运维人员也没有理会这茬儿，所以问题的序幕就这样拉开了。
在 MySQL中，慢查询日志是经常作为我们优化数据库的依据，那在MongoDB中是否有类似的功能呢?答案是肯定的，那就是Mongo Database Profiler.不仅有，而且还有一些比MySQL的Slow Query Log更详细的信息。它就是我们这篇文章的主题。
开启 Profiling 功能
有两种方式可以控制 Profiling 的开关和级别，第一种是直接在启动参数里直接进行设置。
启动MongoDB时加上 –profile=级别 即可。
也可以在客户端调用db.setProfilingLevel(级别) 命令来实时配置。可以通过db.getProfilingLevel()命令来获取当前的Profile级别。