MongoDB:随机与顺序读取性能

Question

我有一个单实例mongodb，它的集合包含3个字段：_id、block_id、负载。

• 有效载荷总是4096字节二进制文件。
• _id是一个不断递增的唯一整数。

在集合上有一个二级索引：

{ "v" : 1, "key" : { "block_id" : 1, "_id" : -1 }, 
  "ns" : "testdb.testdev", "name" : "_block_id_id" }

我做了很多查询，比如：

query: { query: { block_id: 868413 }, orderby: { _id: -1 } } ntoreturn:1 nscanned:1 nreturned:1 reslen:4166 163ms

在这些过程中没有其他查询。当我按顺序阅读block_id时，它比使用随机block_id查询时快10倍。我的cpu使用率很低，内存利用率很低。该集合比内存大小大2-3倍。

这里的瓶颈是什么？

Answer 1

这里有几件事要澄清：

1. 默认情况下，您只会看到缓慢的查询(>100 be )，您可以在这个阈值下执行数百万个永远不会被记录的查询。
2. 找出缓慢操作的原因的方法是在记录缓慢操作时查看统计数据。
3. 您应该使用.explain()重新运行这些查询，以确保它们使用的是您认为的索引。

就统计数据而言，有两种基本的方法来获得它们。首先，也是最快的，是蒙哥特和蒙哥托。这两个实用程序附带了MongoDB，可以用来确定您的数据库要做什么。

另一种选择是彩信 ( MongoDB监视服务)--它是免费的，它允许您随着时间的推移绘制所有相关的统计数据，因此当您看到慢度时，您可以确定什么是尖峰/下降。如果您沿着这个路径(请参阅MMS )安装munin，我建议安装它，因为它将为您提供IO统计数据和MongoDB统计数据的视图。

您通常会查找以下内容之一：

1. 页面错误-如果这是尖峰，您的查询导致分页到磁盘-这是一个数量级的速度比内存中的操作，需要最小化。
2. 驻留内存-与页面错误密切相关，这表示您在内存中的工作集。您提到您的数据集是内存大小的2-3倍，但是您是否在该估计中包括索引(请参阅db.collection.stats()命令)

还有很多其他的事情要看，但考虑到你的描述，这是一个很好的开始。请记住，如果您有内存争用，新的东西越有可能已经在内存中。由于您使用的是顺序ID，所以我希望旧ID(除非最近更新或触摸)比新ID更多地出现在慢速查询日志中(这是操作系统通常管理内存的方式--请参阅LRU获取更多信息)。

在解决这类性能问题方面，除了添加更多RAM外，您还应该查看：

1. 删除可能占用空间的不需要的索引。
2. 如果可能的话，查看如何使用覆盖指数查询(不需要在数据中页面，只需索引)
3. 查看readahead设置--这是一个冗长而复杂的主题--有关更多信息(以及更多信息)，请参见这里和这里。