首先，我正在使用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()報告的統計數據，所以我想這是針對光盤上的壓縮數據，而不是實際需要多少內存一次。
希望這一點額外的信息幫助！