MongoDB 3.0 新特性【轉】

標籤：

本文來自：http://www.open-open.com/lib/view/open1427078982824.html#_label3

更多資訊見官網： http://docs.mongodb.org/manual/release-notes/3.0/

參考文章：

測試：http://www.mongoing.com/archives/862

        http://www.mongoing.com/benchmark_3_0

配置：http://www.mongoing.com/config_3_0

學習：http://www.mongoing.com/

遷移：https://github.com/xbsura/mongo-migrate

引言在曆經版本號碼修改（2.8版本直接跳到3.0版本）和11個rc版本之後，MongoDB 3.0於2015年3月3日正式發布。可以毫不誇張的說，該版本的新增特性標誌著MongoDB這款典型的NoSQL資料庫已經進入了一個全新的發展階段。本文以下內容會逐個盤點3.0版本的新增特性。外掛程式式儲存引擎API

MongoDB 3.0引入了外掛程式式儲存引擎API，為第三方的儲存引擎廠商加入MongoDB提供了方便，這一變化無疑參考了MySQL的設計理念。目前除了早期的MMAP儲存引擎外，WiredTiger和RocksDB均已完成了對MongoDB的支援，前者更是在被MongoDB公司收購後更是直接引入到了MongoDB 3.0版本中。外掛程式式儲存引擎API的引入為MongoDB豐富自己武器庫以處理更多不同類型的業務提供了無限可能，記憶體儲存引擎、事務儲存引擎甚至Hadoop在未來都有可能接入進來。

WiredTiger儲存引擎

如果說外掛程式式儲存引擎API為MongoDB 3.0打造了一個武器庫，那麼WiredTiger絕對是武器庫中第一枚也是最重要的一枚重磅炸彈。因為MMAP儲存引擎自身的天然缺陷（耗費磁碟空間和記憶體空間且難以清理，庫層級鎖），MongoDB為資料庫營運人員帶來了極大痛苦，甚至一部分人已經開始轉向TokuMX，儘管後者目前也不甚穩定。意識到這一問題的MongoDB，做出了有錢任性的決定，直接收購儲存引擎廠商WiredTiger，將WiredTiger儲存引擎整合進3.0版本（僅在64位版本中提供）。那麼這款走到聚光燈下的儲存引擎究竟具備哪些值得期待的特性呢？

1、文檔層級並發控制

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

MongoDB 2.4.12版本

$ /home/mongodb/mongodb-linux-x86_64-2.4.12/bin/mongostat –port 55060 
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn time 
*0 *0 *0 *0 0 1|0 0 18g 18.3g 16.1g 0 ycsb:0.0% 0 0|0 0|0 62b 2k 1 13:04:01 
*0 *0 *0 *0 0 1|0 0 18g 18.3g 16.1g 0 ycsb:0.0% 0 0|0 0|0 62b 2k 1 13:04:02 
*0 *0 *0 *0 0 1|0 0 18g 18.3g 16.1g 0 ycsb:0.0% 0 0|0 0|0 62b 2k 1 13:04:03 

MongoDB 3.0 rc8版本

$ /home/mongodb/mongodb-linux-x86_64-3.0.0-rc8/bin/mongostat –port 55050 
insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn time 
*0 *0 *0 *0 0 1|0 0.0 42.2 0 30.6G 30.4G 0|0 0|0 79b 16k 1 13:02:38 
*0 *0 *0 *0 0 1|0 0.0 42.2 0 30.6G 30.4G 0|0 0|0 79b 16k 1 13:02:39 
*0 *0 *0 *0 0 1|0 0.0 42.2 0 30.6G 30.4G 0|0 0|0 79b 16k 1 13:02:40 

2、磁碟資料壓縮

