MongoDB空間分配

標籤：

Mongodb佔據的磁碟空間比MySQL大得多，可以理解文檔資料如Json這種格式，存在許多冗餘資料，但空間佔用大得不正常，甚至是傳統資料庫的三四倍，不太契合工程實踐，應該有改善的餘地。 查閱了一些資料，具體理下Mongodb的空間分配。

        1. MongoDB每個庫邏輯上包含許多集合（collection）,物理上儲存為多個資料檔案，資料檔案的分配是預先分配的， 預分配的方式可以減少片段 ，程式申請磁碟空間的時候更高效，但MongoDB預分配的策略可能導致空間的浪費。預設的分配空間的策略是：隨著資料庫資料的增加，MongoDB會不斷分配更多的資料檔案。每個新資料檔案的大小都是上一個已指派檔案的 兩倍( 64M, 128M, 256M, 512M, 1G, 2G, 2G, 2G )，直到預分配檔案大小的 上限2G。雖然2G的閥值可以調整，但一般營運等時候往往也不會去調整，就這點來說，可能導致空間的浪費。（可以這樣理解，原本一個collection大小為2M，增加了一個100K的資料後，現在該collection大小變為2M*2=4M,這種分配策略會浪費記憶體，但會避免產生片段） 對於磁碟的空間的分配效率，我報以懷疑的態度， 如果本身有IO瓶頸，預分配一個2G的檔案，將可能導致服務出現嚴重性能問題。預分配檔案，可以減少片段，提高程式申請空間的效率，但有無必要一次分配初始化一個巨大的檔案，這點值得商榷。 雖然預分配的機制，文檔記載是可以關閉的，但一般使用NOSQL產品都是會使用預設配置，也建議使用預設的配置，因預設配置往往經曆了長久的考驗，沒有那麼多bug。  

2. MongoDB的文檔在資料檔案中是連續儲存的，這點不同於一些關聯式資料庫的做法（它們會把長記錄拆分為兩部分，溢出的那部分單獨存放在另一處），如果沒有預留足夠的空間，那麼更新可能導致原有空間放不下新的文檔。當更新迫使引擎在BSON儲存中移動文檔時，儲存片段可以導致意外的延遲。對此MongoDB官方的解釋是如下，

“如果有足夠的空間，在MongoDB中更新文檔時，資料會在原地更新。如果更新後的文檔大小大於已經分配的空間，那麼文檔會在一個新位置被重寫。MongoDB最終會重用原來的空間，但這可能需要時間，而且空間可能會資源過度分派。

在MongoDB 2.6中，預設的空間分配策略將是powerOf2Sizes，這個選項從MongoDB 2.2開始就已經提供了。該設定會將MongoDB分配的空間大小向上取整為2的冪（比如，2、4、6、8、16、32、64等等）。該設定會降低需要移動文檔的幾率，並使空間可以更高效地重用，結果是更少的空間資源過度分派和更可預測的效能。使用者仍然可以使用精確匹配的分配策略，如果文檔大小不增加，該策略更節省空間的。”

顯然，這種策略又將導致空間的浪費，特別是對於匯入唯讀類型的資料。

3. MongoDB不支援資料檔案的壓縮，也不能回收空間。它所使用的磁碟重組的策略，可能是在一個新的地方重寫，而不是對舊的片段進行整理、合并。

4. 不校正資料頁。頁面校正對於資料庫是非常重要的，有助於識別存放裝置異常。就這點，MongoDB儲存的資料是不安全的，也許哪天就起不來了。

MongoDB空間分配