mongodb单条记录大小对查询性能有影响吗？

Question

1.我们的业务场景下存储在mongodb 的数据是中有一个属性字段很大，2000多位的int型数组，mongodb统计显示平均记录大小是21kb左右(AverageObjecrSize是21000)，我们的业务场景数据量又很大，但是我验证了去除这个字段的话，平均大小就会降低到1kb左右。按照1亿的数据规模计算，前者相当于是20K*1亿是2TB，后者缩小了约20倍是100GB，因为Mongodb会占用大量内存，缓存热数据。按照每条记录20K的情况，如果有100G的内存用于缓存数据，只能缓存500万，约5%的数据。按照1K计算就可以缓存约全部数据了。当然查询性能还和索引以及诸多因素相关。但是我想问的是单条记录大小对应查询这块到底是否有影响，就内存和记录大小这2个因素来说的话，我这样的理解是否正确。请指教。

Answer 1

有一定道理，但不完全正确。离开实际情况谈性能都是在耍流氓。

因为Mongodb会占用大量内存，缓存热数据

不是MongoDB，所有数据库都是这样的策略。所以结果就是，如果所有数据都能放进内存中，肯定是性能最好的情况，因为所有读操作不需要等待磁盘，会明显地快很多。但是实际情况是，并不是所有场景下都可以把全部数据都塞进内存里。那么退而求其次，就会要求所有索引在内存中，数据能缓存多少算多少，没有的就从磁盘读。虽然不如前一种情况，但通常也是可以接受的，因为：

• 我们通常进行的是OLTP类型的查询，这种查询有个显著的特点是往往需要从大量数据中选出少量数据并读出来。我们常见的线上应用通常都是这种情况。
• 与之对应的是OLAP类型查询，往往是需要读取大量数据进行分析运算。因为索引本身对OLAP的帮助就非常有限，而OLAP又往往涉及大量数据不可能全部存放到内存中。好在OLAP一般并不在乎执行时间长。在这种情况下对数据库的要求也是完全不一样的，因此以下的讨论对OLAP不适用。
• 在OLTP的前提下，我们需要的索引已经在内存中了，不需要依赖磁盘。索引可以给出少量结果集，这些结果集可能在内存中也可能不在。但因为量小，就算从磁盘读也不会严重影响性能。这里实际上隐含了1个前提：查询必须命中索引。对于OLTP查询而这是绝对必要的。

所以，多快算快？全部放进内存是很快不错，只把索引放在内存不见得不可接受（而且大部分时候是可以接受的）。从这个角度来说，文档大小对你的性能是有影响，但不见得有你想象的严重。因为每次读出来的只是很少量的数据。