知識學習: Mongodb存儲特性[轉]


  • Lv 1

    一、存儲引擎(Storage)

    mongodb 3.0默認存儲引擎為MMAPV1,還有一個新引擎wiredTiger可選,或許可以提高一定的性能。

    mongodb中有多個databases,每個database可以創建多個collections,collection是底層數據分區(partition)的單位,每個collection都有多個底層的數據文件組成。(參見下文data files存儲原理)

    wiredTiger引擎:3.0新增引擎,官方宣稱在read、insert和複雜的update下具有更高的性能。所以後續版本,我們建議使用wiredTiger。所有的write請求都基於「文檔級別」的lock,因此多個客戶端可以同時更新一個colleciton中的不同文檔,這種更細顆粒度的lock,可以支撐更高的讀寫負載和並發量。因為對於production環境,更多的CPU可以有效提升wireTiger的性能,因為它是的IO是多線程的。wiredTiger不像MMAPV1引擎那樣儘可能的耗盡內存,它可以通過在配置文件中指定「cacheSizeGB」參數設定引擎使用的內存量,此內存用於緩存工作集數據(索引、namespace,未提交的write,query緩衝等)。journal就是一個預寫事務日誌,來確保數據的持久性,wiredTiger每隔60秒(默認)或者待寫入的數據達到2G時,mongodb將對journal文件提交一個checkpoint(檢測點,將內存中的數據變更flush到磁碟中的數據文件中,並做一個標記點,表示此前的數據表示已經持久存儲在了數據文件中,此後的數據變更存在於內存和journal日誌)。對於write操作,首先被持久寫入journal,然後在內存中保存變更數據,條件滿足後提交一個新的檢測點,即檢測點之前的數據只是在journal中持久存儲,但並沒有在mongodb的數據文件中持久化,延遲持久化可以提升磁碟效率,如果在提交checkpoint之前,mongodb異常退出,此後再次啟動可以根據journal日誌恢複數據。journal默認使用了snappy壓縮,檢測點創建後,此前的journal日誌即可清除。mongod可以禁用journal,這在一定程度上可以降低它帶來的開支;對於單點mongod,關閉journal可能會在異常關閉時丟失checkpoint之間的數據(那些尚未提交到磁碟數據文件的數據);對於replica set架構,持久性的保證稍高,但仍然不能保證絕對的安全(比如replica set中所有節點幾乎同時退出時)。MMAPv1引擎:mongodb原生的存儲引擎,比較簡單,直接使用系統級的內存映射文件機制(memory mapped files),一直是mongodb的默認存儲引擎,對於insert、read和in-place update(update不導致文檔的size變大)性能較高;不過MMAPV1在lock的並發級別上,支持到collection級別,所以對於同一個collection同時只能有一個write操作執行,這一點相對於wiredTiger而言,在write並發性上就稍弱一些。對於production環境而言,較大的內存可以使此引擎更加高效,有效減少「page fault」頻率,但是因為其並發級別的限制,多核CPU並不能使其受益。此引擎將不會使用到swap空間,但是對於wiredTiger而言需要一定的swap空間。(核心:對於大文件MAP操作,比較忌諱的就是在文件的中間修改數據,而且導致文件長度增長,這會涉及到索引引用的大面積調整)

    為了確保數據的安全性,mongodb將所有的變更操作寫入journal並間歇性的持久到磁碟上,對於實際數據文件將延遲寫入,和wiredTiger一樣journal也是用於數據恢復。所有的記錄在磁碟上連續存儲,當一個document尺寸變大時,mongodb需要重新分配一個新的記錄(舊的record標記刪除,新的記record在文件尾部重新分配空間),這意味著mongodb同時還需要更新此文檔的索引(指向新的record的offset),與in-place update相比,將消耗更多的時間和存儲開支。由此可見,如果你的mongodb的使用場景中有大量的這種update,那麼或許MMAPv1引擎並不太適合,同時也反映出如果document沒有索引,是無法保證document在read中的順序(即自然順序)。3.0之後,mongodb默認採用「Power of 2 Sized Allocations」,所以每個document對應的record將有實際數據和一些padding組成,這padding可以允許document的尺寸在update時適度的增長,以最小化重新分配record的可能性。此外重新分配空間,也會導致磁碟碎片(舊的record空間)。

    Power of 2 Sized Allocations:默認情況下,MMAPv1中空間分配使用此策略,每個document的size是2的次冪,比如32、64、128、256...2MB,如果文檔尺寸大於2MB,則空間為2MB的倍數(2M,4M,6M等)。這種策略有2種優勢,首先那些刪除或者update變大而產生的磁碟碎片空間(尺寸變大,意味著開闢新空間存儲此document,舊的空間被mark為deleted)可以被其他insert重用,再者padding可以允許文檔尺寸有限度的增長,而無需每次update變大都重新分配空間。此外,mongodb還提供了一個可選的「No padding Allocation」策略(即按照實際數據尺寸分配空間),如果你確信數據絕大多數情況下都是insert、in-place update,極少的delete,此策略將可以有效的節約磁碟空間,看起來數據更加緊湊,磁碟利用率也更高。

    本帖部分内容已隐藏,请登入并回覆,以查看隐藏内容!


  • 註冊用戶

    想看~快給我看~芝麻開門


登录后回复
 

与 萌阔论坛 的连接断开,我们正在尝试重连,请耐心等待