Mongodb 优化随机读取

首先，我将MongoDB 3.0与新的WiredTiger存储引擎一起使用。还使用snappy进行压缩

我试图从技术角度理解和优化的用例如下：

我有一个相当大的集合，大约有5亿个文档，包括索引在内，大约需要180 GB

示例文件：

{
  _id: 123234,
  type: "Car",
  color: "Blue",
  description: "bla bla" 
}

查询包括查找具有特定字段值的文档。就这样,

thing.find( { type: "Car" } )

在本例中，类型字段显然应该被索引。到现在为止，一直都还不错。但是，该数据的访问模式将是完全随机的。在给定的时间内，我不知道将访问哪些范围的文档。我只知道它们将在索引字段上查询，一次最多返回100000个文档

在我看来，这意味着MongoDB/WiredTiger中的缓存几乎毫无用处。缓存中唯一需要容纳的就是索引。如果不是不可能的话，估计工作组是很困难的

我要寻找的主要是关于使用哪种索引以及如何为这种用例配置MongoDB的提示。其他数据库是否工作得更好

目前，我发现MongoDB在有限的硬件16 GB RAM、非SSD光盘上工作得相当好。如果结果集已经在缓存中，查询会在适当的时间返回，而且很明显会立即返回。但正如前面所述，这很可能不是典型的情况。查询是否闪电般快速并不重要，更重要的是它们是否可靠，数据库是否以稳定的方式运行

编辑：

我想我遗漏了一些重要的事情。数据库将主要用于存档目的。因此，数据从另一个来源大量到达，比如说一天一次。更新将是非常罕见的

我使用的示例有点做作，但本质上这就是查询的样子。当我提到多个索引时，我指的是该示例中的类型和颜色字段。因此，将使用这些字段查询文档。现在，我们只关心返回所有具有特定类型、颜色等的文档。当然，我们的计划是只查询有索引的字段。因此，临时查询已不存在

现在索引的大小是可以管理的。对于5亿个文档，每个索引大约为2.5GB，并且很容易放入RAM中

关于一个操作的平均数据大小，我现在只能推测。据我所知，典型的操作返回大约20k个文档，平均对象大小在1200字节的范围内。这是db.stats报告的统计数据，所以我猜这是针对磁盘上的压缩数据，而不是它在RAM中实际花费的时间

---

希望这一点额外的信息有帮助

基本上，如果你有一个一致的读取速率，它在类型上是均匀随机的，这就是我所采用的

我不知道将访问哪些范围的文档

也就是说，您将从数据库中看到稳定的性能。幸运的是，它将从缓存中执行一些稳定的读取比例，并且通过从磁盘读取来执行另一个稳定的读取比例，特别是当不同类型值之间的文档数量和大小大致相同时。我认为除了更好的硬件之外，没有什么特别的索引或任何东西可以帮助你。索引应该保留在RAM中，因为它们将不断被使用

我想更多的信息会有所帮助，因为您只提到了一个关于类型的简单查询，然后谈到了在RAM中保存多个索引的问题。平均操作返回多少数据？您是否愿意返回某些类型的文档子集，或者只返回所有文档？此集合的插入和更新是什么样子的

此外，如果正在读取的文档在数据集上确实是完全随机的，那么工作集就是所有数据