本次會議舉辦得非常用心，演講主題豐富，涵蓋了mongodb産品規劃、内部實作、使用者案例、devops、driver使用等很多内容，能滿足各種不同崗位聽衆的需求。我目前在阿裡雲資料庫團隊主要負責mongodb源碼方面的開發工作，是以重點會放在mongodb内部實作的部分，接下來跟大家分享下參會的一些重要内容及感悟。
預設的存儲引擎從mmapv1切換為wiredtiger，提升性能的同時也能通過壓縮降低存儲成本
複制集的選舉使用raft協定，可靠性進一步增強
支援文檔校驗功能（document validation）
支援left join（$lookup）
支援in memory存儲引擎（企業版），mongodb支援複制集各成員使用不同的存儲引擎，應用場景的想象空間很大
本次會議上介紹了下一個大版本3.4裡的主要特性
全量同步（initial sync）改進，目前如果initial sync中間斷開了，需要整個重來，改進後并行度提高，而且斷開後能夠接着上次的進度繼續同步。
<a href="#">支援自定義文檔排序規則（比如按ascii、utf8來排序）</a>
<a href="https://jira.mongodb.org/browse/server-142">隻讀視圖（readonly view）</a>
recursive lookup，目前隻支援簡單的left join
mongodb compass（企業版）在geo index、explain、crud操作上有很大的改進
bi connector功能提升（企業版）
總體看來，mongodb還是很注重社群回報的，像collation、隻讀視圖的功能都是社群vote比較多的特性；企業版本支援上，3.2裡隻有企業版支援的功能主要包括審計日志、資料加密、mongodb compass/ops manager、bi connector，in memory存儲引擎，大都是資料庫外圍的增值功能，放在商業版本裡很能了解，但in memory存儲引擎放到企業版我覺得很意外。
資料庫引擎是mongodb核心的組成部分，開發一個新的引擎很複雜的，而且引擎在各個場景下是否能表現得符合預期，不經過大量的使用驗證是很難穩定的，以wiredtiger為例，wiredtiger在作為mongodb存儲引擎之後，社群的各種使用案例遇到的問題也幫助wiredtiger改進了很多；希望官方能把in memory引擎放出來，讓社群一起來提升它，這樣mongodb就能适應于更多場景了，比如在緩存的場景代替redis...成為真正強大的newsql。
這個主題主要介紹mongodb 3.2異步網絡架構的改造，mongos跟mongod的通信，典型的流程是connect ==> auth ==> [send request ==> recv response] * n ==> close，在之前的版本裡整個過程是按順序同步進行的，總體效率很低。
在3.2裡實作了async network framework，采用狀态機轉換的模式實作異步通信。一個線程池負責做實際的工作，并處理狀态轉換。請求的狀态可分為『connect、auth、send、recv、close』等狀态，connect狀态會觸發線程執行connect動作，并在連接配接成功的回調函數裡将請求設定為auth狀态，然後auth觸發認證過程，成功後進入send狀态，依此類推...整個過程異步化。
目前這個網絡架構主要用于mongos與mongod、複制集mongod之間的通信，driver到mongodb之間還是connection per thread的模式，跟mongodb的工程師交流了下，這塊有改進計劃但不在3.4裡。
async network framework在設計實作時還考慮了代碼可讀性方面的問題，異步代碼是非常難讀的，各種回調很容易把人繞暈；mongodb在在實作時大量使用了c++ 11的lamda表達式，盡可能将異步的代碼寫得『同步化』，以提升代碼可讀性。
這個主題主要介紹了sharded cluster的config server從『多個獨立mongod節點』演變為『複制集』後的一些設計考慮。
但光靠majority還不夠，讀到的資料可能不是最新的，比如3節點複制集，primary上成功更新了資訊，比如chunk遷移後更新路由資訊，但2個secondary還未同步，通過majority級别的read concern讀取時，仍然可能讀到未更新的路由資訊。為了解決這個問題，在readconcern裡加了一個afteroptime的選項，指定讀取的資料一定在某個時間戳以後，以確定讀到最新的資料。
本次大會有好幾個分享mongodb内部測試相關的主題，我聽了3個分享，分别講mongodb的持續內建測試、當機測試、性能測試，感覺mongodb在測試上的确做得很好，非常值得學習，總的來說就是将所有的測試『自動化』。
mongodb通過evergreen來實作自動化的持續內建測試，其自動追蹤代碼commit，并根據配置（哪個子產品、哪個os平台、哪些測試case）來執行測試，測試通過後，将代碼送出到内部的代碼倉庫。絕大部分的測試工作都是在aws機器上完成的，而且ervegreen還能彈性的控制測試需要的aws的機器資源，以盡量降低成本。
性能測試（這裡說的性能測試并不是說單純測mongodb的服務能力，目的是要發現mongodb可能存在的性能問題，并進行優化），性能測試的基礎還是『測試自動化』，多種workload持續測試，當發現性能問題後（有的問題可能要跑很久才會出現），就做case study，分析原因以及如何讓問題重制，然後改進代碼，重新測試...直到問題解決。
wiredtiger cache的配置是個老大難的問題，社群裡最近很多使用者遇到持續insert場景下，cache滿了之後，cache evict導緻請求響應很慢，通過設定小的cache size可以緩解這個問題，是以wiredtiger的cache并不是越大越好。
wiredtiger的cache裡存儲解壓縮後的資料，通路時如果wt cache命中，則直接讀取資料；如果cache不命中，則會在os page cache查找，再不命中則從磁盤讀取。如果wt沒有開啟壓縮、加密，則資料不會存儲到wt cache裡，相當于關閉了cache（這一點未實際驗證過）。
對于wt cache的配置，沒有明确的規則，建議如果讀多寫少，可以配置較大的cache size；如果寫多讀少，則配置較小的cache size。
國外技術會議參會平均年齡遠大于國内，現場見到不少白頭發的老頭
mongodb專門為會議開發了一個app，每個參會者會發一個小的智能裝置，互相碰一下，app上就會自動加好友，app的資料就存儲在mongodb，這是對技術最好的诠釋。
會議除了技術分享，會議第一天晚上安排了一個after party的活動，把參會的人拉到酒吧，聽歌吃東西；第二天早上還有一個跟cto一起晨跑的活動（老美的身體都太棒了，跑了幾分鐘就被甩得跟不上了，經常鍛煉太重要了），會議結束後大家一塊在會場喝啤酒、吃點心聊天。整個會議感覺很棒，學到了也玩到了。
foursquare是目前我了解到使用mongodb規模最大的公司，部署節點700+，大量使用shareded cluster，mongodb大有可為
百度、東航分享了使用mongodb的經驗，關注度很高，尤其百度的同學分享後很多聽衆提問
mongodb的slogan是for giant ideas，本次會議也有2場keynote的分享跟技術及mongodb無關，而是分享一些『很有創意的想法及實踐』。