MongoDB 3.2 預計在2015年底在 MongoDB World 里向大家介紹，我們認為這有益于帶來一些很有吸引力的特征。大多數的這些功能仍然在發展，盡管它們被展示出來，有可能真正等到 MongoDB 3.2 公布時，這些特征也許將會發生改變。

模式?

會議上有很多關于模式的討論。一個“無模式”的數據庫，如 MongoDB 的一個提升，這看起來很奇怪，但它似乎 MongoDB，公司已重新發現規則的結構存儲在數據庫中的文檔可以幫助管理一個數據庫的演變。

這實際上涉及到的是一個新的，MongoDB 的企業工具支付，掃描集合和逆向工程師從集合模式中的搜索。它也提供了關于在 MongoDB3.2 使用的新熱性，來使收集更有用、更正常，這些特性就是……

校驗

MongoDB 開源版本的諸多新特性之一是可以給文檔的字段加校驗。 這個特點， SERVER-18227， 使得集合可以擁有一個校驗器來作為集合元數據的一部分。校驗器是一個匹配表達式，會在文檔插入或修改時驗證匹配結果為 true。 如果校驗不通過，修改將會被拒絕并返回一個錯誤 121,  DocumentValidationFailure.

但是也有些限制。首先，校驗器必須是非常簡單的匹配表達式；大于、 小于或是否存在等。不可以用地理位置的附近，不可以用文本查找也不能用where表達式。

你可以在創建表（譯者注:我想應該是集合）的時候設置校驗器，只需要加一個 validator 的設置項，或者也可通過 collmod 命令，如下：

db.runCommand({"collMod": collName,  
               "validator" : {a: {$exists: true}}})

這個例子校驗了字段"a"是否存在。如果你想修改校驗器，但是注意到并沒有獲取元數據函數，因此需要獲取集合的統計信息（stats），這個里面有現有的校驗器。然后就能用"collMod"來修改跟重新設置了。

關于校驗器，還有些需要記住的。首先，他們只在添加跟修改操作時生效，言下之意是對于集合中的現存數據，校驗器是不校驗的...直到你更新一個已經存在的文檔，校驗器就會起作用了，除非文檔沒做更改。因此如果你想啟動校驗，你可能需要先把現有集合掃描一遍，確認所有文檔符合或者對所有添加/修改操作添加失敗快照。你可以把 BypassDocumentValidation 權限給你的用戶，讓他們設置bypassDocumentationValidation 標志，但是這可能與校驗的初衷有所沖突。順帶一提，這些權限跟標識主要是為一些運維操作設計的，比如恢復一個 partially conforming collection 。

局部索引

與模式相關的另一個服務器端的功能就是”局部索引“，這個功能自2010開始就在 MongoDB 的 JIRA 里時不時的被提到。對這一功能最好的解釋就是通過實例來說明。假設你手頭有你曾經接觸過的所有客戶，包括活躍的和非活躍的。在日常的使用中，你想在查詢活躍客戶時獲得很好的性能。要達到很好性能的一種方式是分為兩個數據集（即表）來處理，一個數據集是活躍客戶，它具有索引，另一數據集是非活躍客戶，沒有索引，不過，這就要求對應用進行更改，確保客戶存儲在它應該存儲的那一數據集里。另外，你可以使用局部索引，局部索引只對哪些滿足過濾器表達式的文檔進行索引。如下：

myusercoll.createIndex({ name: 1 },  
        { partialFilterExpression: { status: { $eq: "active" } })

此時，對非常大型的表的處理性能會得到巨大的提升。這種情況下，如果文檔與過濾器不匹配，那么，不但在查詢時跳過了這些文檔，而且在插入或者更新時也不會對這些文檔添加索引。不過性能提升的程度則完全取決于需要進行索引處理字段的結構和密度。

Lookup!

有個不爭的事實是 MongoDB 不具備任何形式的表連接。其實大部分情況，你不需要表連接，但是當你需要將數據組合并分析，這個時候你可能想要個連接功能。MongoDB 公司關于這點的意見是，稍稍將你的數據非正規化一下，將不同集合的數據復制到那個你準備分析的集合中，并保持同步，起碼每天同步一次，但是談到分析，你總不能啥數據都到處復制。

MongoDB 的核心分析工具是 aggregation，通過這個，你能創建一個任務管道（pipeline），對選中的文檔施加各種操作，最后得到需要的數據。當你要聚合訂單表時，首先在 pipeline 中添加個運算符，來匹配特定的幾類產品的訂單，然后用另一個運算符分組計算每類產品的銷量。問題是 pipeline 只能對一個集合中的文檔進行操作，因此，如果還需要操作另一個集合的時候，就玩不轉了。MongoDB 3.2添加了一個 $lookup 操作符 用以引入其它集合的數據。

$lookup 操作符有一個 from 參數，用來指定你想從哪個集合拖數據。還有一個 on 參數用來指定另一個集合中的哪個字段跟 pipeline 中的哪個字段應該匹配。最后當匹配到一個文檔，該文檔會被插入管道中的文檔，通過 as 參數設定一個 key 把該文檔就放到這個 key 中。這個方式看上去有點暴力， 使文檔變得很大， 別擔心，其它的聚合操作符會把數據切小的。

$lookup 在聚合管道中有巨大的潛力，可以使用戶不需要刻意將數據非正規化。不過我們要等到 alpha/beta 發布才能知道 $lookup 在實踐中到底有多有效。

總結 

這是第一次評判數據庫級別的操作，我們應該把期待放在 MongoDB 3.2 上。所有三個特性在這里的痛點是 MongoDB 的架構內的服務器。在 MongoDB 3.2 alpha /beta 版本釋放時，我們將能夠在服務器端的用戶端獲得更多改進。其他大部分 MongoDB 3.2 變化與存儲引擎，認證，集成和復制。我們將在未來覆蓋。