MongoDB數據庫容量規劃是指什么

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

　　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(當然你可以適當調整這個值)。需要對數據進行實時排序的話，需要再算上排序時的內存開銷。

　　總結

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

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