MongoDB的空間分配
寫篇文章時,2.8版本還沒有出。
據我的生產實踐,Mongodb佔據的磁碟空間比MySQL大得多,可以理解文檔數據如Json這種格式,存在許多冗餘數據,但空間佔用大得不正常,甚至是傳統資料庫的三四倍,不太契合工程實踐,應該有改善的餘地。 查閱了一些資料,具體理下Mongodb的空間分配。
1. MongoDB每個庫邏輯上包含許多集合(collection),物理上存儲為多個數據文件,數據文件的分配是預先分配的,預分配的方式可以減少碎片,程序申請磁碟空間的時候更高效,但MongoDB預分配的策略可能導致空間的浪費。默認的分配空間的策略是:隨著資料庫數據的增加,MongoDB會不斷分配更多的數據文件。每個新數據文件的大小都是上一個已分配文件的兩倍( 64M, 128M, 256M, 512M, 1G, 2G, 2G, 2G ),直到預分配文件大小的上限2G。雖然2G的閥值可以調整,但一般運維等時候往往也不會去調整,就這點來說,可能導致空間的浪費。
對於磁碟的空間的分配效率,我報以懷疑的態度,如果本身有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存儲的數據是不安全的,也許哪天就起不來了。
推薦閱讀:
※誰殺死了 MySQL? - 後記
※使用外鍵約束還是還是自己來寫代碼做約束?
※Mysql佔用CPU過高如何優化?
※【我的DBA好友系列】之隔壁老王在練腰
※【阿里雲大學課程】MySQL大牛丁奇:分散式資料庫技術與實現
TAG:MySQL |