WiredTiger支援對所有集合和索引進行Block壓縮和首碼壓縮（如果資料庫啟用了journal，journal檔案一樣會壓縮），已支援的壓 縮選項包括：不壓縮、Snappy壓縮和Zlib壓縮。這為廣大Mongo使用者們帶來了又一福音，因為很多Mongo資料庫都是因為MMAP儲存引擎消 耗了過多的磁碟空間而不得已進行擴容。其中Snappy壓縮為資料庫的預設壓縮方式，使用者可以根據業務需求選擇適合的壓縮方式。理論上來說，Snappy 壓縮速度快，壓縮率OK，而Zlib壓縮率高，CPU消耗多且速度稍慢。當然，只要選擇使用壓縮，Mongo肯定會佔用更多的CPU使用率，但是考慮到 Mongo本身並不是十分耗CPU，所以啟用壓縮完全是值得的。

 

此外，WiredTiger儲存方式上也有很大改進。舊版本Mongo在資料庫層級分配檔案，資料庫中的所有集合和索引都混合儲存在資料庫檔案中，所以即 使刪掉了某個集合或者索引，佔用的磁碟空間也很難及時自動回收。WiredTiger在集合和索引層級分配檔案，資料庫中的所有集合和索引均儲存在單獨的 檔案中，集合或者索引刪除後，對應的隱藏檔隨即刪除。當然，因為儲存方式不同，低版本的資料庫無法直接升級到WiredTiger儲存引擎，只能通過導 出匯入資料的方式來實現。

MongoDB 2.4.12版本

[[email protected] mongodb_2_4_12]$ ll 
drwxrwxr-x 3 mongodb mongodb 4096 2月 25 19:03 local 
-rwxrwxr-x 1 mongodb mongodb 6 2月 25 19:04 mongod.lock 
drwxrwxr-x 2 mongodb mongodb 4096 2月 27 18:30 _tmp 
drwxrwxr-x 3 mongodb mongodb 4096 2月 27 18:39 ycsb 
[[email protected] mongodb_2_4_12]$ ll ycsb/ 
drwxrwxr-x 2 mongodb mongodb 4096 2月 27 18:39 _tmp 
-rw——- 1 mongodb mongodb 67108864 2月 27 18:57 ycsb.0 
-rw——- 1 mongodb mongodb 134217728 2月 27 18:57 ycsb.1 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.10 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.11 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.12 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:39 ycsb.13 
-rw——- 1 mongodb mongodb 268435456 2月 27 18:57 ycsb.2 
-rw——- 1 mongodb mongodb 536870912 2月 27 18:57 ycsb.3 
-rw——- 1 mongodb mongodb 1073741824 2月 27 18:57 ycsb.4 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.5 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.6 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.7 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.8 
-rw——- 1 mongodb mongodb 2146435072 2月 27 18:57 ycsb.9 
-rw——- 1 mongodb mongodb 16777216 2月 27 18:40 ycsb.ns 

Mongo 3.0 rc8版本

[[email protected] mongodb_3_0_0]$ ll 
drwxrwxr-x 2 mongodb mongodb 4096 2月 28 18:32 local 
-rw-rw-r– 1 mongodb mongodb 36864 3月 21 13:41 _mdb_catalog.wt 
-rwxrwxr-x 1 mongodb mongodb 6 2月 28 18:32 mongod.lock 
-rw-rw-r– 1 mongodb mongodb 36864 3月 21 13:42 sizeStorer.wt 
-rw-rw-r– 1 mongodb mongodb 95 2月 28 18:32 storage.bson 
-rw-rw-r– 1 mongodb mongodb 49 2月 28 18:32 WiredTiger 
-rw-rw-r– 1 mongodb mongodb 433 2月 28 18:32 WiredTiger.basecfg 
-rw-rw-r– 1 mongodb mongodb 21 2月 28 18:32 WiredTiger.lock 
-rw-rw-r– 1 mongodb mongodb 921 3月 21 13:41 WiredTiger.turtle 
-rw-rw-r– 1 mongodb mongodb 53248 3月 21 13:41 WiredTiger.wt 
drwxrwxr-x 2 mongodb mongodb 4096 3月 21 13:41 ycsb 
[[email protected] mongodb_3_0_0]$ ll ycsb/ 
-rw-rw-r– 1 mongodb mongodb 19314257920 2月 28 19:16 collection-4–1318477584648278106.wt 
-rw-rw-r– 1 mongodb mongodb 602112 3月 21 13:40 collection-6–1318477584648278106.wt 
-rw-rw-r– 1 mongodb mongodb 262598656 2月 28 18:53 index-5–1318477584648278106.wt 
-rw-rw-r– 1 mongodb mongodb 827392 3月 21 13:40 index-7–1318477584648278106.wt 
-rw-rw-r– 1 mongodb mongodb 1085440 3月 21 13:41 index-8–1318477584648278106.wt 

