MongoDB 3.2 預計在2015年底在 MongoDB World 裡向大家介紹，我們認為這有益於帶來一些很有吸引力的特徵。大多數的這些功能仍然在發展，儘管它們被展示出來，有可能真正等到 MongoDB 3.2 公佈時，這些特徵也許將會發生改變。
模式?
會議上有很多關於模式的討論。一個“無模式”的資料庫，如 MongoDB 的一個提升，這看起來很奇怪，但它似乎 MongoDB，公司已重新發現規則的結構儲存在資料庫中的文件可以幫助管理一個資料庫的演變。
這實際上涉及到的是一個新的，MongoDB 的企業工具支付，掃描集合和逆向工程師從集合模式中的搜尋。它也提供了關於在 MongoDB3.2 使用的新熱性，來使收集更有用、更正常，這些特性就是……
校驗
MongoDB 開源版本的諸多新特性之一是可以給文件的欄位加校驗。 這個特點， SERVER-18227， 使得集合可以擁有一個校驗器來作為集合後設資料的一部分。校驗器是一個匹配表示式，會在文件插入或修改時驗證匹配結果為 true。 如果校驗不通過，修改將會被拒絕並返回一個錯誤 121, DocumentValidationFailure.
但是也有些限制。首先，校驗器必須是非常簡單的匹配表示式；大於、 小於或是否存在等。不可以用地理位置的附近，不可以用文字查詢也不能用where表示式。
你可以在建立表（譯者注:我想應該是集合）的時候設定校驗器，只需要加一個 validator 的設定項，或者也可通過 collmod 命令，如下：
|
1 2 |
db.runCommand({"collMod": collName, "validator" : {a: {$exists: true}}}) |
這個例子校驗了欄位”a”是否存在。如果你想修改校驗器，但是注意到並沒有獲取後設資料函式，因此需要獲取集合的統計資訊（stats），這個裡面有現有的校驗器。然後就能用”collMod”來修改跟重新設定了。
關於校驗器，還有些需要記住的。首先，他們只在新增跟修改操作時生效，言下之意是對於集合中的現存資料，校驗器是不校驗的…直到你更新一個已經存在的文件，校驗器就會起作用了，除非文件沒做更改。因此如果你想啟動校驗，你可能需要先把現有集合掃描一遍，確認所有文件符合或者對所有新增/修改操作新增失敗快照。你可以把 BypassDocumentValidation 許可權給你的使用者，讓他們設定bypassDocumentationValidation 標誌，但是這可能與校驗的初衷有所衝突。順帶一提，這些許可權跟標識主要是為一些運維操作設計的，比如恢復一個 partially conforming collection 。
區域性索引
與模式相關的另一個伺服器端的功能就是”區域性索引“，這個功能自2010開始就在 MongoDB 的 JIRA 裡時不時的被提到。對這一功能最好的解釋就是通過例項來說明。假設你手頭有你曾經接觸過的所有客戶，包括活躍的和非活躍的。在日常的使用中，你想在查詢活躍客戶時獲得很好的效能。要達到很好效能的一種方式是分為兩個資料集（即表）來處理，一個資料集是活躍客戶，它具有索引，另一資料集是非活躍客戶，沒有索引，不過，這就要求對應用進行更改，確保客戶儲存在它應該儲存的那一資料集裡。另外，你可以使用區域性索引，區域性索引只對哪些滿足過濾器表示式的文件進行索引。如下：
|
1 2 |
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 變化與儲存引擎，認證，整合和複製。我們將在未來覆蓋。