以下讨论的问题，有一个前提，就是要保存的数据大于内存容量。否则你可无视之。。。 索引占用的空间有时候超出你的想象。 即使集合中只有一个默认的索引 _id, 1 亿条记录，索引占用超过 5G 。如果内存不足以保存索引，赶紧加内存吧 ~~~ 查询或者更新的速度，
以下讨论的问题，有一个前提，就是要保存的数据大于内存容量。否则你可无视之。。。
索引占用的空间有时候超出你的想象。即使集合中只有一个默认的索引_id, 1亿条记录，索引占用超过5G。如果内存不足以保存索引，赶紧加内存吧~~~
查询或者更新的速度，有时候与文档数量的关系并不大。我在网上看到的最多的是，mongodb的速度与文档数量有关，与文档所占用空间的关系谈的人不多。我尝试在一台16G的机器上，添加100w文档，索引占用的空间大概100M不到。每个文档大小大概为50k, 100w的数据量大概占用的磁盘空间是50G，然后随机的update或者find_one这100w个文档，update操作不会改变原有记录大小。原本以为才这点数据，mongodb应该像火箭一样飞起来，结果出乎意料，速度慢的要死，每秒大概只能更新50条记录左右，通过iostat或者mongostat查询，你会发现磁盘像疯了一样的转，好像吃了*，停也停不下来。想想我在sqlite中，100w记录量，查询的速度都比这要快。为什么会这么慢？mongodb也不过如此，可能还不如自己写的程序来的快？真的吗？
了解一些b-tree的知识对使用mongodb或者其他关系数据库有好处。但索引不是万能，别以为充分利用了索引就以为mongodb会像火箭一样飞起来，有时候他会比蜗牛爬的还慢。应该根据业务需求，充分考虑数据在磁盘上保存的顺序和索引的关系，合理的设计索引。以前在学sqlserver的时候，书上说主键很重要，因为数据在磁盘上保存的顺序就是按主键的顺序来的，好像一本新华字典，书上的字按拼音的顺序保存，虽然我们也可以按部首去查询某个字，但要像获取所有”a”开头的汉字，总比获取所有“亻”的汉字要快的多。
如果热点数据在内存中，查询与更新操作非常快，亿级数据，单实例不分片，每妙能处理上千次查询或者更新操作。否则，你的磁盘会转个不停，而且非常慢。即使充分使用了索引，因为数据不在内存中，操作系统需要先卸载部分数据腾出内存空间（如果内存不够的话）去映射磁盘上的数据。这个过程磁盘会疯一样的转。
Mongodb的内存管理是交给操作系统的，即使mongodb重启，系统可能并不会立即释放系统cache，这个时候，如果热点数据还没有被系统卸载掉，查询的速度还是非常快的。这常常会给人以假象，mongodb很快。。。
总之，索引与热点数据有多大，就给mongodb分配多大的内存。如果主要是保存数据，那么只要磁盘足够大，mongodb都可以把数据塞进去。
Last: good luck…
原文地址：Mongodb使用小结, 感谢原作者分享。
