[mongodb] MMAP 和wiredTiger 的比較

標籤：lib   儲存引擎   命令   返回   git   資料檔案   技術分享   磁碟   瓶頸   

　　mongodb 現在有兩款儲存引擎  MMAPv1 和 WireTiger,當然了除了這兩款儲存引擎還有其他的儲存引擎了。

如：

• 記憶體引擎：現在的mongodb 版本中已經有了，主要的cache 服務，它主要是做單元測試的。
• mongo-rocks:是一個key-value 的引擎被作為一個混合層為Facebook的RocksDB
• Fusion-io: 這個儲存引擎是被SanDisk建立，他是儘可能的繞過作業系統的檔案層直接寫到存放裝置。
• TokuMX:這個儲存系統被 Percona 建立，使用了分形樹索引代替了B-tree樹索引。
• /dev/null:這個儲存引擎把你所有寫的和讀的每一件事都返回空的結果，這聽起來是愚蠢的，但是在一些情況下是十分有用的，例如，在與資料庫無關的情況下，在你的應用程式中去找一些效能瓶頸的時候。

MMAPv1

　　MMAPv1之所以被命名，是因為Linux 中的命令mmap() 這個命令的意思是對應檔到虛擬記憶體並且允許對一些用例進行單個的最佳化，例如，當你有一個大的檔案，但是你不需要去讀整個檔案，你只需要讀取器中的一部分，mmap()是十分快的比一個read()，因為read() 是把整個檔案讀到記憶體中。

　　MMAP1有一個collection層級的鎖，但是沒有document 層級的鎖，這就造成不能同時有兩個進程對同一個collection 進行寫的操作。因此，針對同一個collection的寫操作，必須要等到前一個操作完成才能進行下一個寫的操作。MMAP這個collection 層級的鎖事必要的，因為MMAP的索引涉及多個document ，如果這些索引不能同時的被更新，那麼這些索引將是不穩定的。

WiredTiger

　　MMAP使用B-tree樹去儲存索引，WiredTiger也使用B-trees ，但是支援LSM樹image above was adapted from here)。

　　LSM 樹針對需要去有大量的隨機的插入的工作負載的，當你的資料比cahce的容量大並且背景維護經費在可以接受的範圍的的情況是有利的。

　　在WiredTiger引擎中，如果一個元素的document 需要被更新，一整個新的document將被全部寫到磁碟中，並且把這箇舊的document移除。

　　WiredTiger 提供了document-level-concurrency,這意味著兩個寫的操作將不影響相同的document,如果影響，一個操作將被返回重新執行。如果返回執行是十分少的那麼這個是一個非常不錯的效能最佳化。

　　還有一個WiredTiger特有的，提供了一個在檔案系統中壓縮資料和索引的功能，他支援快壓和zlib 兩種運算，預設情況下是有用快壓，和zlib相比他是用了少量的cpu但是它有低 的壓縮效率。

Benchmarks

　　當WiredTiger為mongodb服務的時候，他被公布在寫操作方面，效能將比之前快7-10 倍，並且壓縮了80%的檔案系統，這是一個大的改善，下面是多線程的輸送量

 

 Conclusion 

　　如果你的app是讀的權重大，使用MMAP，如果寫的大，使用WiredTiger。

　　一個有趣的問題是可以建立一個混合引擎的複製集。在複製集中，你可以給一個node配置WiredTiger去接受一個大量寫的資料負載，再用另外一個node 配置MMAP引擎去被一些讀資料的服務使用，複製集會自動主庫和其他庫之間的資料，她們基礎的儲存引擎是獨立的。

　　如果你的資料檔案使用MMAP引擎建立的，你將需要建立一個新的資料庫，如果你需要用一個WiredTirger node去運行,他不能開啟資料檔案，這倒轉過來是一樣的，雖然她們使用了不同的方法儲存資料，你不能重新使用相同的檔案，但是在複製集中，資料和主庫進行交換是沒有問題的

 

[mongodb] MMAP 和wiredTiger 的比較