MongoDB WiredTiger儲存引擎的優勢是什麼?

• MMAP v1 – 目前的基於記憶體對映的儲存引擎。MMAP v1在2.8支援collection level locking，並在2.8內繼續作為MongoDB的預設儲存引擎。
• WiredTiger – 這是一個BerkerlyDB 架構師們開發的一個儲存引擎。主要特點為高效能寫入，支援壓縮和文件級鎖。

MMAP儲存引擎自身的天然缺陷（耗費磁碟空間和記憶體空間且難以清理，庫級別鎖）。

1. 文件級別併發控制： WiredTiger透過MVCC實現文件級別的併發控制，即文件級別鎖。這就允許多個客戶端請求同時更新一個集合記憶體的多個文件，再也不需要在排隊等待 庫級別的寫鎖。這在提升資料庫讀寫效能的同時，大大提高了系統的併發處理能力。關於這一點的效果從監控工具mongostat就可以直接體現出來，舊版本 的監控指標會有locked db這一項（該項指標過高是mongo使用人員的一大痛點啊），而新版的mongostat已經看不到了。

2. 磁碟資料壓縮： WiredTiger支援對所有集合和索引進行Block壓縮和字首壓縮（如果資料庫啟用了journal，journal檔案一樣會壓縮），已支援的壓 縮選項包括：不壓縮、Snappy壓縮和Zlib壓縮。這為廣大Mongo使用者們帶來了又一福音，因為很多Mongo資料庫都是因為MMAP儲存引擎消 耗了過多的磁碟空間而不得已進行擴容。其中Snappy壓縮為資料庫的預設壓縮方式，使用者可以根據業務需求選擇適合的壓縮方式。理論上來說，Snappy 壓縮速度快，壓縮率OK，而Zlib壓縮率高，CPU消耗多且速度稍慢。當然，只要選擇使用壓縮，Mongo肯定會佔用更多的CPU使用率，但是考慮到 Mongo本身並不是十分耗CPU，所以啟用壓縮完全是值得的。 此外，WiredTiger儲存方式上也有很大改進。舊版本Mongo在資料庫級別分配檔案，資料庫中的所有集合和索引都混合儲存在資料庫檔案中，所以即 使刪掉了某個集合或者索引，佔用的磁碟空間也很難及時自動回收。WiredTiger在集合和索引級別分配檔案，資料庫中的所有集合和索引均儲存在單獨的 檔案中，集合或者索引刪除後，對應的儲存檔案隨即刪除。當然，因為儲存方式不同，低版本的資料庫無法直接升級到WiredTiger儲存引擎，只能透過導 出匯入資料的方式來實現。

MMAPv1儲存引擎提升

MongoDB 3.0出了引入WiredTiger外，對於原有的儲存引擎MMAP也進行了一定的完善，該儲存引擎依然是3.0版的預設儲存引擎。遺憾的是改進後的 MMAP儲存引擎依舊在資料庫級別分配檔案，資料庫中的所有集合和索引都混合儲存在資料庫檔案中，所以磁碟空間無法及時自動回收的問題如故。

1、鎖粒度由庫級別鎖提升為集合級別鎖

這在一定程度上也能夠提升資料庫的併發處理能力。

2、文件空間分配方式改變

在MMAP儲存引擎中，文件按照寫入順序排列儲存。如果文件更新後長度變長且原有儲存位置後面沒有足夠的空間放下增長部分的資料，那麼文件就要移動到檔案 中的其他位置。這種因更新導致的文件位置移動會嚴重降低寫效能，因為一旦文件發生移動，集合中的所有索引都要同步修改文件新的儲存位置。

MMAP儲存引擎為了減少這種情況的發生提供了兩種文件空間分配方式：基於paddingFactor（填充因子）的自適應分配方式和基於 usePowerOf2Sizes的預分配方式，其中前者為預設方式。第一種方式會基於每個集合中文件更新歷史計算文件更新的平均增長長度，然後在新文件 插入或舊文件移動時填充一部分空間，如當前集合paddingFactor的值為1.5，那麼一個大小為200位元組的文件插入時就會自動在文件後填充 100個位元組的空間。第二種方式則不考慮更新歷史，直接為文件分配2的N次方大小的儲存空間，如一個大小同樣為200位元組的文件插入時直接分配256個字 節的空間。

MongoDB 3.0版本中的MMAPv1拋棄了基於paddingFactor的自適應分配方式，因為這種方式看起來很智慧，但是因為一個集合中的文件的大小不一，所 以經過填充後的空間大小也不一樣。如果集合上的更新操作很多，那麼因為記錄移動後導致的空閒空間會因為大小不一而難以重用。目前基於 usePowerOf2Sizes的預分配方式成為預設的文件空間分配方式，這種分配方式因為分配和回收的空間大小都是2的N次方（當大小超過2MB時則 變為2MB的倍數增長），因此更容易維護和利用。如果某個集合上只有insert或者in-place update，那麼使用者可以透過為該集合設定noPadding標誌位，關閉空間預分配。