摘要：?上周和 @葉翔 一起參加了在 紐約舉行的MongoDB World 2016，MongoDB作為一個NewSQL數(shù)據(jù)庫越來越受關(guān)注，這一點從google趨勢、百度指數(shù)都可以看出來。 本次會議舉辦得非常用心，演講主題豐富，涵蓋了MongoDB產(chǎn)品規(guī)劃、內(nèi)部實現(xiàn)、 用戶案例、devops、

上周和 @葉翔 一起參加了在 紐約舉行的MongoDB World 2016，MongoDB作為一個NewSQL數(shù)據(jù)庫越來越受關(guān)注，這一點從google趨勢、百度指數(shù)都可以看出來。

本次會議舉辦得非常用心，演講主題豐富，涵蓋了MongoDB產(chǎn)品規(guī)劃、內(nèi)部實現(xiàn)、用戶案例、devops、driver使用等很多內(nèi)容，能滿足各種不同崗位聽眾的需求。我目前在阿里云數(shù)據(jù)庫團隊主要負責MongoDB源碼方面的開發(fā)工作，所以重點會放在MongoDB內(nèi)部實現(xiàn)的部分，接下來跟大家分享下參會的一些重要內(nèi)容及感悟。

MongoDB 3.4 preview

MongoDB的版本迭代非常快，我接觸MongoDB還不到一年的時間，已經(jīng)經(jīng)歷了MongoDB 3.0、3.2兩個大版本，云數(shù)據(jù)庫為了跟官方保持同步，已經(jīng)使用了最新的3.2版本。大版本的發(fā)布，新功能改進上還是非常給力的，比如3.2相比3.0版本，重大的改進包括：

• 默認的存儲引擎從mmapv1切換為wiredtiger，提升性能的同時也能通過壓縮降低存儲成本
• 復制集的選舉使用raft協(xié)議，可靠性進一步增強
• 支持文檔校驗功能（document validation）
• 支持left join（$lookup）
• 支持in memory存儲引擎（企業(yè)版），MongoDB支持復制集各成員使用不同的存儲引擎，應用場景的想象空間很大

本次會議上介紹了下一個大版本3.4里的主要特性

• 全量同步（initial sync）改進，目前如果initial sync中間斷開了，需要整個重來，改進后并行度提高，而且斷開后能夠接著上次的進度繼續(xù)同步。
• 支持自定義文檔排序規(guī)則（比如按ascii、utf8來排序）
• 只讀視圖（readonly view）
• recursive lookup，目前只支持簡單的left join
• mongodb compass（企業(yè)版）在geo index、explain、crud操作上有很大的改進
• bi connector功能提升（企業(yè)版）

總體看來，MongoDB還是很注重社區(qū)反饋的，像collation、只讀視圖的功能都是社區(qū)vote比較多的特性；企業(yè)版本支持上，3.2里只有企業(yè)版支持的功能主要包括審計日志、數(shù)據(jù)加密、mongodb compass/ops manager、bi connector，in memory存儲引擎，大都是數(shù)據(jù)庫外圍的增值功能，放在商業(yè)版本里很能理解，但in memory存儲引擎放到企業(yè)版我覺得很意外。

數(shù)據(jù)庫引擎是MongoDB核心的組成部分，開發(fā)一個新的引擎很復雜的，而且引擎在各個場景下是否能表現(xiàn)得符合預期，不經(jīng)過大量的使用驗證是很難穩(wěn)定的，以wiredtiger為例，wiredtiger在作為mongodb存儲引擎之后，社區(qū)的各種使用案例遇到的問題也幫助wiredtiger改進了很多；希望官方能把in memory引擎放出來，讓社區(qū)一起來提升它，這樣MongoDB就能適應于更多場景了，比如在緩存的場景代替redis...成為真正強大的NewSQL。

MongoDB Atlas

本次大會最重量級的內(nèi)容就是MongoDB Atlas Cloud Service的發(fā)布，MongoDB公司正式提供Database-as-a-service服務模式，用戶可以選擇在AWS（后續(xù)可能支持azure，gcp）上部署MongoDB云服務，模式跟現(xiàn)在的mlab類似。

Async network framework

這個主題主要介紹MongoDB 3.2異步網(wǎng)絡框架的改造，Mongos跟Mongod的通信，典型的流程是connect ==> auth ==> [send request ==> recv response] * N ==> close，在之前的版本里整個過程是按順序同步進行的，總體效率很低。

