用於收集的 MongoDB 文件大小 - 對 RAM 和查詢性能的影響
我在 stackoverflow 上被建議在 dba.stackexchange 上問這個問題 -
我們正在使用帶有 WiredTiger 儲存的 MongoDB 3.0 版。
作為 MongoDB 的新手，我們可能基於各種書籍和文章的有限知識天真地設計了我們的模式，並希望改進設計以獲得更好的性能。
一到兩個集合的平均對像大小為 52.3 KB，這些集合最終可能有數百萬條記錄，我們可能會對其進行分片。我想知道的是 - 如果我們查詢集合會對 RAM 產生什麼影響。請注意，文件的大小不會隨時間增長太多。
例如 - 1 個文件（平均對像大小為 52KB）有 91 個欄位/屬性，其中包括數組和子文件。假設我對特定查詢中的大約 5 個欄位感興趣，並且我在投影參數中指定了這些欄位 - 我已經驗證在我的查詢中使用了適當的索引。mongoDB 是否將僅將這 5-6 個欄位載入到 RAM 中 - 我感興趣的那些 - 或者俱有 91 個欄位且大小為 52KB 的整個文件。我的問題是針對兩者的-
- 普通查詢
- 基於聚合的查詢
這將有助於估計我的工作集大小。另一件事是，有許多其他類型的查詢需要在同一個集合和文件上使用不同的屬性集——因此覆蓋查詢索引可能不適用於所有查詢。
我是否應該探索根據使用模式拆分為不同集合的可能性，即使它們可能都是真正的 1:1 關係？另一方面，如果許多屬性一起更新，這將不能保證原子寫入。
我問的原因是我最近觀察到，如果我將集合縮減為僅幾個基本屬性，geoNear 聚合查詢肯定會更快。我有一種預感，可能 MongoDB 可能會將整個文件放入 RAM，因為它記憶體映射數據文件。
將來，請要求將問題遷移到此處，而不是重複發布。
從MongoDB 文件中，
要計算您需要多少 RAM，您必須計算您的工作集大小，或客戶最常使用的數據部分。這取決於您的訪問模式、您擁有的索引以及文件的大小。因為 MongoDB 每個連接模型使用一個執行緒，所以每個數據庫連接也需要高達 1MB 的 RAM，無論是活動的還是空閒的。
如果查詢沒有完全被索引覆蓋，那麼整個文件將由 MongoDB 載入到 RAM 中。無論查詢的類型如何，這都是相同的。
至於您是否應該拆分您的收藏，這確實是一個設計決策，需要更多的背景知識來理解和權衡。您需要執行測試，以查看基於查詢模式的收益是否值得與原子性的損失（可能是業務驅動的決策）相比。
不過，我可能不會推薦這種方法，並且會評估您真正的 SLA 是什麼，以及您是否使用正確數量的硬體 (RAM) 來獲得所需的結果。您真正的問題是“在記憶體數據方面，我是否有足夠的 RAM 來滿足我的查詢性能要求？” 如果答案是否定的，請找出最適合您的約束的設計。