产品中心
结论：
1、 200w数据，合理使用索引的情况下，单个stationId下4w数据。mongodb查询和排序的性能理想，无正则时client可以在600ms+完成查询，qps300+。有正则时client可以在1300ms+完成查询，qps140+。
2、 Mongodb的count性能比较差，非并发情况下client可以在330ms完成查询，在并发情况下则需要1-3s。可以考虑估算总数的方法，http://blog.sina.com.cn/s/blog_56545fd30101442b.html
测试环境：mongodb使用 replica set，1主2从，96G内存，版本2.6.5
Mem消耗（4个200w数据的collection）：
空间消耗（测试数据最终选定的collection）：
Jvm: -Xms2G -Xmx2G
Ping延迟33ms
查询都使用ReadPreference.secondaryPreferred()
无正则
1、 创建stationId, firmId复合引查询场景（200w集合，12个字段）
查询次数：20000
查询条件：多条件查询10条记录，并逐条获取记录
关于MongoDB 查询优化原则的大家了解吗？下文给大家介绍下，具体内容如下所示：1.在查询条件、排序条件、统计条件的字段上选择创建索引，可以显著提高查询效率。
2.用$or时把匹配最多结果的条件放在最前面，用$and时把匹配最 少 结果的条件放在最前面。
3.使用limit()限定返回结果集的大小，减少数据库服务器的资源消耗，以及网络传输的数据量。
4.尽量少用$in，而是分解成一个一个的单一查询。尤其是在分片上，$in会让你的查询去每一个分片上查一次，如果实在要用的话，先在每个分片上建索引。
5.尽量不用模糊匹配查询，用其它精确匹配查询代替，比如$in、$nin。
6.查询量大、并发大的情况，通过前端加缓存解决。
7.能不用安全模式的操作就不用安全模式，这样客户端没必要等待数据库返回查询结果以及处理异常，快了一个数量级。
8.MongoDB的智能查询优化，判断粒度为query条件，而skip和limit都不在其判断之中，当分页查询最后几页时，先用order反向排序。
9.尽量减少跨分片查询，balance均衡次数少。
10.只查询要使用的字段，而不查询所有字段。
11.更新字段的值时，使用$inc比update效率高。
12.apped collections比普通collections的读写效率高。
13.server-side processing类似于SQL查询的存储过程，可以减少网络通讯的开销。
14.必要时使用hint()强制使用某个索引查询。
15.如果有自己的主键列，则使用自己的主键列作为id，这样可以节约空间，也不需要创建额外的所以。
16.使用explain，根据exlpain plan进行优化。
17.范围查询的时候尽量用$in、$nin代替。
18.查看数据库查询日志，具体分析的效率低的操作。
19.mongodb有一个数据库优化工具database profiler，能够检测数据库操作的性能。可以发现query或者write操作中执行效率低的，从而针对这些操作进行优化。
20.尽量把更多的操作放在客户端，当然这就是mongodb设计的理念之一。