在3.2里實現(xiàn)了Async network framework，采用狀態(tài)機轉(zhuǎn)換的模式實現(xiàn)異步通信。一個線程池負責做實際的工作，并處理狀態(tài)轉(zhuǎn)換。請求的狀態(tài)可分為『connect、auth、send、recv、close』等狀態(tài)，connect狀態(tài)會觸發(fā)線程執(zhí)行connect動作，并在連接成功的回調(diào)函數(shù)里將請求設置為auth狀態(tài)，然后auth觸發(fā)認證過程，成功后進入send狀態(tài)，依此類推...整個過程異步化。

目前這個網(wǎng)絡框架主要用于mongos與mongod、復制集mongod之間的通信，driver到MongoDB之間還是connection per thread的模式，跟MongoDB的工程師交流了下，這塊有改進計劃但不在3.4里。

Async network framework在設計實現(xiàn)時還考慮了代碼可讀性方面的問題，異步代碼是非常難讀的，各種回調(diào)很容易把人繞暈；MongoDB在在實現(xiàn)時大量使用了C++ 11的lamda表達式，盡可能將異步的代碼寫得『同步化』，以提升代碼可讀性。

Raft Protocol in MongoDB

從3.2版本起，MongoDB使用raft協(xié)議來保證一致性，這個主題思遠同學在之前中文社區(qū)的Webinar也分享過，有興趣的同學直接去看中文的PPT及視頻，不做過多介紹。

Sharded cluster

這個主題主要介紹了Sharded cluster的config server從『多個獨立mongod節(jié)點』演變?yōu)椤簭椭萍缓蟮囊恍┰O計考慮。

config server改為復制集模式后，復制集的備節(jié)點同步可能存在延時，而且primary節(jié)點還可能出現(xiàn)回滾（rollback）的情況，為了讓所有mongos看到一樣的視圖，一致性的問題得重新考慮，3.2版本里引入了Read Concern的功能來解決這個問題。

mongos向config server寫入時，使用默認的write concern，但讀取時使用read concern majority級別，確保讀取的數(shù)據(jù)已經(jīng)成功寫入大多數(shù)節(jié)點，這樣就不會讀到可能會回滾的數(shù)據(jù)了；

但光靠majority還不夠，讀到的數(shù)據(jù)可能不是最新的，比如3節(jié)點復制集，primary上成功更新了信息，比如chunk遷移后更新路由信息，但2個secondary還未同步，通過majority級別的read concern讀取時，仍然可能讀到未更新的路由信息。為了解決這個問題，在readConcern里加了一個afterOpTime的選項，指定讀取的數(shù)據(jù)一定在某個時間戳以后，以確保讀到最新的數(shù)據(jù)。

Testing Infrastructure

本次大會有好幾個分享MongoDB內(nèi)部測試相關(guān)的主題，我聽了3個分享，分別講MongoDB的持續(xù)集成測試、宕機測試、性能測試，感覺MongoDB在測試上的確做得很好，非常值得學習，總的來說就是將所有的測試『自動化』。

