mongodb一个collection里存了日志，现在要进行统计分析。因为是记录日志，所以经常插入信息，也就没有索引。但是分析查表的时候没有索引又特别慢。想问下有没有什么好的方法。暂时2000W数据量。
闭关修行中......
通常来说索引对写性能不应该有十分明显的影响，当然如果你需要加的索引很多，那另当别论。如果没有试过，建议先试一下你需要的索引到底带来多大副作用，是否在接受范围内。如果在，那很好，问题解决。如果不能接受，那可以考虑下面两个方案：
使用sharding进行改造。你应该已经知道sharding是什么了，不多做解释。这个方案带来的问题显然就是服务器数量会有明显增加，这也是水平扩展的必然结果。长远来看，如果你的业务向前发展，这也是必经的道路，所以可以早做打算。
在不同的复制集结点上创建不同的索引如果你现在还在用单结点运行，那建议赶紧升级到复制集。单结点硬件故障丢了数据找不回来的案例比比皆是，不要等发生了再后悔。在复制集的前提下，每个结果是可以单独建立不同的索引的。
停止结点
以不同的端口去掉复制集配置后启动
在这个结点上构建你所需要的索引
以原配置重新启动
需要注意的是复制集仍然要完成主结点上所有的写操作，所以索引太多仍然可能造成问题。一切还是要你自己亲测得出结论。
要么加索引，要么换elasticsearch或hbase。建议尽早换elasticsearch
通常来说索引对写性能不应该有十分明显的影响，当然如果你需要加的索引很多，那另当别论。如果没有试过，建议先试一下你需要的索引到底带来多大副作用，是否在接受范围内。如果在，那很好，问题解决。如果不能接受，那可以考虑下面两个方案：
使用sharding进行改造。
你应该已经知道sharding是什么了，不多做解释。这个方案带来的问题显然就是服务器数量会有明显增加，这也是水平扩展的必然结果。长远来看，如果你的业务向前发展，这也是必经的道路，所以可以早做打算。
在不同的复制集结点上创建不同的索引
如果你现在还在用单结点运行，那建议赶紧升级到复制集。单结点硬件故障丢了数据找不回来的案例比比皆是，不要等发生了再后悔。在复制集的前提下，每个结果是可以单独建立不同的索引的。
停止结点
以不同的端口去掉复制集配置后启动
在这个结点上构建你所需要的索引
以原配置重新启动
需要注意的是复制集仍然要完成主结点上所有的写操作，所以索引太多仍然可能造成问题。一切还是要你自己亲测得出结论。
要么加索引，要么换elasticsearch或hbase。建议尽早换elasticsearch