3、可配置記憶體使用量上限

WiredTiger支援記憶體使用量容量配置，使用者通過storage.wiredTiger.engineConfig.cacheSizeGB參數即可 控制MongoDB所能使用的最大記憶體，該參數預設值為實體記憶體大小的一半。這也為廣大Mongo使用者們帶來了又一福音，MMAP儲存引擎消耗記憶體是出 了名的，只要資料量夠大，簡直就是有多少用多少。

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標誌位，關閉空間預分配。

複製集改進

1、複製整合員增長

MongoDB 3.0的複製整合員的最大個數由之前的12個增長為50個，但能夠投票的最大成員個數依然為7個，而相應的getLastError中的 w: “majority” 項也僅代表投票節點的大多數。

2、Primary節點StepDown處理方式變化

在複製集中通過replSetStepDown命令可以使得當前的Primary節點退位，重新選舉新的Primay節點。MongoDB 3.0在StepDown的處理方式上做了如下修改：1）在Primary退位之前，會首先中斷某些耗時較長的使用者操作如建立索引、寫操作、 Mapreduce任務等；2）為了防止資料復原，Primary節點在退位之前會等待一個可被選舉的Secondary節點同步到最新資料，而舊版本中 Primary節點只要有Secondary節點的資料同步到10秒以內就退位；3）同時replSetStepDown命令新增了一個 secondaryCatchUpPeriodSecs參數，使用者可以指定Primary節點等待有Secondary節點的資料同步到該參數指定的秒數內就退位。

分區叢集改進

1、新增工具函數 sh.removeTagRange()

舊版本中只有sh.addTagRange()，如果要刪除tagRange只能手工到config.tags集合中刪除。

2、提供更可預測的Read Preference處理

新版本中mongos執行個體在執行讀操作時不再將串連固定在複製整合員上，而是對每個讀操作都會重新評估Read Preference。這樣當Read Preference修改時，其行為更容易預測。

3、為chunk遷移提供writeConcern設定

新版本針對均衡器為moveChunk和cleanupOrphaned這兩個涉及到chunk遷移的命令提供了writeConcern參數。

4、增加均衡器狀態顯示

新版本中通過sh.status()可以看到均衡器的狀態資訊。

其他改動

1、最佳化explan函數

新版本explain函數可以支援count，find，group，aggregate，update，remove等操作的查詢計劃顯示，結果更全面更精細。

2、重寫mongodb工具

新版本所有mongodb內建工具均使用Go語言重寫，特別是在mongodump和mongorestore添加了並行機制，這樣可以大大加快資料的匯出和匯入。

3、日誌輸出控制

新版本中將日誌分為不同的模組，其中包括ACCESS、COMMAND、CONTROL、GEO、INDEX、NETWORK、QUERY、REPL、 SHARDING、STORAGE、JOURNAL和WRITE等。使用者可以動態調整每個模組的記錄層級，這無疑更有利於系統問題診斷。

4、 索引構建最佳化

後台索引建立過程中，不能進行刪庫刪表刪索引操作，且後台索引建立過程不會因此自動中斷。另外，使用createIndexes命令可以同時建立多個索引，並且只掃描一遍資料，提升了建索引的效率。

總結

以上僅列出了MongoDB 3.0的一些主要特性和修改，如果希望瞭解更多可以查看MongoDB 3.0的Release-Notes。總體來看，MongoDB 3.0提供了較多令人驚喜的新特性，也使人們更加看好其未來的發展。

MongoDB 3.0 新特性【轉】