MongoDB使用evergreen(evergreen目前也是開源的）做持續(xù)繼承測試，因為MongoDB實現(xiàn)上包含很多模塊如replication、sharding、index等，再加上MongoDB是能在linux、windows、solaris等多個平臺上運行的，測試是相當難做的。

MongoDB通過evergreen來實現(xiàn)自動化的持續(xù)集成測試，其自動追蹤代碼commit，并根據(jù)配置（哪個模塊、哪個OS平臺、哪些測試case）來執(zhí)行測試，測試通過后，將代碼提交到內(nèi)部的代碼倉庫。絕大部分的測試工作都是在AWS機器上完成的，而且ervegreen還能彈性的控制測試需要的AWS的機器資源，以盡量降低成本。

為了保證MongoDB在異常情況下的數(shù)據(jù)可靠性，需要針對MongoDB運行的不同環(huán)境（虛擬機 or 物理機）進行斷電測試，他們使用一種可編程插座來實現(xiàn)通過ssh的方式來自動啟停服務器，以模擬斷電測試環(huán)境。

性能測試（這里說的性能測試并不是說單純測MongoDB的服務能力，目的是要發(fā)現(xiàn)MongoDB可能存在的性能問題，并進行優(yōu)化），性能測試的基礎還是『測試自動化』，多種workload持續(xù)測試，當發(fā)現(xiàn)性能問題后（有的問題可能要跑很久才會出現(xiàn)），就做case study，分析原因以及如何讓問題重現(xiàn)，然后改進代碼，重新測試...直到問題解決。

Wiretiger cache調(diào)優(yōu)

wiredtiger cache的配置是個老大難的問題，社區(qū)里最近很多用戶遇到持續(xù)insert場景下，cache滿了之后，cache evict導致請求響應很慢，通過設置小的cache size可以緩解這個問題，所以wiredtiger的cache并不是越大越好。

wiredtiger的cache里存儲解壓縮后的數(shù)據(jù)，訪問時如果WT cache命中，則直接讀取數(shù)據(jù)；如果cache不命中，則會在OS page cache查找，再不命中則從磁盤讀取。如果WT沒有開啟壓縮、加密，則數(shù)據(jù)不會存儲到WT cache里，相當于關(guān)閉了cache（這一點未實際驗證過）。

對于WT cache的配置，沒有明確的規(guī)則，建議如果讀多寫少，可以配置較大的cache size；如果寫多讀少，則配置較小的cache size。

存儲引擎API及mongorocks

MongoDB 3.2已經(jīng)支持wiredtiger、mmapv1、in-memory存儲引擎，其他的一些存儲引擎比如rocksdb、terakdb也對MongoDB做了適配，但沒有被合到官方代碼里。

MongoDB存儲引擎適配工作量還是很大的，需要實現(xiàn)的接口挺多，還需要考慮各種可能的優(yōu)化，比如wiredtiger引擎針對oplog采用特殊的刪除策略來提升性能。希望存儲引擎API的抽象能做得越來越好，適配起來更簡單，這樣才能讓更多的引擎加入進來，讓用戶能有更多的選擇。

SQL Proxy （BI Connector）

MongoDB 3.2企業(yè)版里支持bi connector來適配了多種bi分析工具如tableau等，通常這些工具都是直接使用SQL來進行數(shù)據(jù)分析，MongoDB開發(fā)了SQL proxy用于實現(xiàn)從sql到MongoDB的查詢語言MQL的轉(zhuǎn)換。

SQL里大部分操作都在MongoDB里都能找到對應操作符，重點需要解決數(shù)組字段的查詢、MongoDB在實現(xiàn)SQL PROXY時，把數(shù)組的多個元素當做多個文檔來看待（類似與$unwind操作符的工作），目前也有類似的項目做SQL到MQL的轉(zhuǎn)換，如querymongo。

其他

• 國外技術(shù)會議參會平均年齡遠大于國內(nèi)，現(xiàn)場見到不少白頭發(fā)的老頭
• MongoDB專門為會議開發(fā)了一個app，每個參會者會發(fā)一個小的智能設備，相互碰一下，app上就會自動加好友，app的數(shù)據(jù)就存儲在MongoDB，這是對技術(shù)最好的詮釋。
• 會議除了技術(shù)分享，會議第一天晚上安排了一個after party的活動，把參會的人拉到酒吧，聽歌吃東西；第二天早上還有一個跟CTO一起晨跑的活動（老美的身體都太棒了，跑了幾分鐘就被甩得跟不上了，經(jīng)常鍛煉太重要了），會議結(jié)束后大家一塊在會場喝啤酒、吃點心聊天。整個會議感覺很棒，學到了也玩到了。
• foursquare是目前我了解到使用MongoDB規(guī)模最大的公司，部署節(jié)點700+，大量使用shareded cluster，MongoDB大有可為
• 百度、東航分享了使用MongoDB的經(jīng)驗，關(guān)注度很高，尤其百度的同學分享后很多聽眾提問
• MongoDB的slogan是FOR GIANT IDEAS，本次會議也有2場keynote的分享跟技術(shù)及MongoDB無關(guān)，而是分享一些『很有創(chuàng)意的想法及實踐』。

阿里云數(shù)據(jù)庫團隊常年招工，歡迎加入，和我們一起實現(xiàn)Giant Ideas！

掃我，和云棲在線交流

【云棲快訊】首屆阿里巴巴在線技術(shù)峰會，將于7月19日-21日20:00-21:30在線舉辦。峰會邀請到阿里集團9位技術(shù)大V，分享電商架構(gòu)、安全、數(shù)據(jù)處理、數(shù)據(jù)庫、多應用部署、互動技術(shù)、Docker持續(xù)交付與微服務等一線實戰(zhàn)經(jīng)驗，解讀最新技術(shù)在阿里集團的應用實踐。??詳情請點擊

總結(jié)

以上是生活随笔為你收集整理的MongoDB World 2016参会全记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。