MongoDB的存儲結(jié)構(gòu)及對空間使用率的影響是怎樣的，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。
專注于為中小企業(yè)提供成都網(wǎng)站制作、做網(wǎng)站服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)翠屏免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了1000多家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
使用MongoDB一段時間的同學(xué)肯定會發(fā)現(xiàn)，MongoDB往往會占用比實際數(shù)據(jù)大小多不少空間的問題。如果利用db.stats()命令去查看，會發(fā)現(xiàn)MongoDB會報告幾種不同的空間大小信息，如dataSize, storageSize以及fileSize。這些大小到底指的是什么意思呢？讓我們來通過了解MongoDB的存儲機制來解析這幾個數(shù)值的含義。
MongoDB的數(shù)據(jù)庫文件主要有3種：
journal 日志文件
namespace 表名文件
data 數(shù)據(jù)及索引文件
日志文件
跟一些傳統(tǒng)數(shù)據(jù)庫不同，MongoDB的日志文件只是用來在系統(tǒng)出現(xiàn)宕機時候恢復(fù)尚未來得及同步到硬盤的內(nèi)存數(shù)據(jù)。日志文件會存放在一個分開的目錄下面。啟動時候MongoDB會自動預(yù)先創(chuàng)建3個每個為1G的日志文件（初始為空）。除非你真的有持續(xù)海量數(shù)據(jù)并發(fā)寫入，一般來說3個G已經(jīng)足夠。
命名文件 dbname.ns
這個文件用來存儲整個數(shù)據(jù)庫的集合以及索引的名字。這個文件不大，默認(rèn)16M，可以存儲24000個集合或者索引名以及那些集合和索引在數(shù)據(jù)文件中得具體位置。通過這個文件MongoDB可以知道從哪里去開始尋找或插入集合的數(shù)據(jù)或者索引數(shù)據(jù)。這個值可以通過參數(shù)調(diào)整至2G。
數(shù)據(jù)文件 dbname.0, dbname.1,… dbname.n
MongoDB的數(shù)據(jù)以及索引都存放在一個或者多個MongoDB數(shù)據(jù)文件里。第一個數(shù)據(jù)文件會以“數(shù)據(jù)庫名.0”命名，如 my-db.0。這個文件默認(rèn)大小是64M，在接近用完這個64M之前，MongoDB 會提前生成下一個數(shù)據(jù)文件如my-db.1。數(shù)據(jù)文件的大小會2倍遞增。第二個數(shù)據(jù)文件的大小為128M，第三個為256M。一直到了2G以后就會停止，一直按這個2G這個大小增加新的文件。
當(dāng)然MongoDB還會生成一些臨時文件如 _tmp 和 mongod.lock等， 不過他們跟我們的討論都沒有太大相關(guān)性。
Extent
在每一個數(shù)據(jù)文件內(nèi)，MongoDB把所存儲的BSON文檔的數(shù)據(jù)和B樹索引組織到邏輯容器“Extent”里面。如下圖所示（my-db.1和my-db.2 是數(shù)據(jù)庫的兩個數(shù)據(jù)文件）：
一個文件可以有多個Extent
每一個Extent只會包含一個集合的數(shù)據(jù)或者索引
同一個集合的數(shù)據(jù)或索引可以分布在多個Extent內(nèi)。這幾個Extent也可以分步于多個文件內(nèi)
同一個Extent不會又有數(shù)據(jù)又有索引
Record 記錄
在每個Extent里面存放有多個”Record“, 每一個記錄里包含一個記錄頭以及MongoDB的BSON文檔，以及一些額外的padding空間。Padding是MongoDB在插入記錄時額外分配一些未用空間，這樣將來文檔變大的時候不至于需要把文檔遷移到別處。記錄頭以整個記錄的大小開始，包括該記錄自己的位置以及前一個記錄和后一個記錄的位置?？梢韵胂蟪梢粋€Double Linked List。
在之前的基礎(chǔ)上，我們可以來理解一下db.stats()里面關(guān)于空間大小參數(shù)的含義。
dataSize
dataSize是最接近真實數(shù)據(jù)大小的一個參數(shù)。你可以用來檢查你的數(shù)據(jù)有多少。這個大小包括了數(shù)據(jù)庫（或者集合）的每條記錄的總和。注意每條記錄除了BSON文檔外還有header及padding這些額外開銷。所以實際大小會比真正數(shù)據(jù)所占空間會稍大。
當(dāng)刪除文檔的時候，這個參數(shù)會相應(yīng)變小因為它是所有文檔數(shù)的大小總和。如果你的文檔沒有刪除，只是文檔內(nèi)部的字段被刪除或縮小，則不會對dataSize 有影響。原因就是因為文檔所在記錄還在，并且整條記錄所占空間并無改動，只不過記錄內(nèi)的未用空間變多了而已。
storageSize
這個參數(shù)等于數(shù)據(jù)庫或者某個集合所有用到的Data Extents的總和。注意這個數(shù)字會大于dataSize因為Extent里面會有一些刪除文檔之后留下來的碎片（deleted）。及時你的storageSize大出dataSize很多，這個也不一定就是很糟糕的情況。如果有新插入的文檔小于或等于碎片的大小，MongoDB會重新利用這個碎片來存儲新的文檔。不過在這之前這些碎片將一直會被保留在那里占用空間。由于這個原因，你刪除文檔的時候這個參數(shù)不會變小。
碎片問題會因為運行的時間變長而變得嚴(yán)重。你可以通過 compact 命令來進行碎片清理或者通過新架一臺從機復(fù)制所有數(shù)據(jù)，然后變成主節(jié)點的方式來解決這些碎片。
fileSize
這個參數(shù)只在數(shù)據(jù)庫上有效，指的是實際文件系統(tǒng)中用到的文件的大小。它包括所有的數(shù)據(jù)Extents的總和，索引Extent的總和，以及一些未被分配的空間。之前提到MongoDB會對數(shù)據(jù)庫文件創(chuàng)建時候進行預(yù)分配，例如最小就是64M，哪怕你只有幾百個KB的數(shù)據(jù)。所以這個參數(shù)可能會比實際的數(shù)據(jù)大小會大不少。這些額外未用空間是用來保證MongoDB可以在新的數(shù)據(jù)寫入時候快速的分配新的Extent，避免引起磁盤空間分配引起的延遲。
值得注意的是，當(dāng)你刪除文檔，或甚至集合和索引，這個參數(shù)不會變小。換句話說，數(shù)據(jù)庫所使用的硬盤空間只會上升（或者不變），而不會因為刪除數(shù)據(jù)而變小。當(dāng)然需要知道的是這并不就意味著浪費，只是說有很多預(yù)留空間而已。
看完上述內(nèi)容，你們掌握MongoDB的存儲結(jié)構(gòu)及對空間使用率的影響是怎樣的的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！
重慶分公司
重慶分公司
