共計 1814 個字符，預計需要花費 5 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

MongoDB 數據庫容量規劃是指什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

MongoDB 數據庫容量規劃是什么

我們討論的存儲，說到底都是基于操作系統之上的一個應用軟件，而操作系統能利用的，無非是系統的存儲：磁盤、內存、CPU cache 等等。所以容量規劃的意義就是：按要存儲的數據特點，針對一段時間的數據量，對機器各個存儲的容量、性能及系統配置進行合理預估。

通常這個問題在實際容量規劃中可以化簡為對內存，硬盤容量和性能的預估。

下面我們就以 MongoDB 為例說一下容量預估的一些計算方法。我們通常的一個粗糙的要求是要將所有熱數據放到內存中。這里的熱數據可能包括經常訪問的數據，索引和系統開銷。下面我們就這三個方面進行說明：

常訪問的數據

根據不同的應用場景，你可以對數據訪問情況進行預估。比如用 MongoDB 保存帖子內容，每個帖子大小為 1k，目前有 1 億個帖子，每天新增 100w 個帖子，那么 3 個月后帖子量大概為 2 億，需要 200G 的硬盤空間。

每天新增的 100w 帖子是常訪問的，而可能我們每天活躍訪問的貼子為 200w，也就是說另外 100w 是之前的老帖子。如果我們規劃給熱數據的內存大小為 1G，那只能裝下 100w 數據，裝不了 200w 數據。由于帖子訪問的隨機性，最壞的情況是我們每次訪問的數據都不在內存中 (比如先訪問了不在內存中的 100w，加載到內存中，再訪問剛剛被換到磁盤上的數據，又需要再加載一次)，需要進行和 PV 相同次數的磁盤 IO，災難! 最好的情況我們也需要 100w 次 磁盤 IO(比如先對在內存中的 100w 數據進行頻繁訪問，再對不在內存中的 100w 數據進行頻繁訪問)，在訪問頻率均勻的情況下，每秒需要進行大概 12 次 的磁盤 IO。

那我們把規劃給熱數據的內存大小調為 2G，看看會如何，這時候一天 200w 熱數據正好能裝下。那么最好的情況下，需要進行 100w 次磁盤 IO(比如 200w 數據中的 100w 老數據全都在昨天的熱數據中，則只需要對 100w 數據進行重新加載)，在訪問頻率均勻的情況下，每秒需 要進行大概 12 次的磁盤 IO。最壞的情況下，需要進行 200w 次磁盤 IO(比如今天訪問的 200w 條數據和昨天的熱數據沒有重合)，在訪問頻率均勻的情況 下，每秒需要進行大概 25 次的磁盤 IO。

MongoDB 數據庫容量規劃是什么

同理，我們再增大內存，會需要訪問的數據在內存中的機率增大，從而減小磁盤 IO 的頻率。

上面說的是一個簡單例子，具體你可以根據自己的數據訪問特性進行評估和計算，而且不僅要算平均 IO，更重要的是巔峰 IO。

同時不要忘了，MongoDB 還會定時調用 fsync 將內存中的臟頁 flush 到磁盤 (默認一分鐘一次)，你可以根據你自己臟數據的量或者比例來評估每次的 IO，然后你再考慮是否需要將 fsync 的頻率調低一點。

如果你還開啟了 journaling log，那這個 IO 量也需要加進去。

當然，接下來的就是你的磁盤是否能夠承受最終的 IO 量，然后你可以考慮你是否需要使用更快的硬盤，是否需要 RAID，是否需要換用 SSD 等等了。

索引量

索引和常訪問數據不同，索引要求全部放在內存中，所以索引的容量計算就相對容易很多。通過 MongoDB 的 db.stats() 命令就能看到你當前占用 的索引大小。比如上面的例子，現在 1 億條數據如果索引大小為 5G 的話，那么 2 億條的時候大概需要 10G。所以內存必須要裝下這 10G 索引。

系統開銷

MongoDB daemon 的開銷基本可以理解為一個常數，所以這里的系統開銷就主要是連接開銷。這取決于你的應用特點。比如你最大的并發操作為 100。也就是同時 100 個連接與 MongoDB 相連。每個連接一個線程開銷為系統的 stack size 設置，默認是 10M，那就是 1G(當然你可以適當調整這個值)。需要對數據進行實時排序的話，需要再算上排序時的內存開銷。

總結

當然，上面講的是一個簡單的預估方法，我們不期望能夠通過計算得出真實的容量估算結果，畢竟互聯網產品的變化總是那么不可控。但是在部署前按業務情況進行相關的容量預估是非常重要的。好的預估可以在金錢、性能和運維成本上得到一個相對平衡的結果。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。

向 AI 問一下細節