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的冪（好比，二、四、六、八、1六、3二、64等等）。該設置會下降須要移動文檔的概率，並使空間能夠更高效地重用，結果是更少的空間過分分配和更可預測的性能。用戶仍然可使用精確匹配的分配策略，若是文檔大小不增長，該策略更節省空間。」

顯然，這種策略又將致使空間的浪費，特別是對於導入只讀類型的數據。

3. MongoDB不支持數據文件的壓縮，也不能回收空間。它所使用的碎片整理的策略，多是在一個新的地方重寫，而不是對舊的碎片進行整理、合併。

4. 不校驗數據頁。頁面校驗對於數據庫是很是重要的，有助於識別存儲設備異常。就這點，MongoDB存儲的數據是不安全的，也許哪天就起不來了。