MongoDB 3.2 先睹為快

MongoDB 3.2 先睹為快

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 變化與儲存引擎，認證，整合和複製。我們將在未來覆蓋。

MongoDB常用操作命令整理 

MongoDB 3.0 正式版發布下載 

CentOS編譯安裝MongoDB

CentOS 編譯安裝 MongoDB與mongoDB的php擴充

CentOS 6 使用 yum 安裝MongoDB及伺服器端配置

Ubuntu 13.04下安裝MongoDB2.4.3

MongoDB入門必讀(概念與實戰並重)

Ubunu 14.04下MongoDB的安裝指南

《MongoDB 權威指南》(MongoDB: The Definitive Guide)英文文字版[PDF]

Nagios監控MongoDB分區叢集服務實戰

基於CentOS 6.5作業系統搭建MongoDB服務

MongoDB 的詳細介紹：請點這裡
MongoDB 的：請點這裡

英文原文：MongoDB 3.2 – A First Forward Look

本文永久更新連結地址：