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存儲的數據是不安全的，也許哪天就起不來了。