Question

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

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

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

示例文件：

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

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

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

在此示例中，显然应将type字段编入索引。到现在为止还挺好。但是，此数据的访问模式将完全随机。在给定时间，我不知道将访问哪些文档范围。我只知道它们将在索引字段上查询，一次返回最多100000个文档。

在我看来，这意味着MongoDB / WiredTiger中的缓存几乎没用。唯一需要适应缓存的是索引。如果不是不可能的话，估计工作集很难吗？

我正在寻找的主要是关于使用什么类型的索引以及如何为这种用例配置MongoDB的技巧。其他数据库会更好用吗？

目前我发现MongoDB在有限的硬件（16 GB RAM，非SSD光盘）上运行良好。如果结果集已经在缓存中，则查询会以适当的时间返回，并且显然会立即返回。但正如已经说过的，这很可能不是典型的情况。查询是快速的，并且它们是可靠的并且数据库将以稳定的方式运行并不重要。

修改

猜猜我遗漏了一些重要的事情。该数据库主要用于存档目的。因此，数据来自另一个来源，例如每天一次。更新将非常罕见。

我使用的例子有点做作，但实质上这就是查询的样子。当我提到多个索引时，我的意思是该示例中的type和color字段。因此，将使用这些字段查询文档。就像现在一样，我们只关心返回具有特定type，color等的所有文档。当然，我们的计划是仅查询我们有索引的字段。所以临时查询不在桌面上。

目前，索引大小非常易于管理。对于5亿个文档，这些索引中的每个索引大约为2.5GB，并且很容易放入RAM中。

关于操作的平均数据大小，我只能在此时进行推测。据我所知，典型的操作返回大约20k文档，平均对象大小在1200字节范围内。这是db.stats()报告的统计数据，所以我猜它是针对光盘上的压缩数据，而不是它在RAM中实际需要多少。

希望这些额外的信息有所帮助！

Answer 1

基本上，如果你在type之上具有统一随机的一致读取率（这就是我正在采取的

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

表示），然后您将从数据库中看到稳定的性能。它将从缓存中执行一些稳定的读取操作，只是通过好运，并通过从磁盘读取另一个稳定的比例，特别是如果文档的数量和大小在不同type值之间大致相同。除了更好的硬件之外，我认为没有特别的索引或任何东西可以帮助你。索引应保留在RAM中，因为它们将不断被使用。

我想更多的信息会有所帮助，因为你只在type上提到了一个简单的查询，但随后谈到让多个索引担心保留在RAM中。平均操作返回多少数据？您是否曾经关注某些type或仅所有文档的文档子集？这个集合的插入和更新是什么样的？

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