MongoDB 3.2中的最新功能 第三部分：為數(shù)據(jù)分析師和DBA提供的工具和集成

lyhabc

在這篇博客中，我將會簡要介紹一些關(guān)于支持數(shù)據(jù)分析人員、數(shù)據(jù)庫管理員及運維團隊的工具和集成。記住，您可以通過下載新功能白皮書來了解MongoDB 3.2提供的所有功能細節(jié)。

新用戶

伴隨著MongoDB部署在更廣范圍內(nèi)的公司應(yīng)用中，數(shù)據(jù)分析人員、數(shù)據(jù)庫管理員以及運維團隊將會需要將MongoDB集成到他們現(xiàn)有的進程及工具集。MongoDB 3.2允許分析人員從未經(jīng)開發(fā)的數(shù)據(jù)源中得到新洞察來支撐業(yè)務(wù)，而數(shù)據(jù)庫管理員和運維團隊可以在運行現(xiàn)有關(guān)系型數(shù)據(jù)庫的同時實施MongoDB，以保留管理平臺和技能儲備中的已有投資。

數(shù)據(jù)分析師和工程師

MongoDB BI 連接件

針對自助分析、基于實時操作型數(shù)據(jù)的快速發(fā)現(xiàn)和預(yù)測以及集成多結(jié)構(gòu)和流式數(shù)據(jù)集需求的不斷增長，商務(wù)智能和分析平臺成為增長速度最快的軟件市場之一。

為了滿足這些需求，用戶可以非常容易地使用符合產(chǎn)業(yè)標準的、基于SQL的商務(wù)智能和分析平臺對存儲在MongoDB中的現(xiàn)代應(yīng)用數(shù)據(jù)進行研究。通過使用MongoDB BI連接件，分析員、數(shù)據(jù)科學家以及業(yè)務(wù)用戶現(xiàn)在可以無縫地使用部署在無數(shù)企業(yè)中相同商務(wù)智能工具可視化 MongoDB中管理的半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)以及SQL數(shù)據(jù)庫中存儲的傳統(tǒng)數(shù)據(jù)。

bi_images-ffae146804


圖1：使用MongoDB生成的強大可視化獲取新洞察

MongoDB BI連接件 實現(xiàn)

基于SQL的商務(wù)智能工具一般使用一個固定的模式表示表格數(shù)據(jù)來連接到數(shù)據(jù)源。當使用MongoDB的動態(tài)模式及豐富的多維文檔時，這是一個非常大的挑戰(zhàn)。為了使得BI工具將查詢MongoDB作為一個數(shù)據(jù)源，BI連接件實現(xiàn)了以下操作：

為BI 工具提供希望可視化MongoDB集合的模式。用戶可以校驗?zāi)Ｊ捷敵鲆员ＷC正確表示數(shù)據(jù)類型、子文檔及數(shù)組
將BI 工具生成的SQL語句翻譯為等同的MongoDB查詢，之后發(fā)送給MongoDB處理
將返回的結(jié)果轉(zhuǎn)化為商務(wù)智能工具需要的表格格式，基于用戶需求對數(shù)據(jù)進行可視化
BI 連接件可以在MongoDB企業(yè)高級版中獲取。觀看演示了解BI連接件的運行，查閱文檔了解更多。您也可以下載BI連接件對其進行評估。

動態(tài)查找$lookup：將Left Outer Join引入到MongoDB

通過將一起存取的數(shù)據(jù)整合到一個單一文檔，應(yīng)用可以從MongoDB中獲取極大的性能提高。相反地，典型的傳統(tǒng)數(shù)據(jù)庫模式將相關(guān)的數(shù)據(jù)分散到一系列表中：例如，一個博客網(wǎng)站將與博客相關(guān)的每個標簽、類別、評論、作者及callback作為單獨表中的列。

通常，從操作型數(shù)據(jù)庫中選擇非規(guī)范化數(shù)據(jù)模型方法的最大優(yōu)勢在于：在單一操作中讀取或?qū)懭胍粭l完整記錄的效率優(yōu)先于存儲需求的增加。然而，下面是一個規(guī)范化數(shù)據(jù)的案例，尤其是需要混合多來源的數(shù)據(jù)用于分析的時候�？紤]一個購物車，有兩個用于處理訂單和產(chǎn)品信息的選項：

在相同文檔中包括一個訂單的所有數(shù)據(jù)

更快的讀取-一個find可以獲取所有需要的數(shù)據(jù)
文檔中包括的產(chǎn)品細節(jié)在訂單存儲時是正確的，產(chǎn)品的價格之后可能會變化，但是訂單文檔中仍然會維護訂單的準確表示
占用額外的存儲：每個產(chǎn)品的細節(jié)可能存儲在多個訂單文檔中，但是伴隨著內(nèi)存和存儲價格的下降，這將變得越來越不是問題
訂單文檔引用產(chǎn)品文檔

空間的高效性-產(chǎn)品細節(jié)只存儲一次
更慢的讀取-多數(shù)據(jù)庫的多次讀取
如果產(chǎn)品的某個屬性（例如單價）之后發(fā)生改變，任何之前的訂單文檔都是不正確的，因為他們引用的是更新的版本
額外的應(yīng)用邏輯-一個應(yīng)用必須在訂單文檔中對產(chǎn)品ID進行迭代，再從產(chǎn)品文檔中進行獲取
MongoDB 3.2 通過在$lookup 操作符中實現(xiàn)left out join操作引入了從多個集合中組合數(shù)據(jù)的供您使用，現(xiàn)在已經(jīng)可以作為MongoDB聚合框架管道中的一個階段。新的$lookup 階段在數(shù)據(jù)建模方面提供了更大的靈活性，并且提供了更高的性能和更少的應(yīng)用方代碼運行更豐富的分析。

實時分析和檢索

MongoDB 3.2擴展了在實時、操作型數(shù)據(jù)上執(zhí)行分析的選項，保證能夠基于現(xiàn)有數(shù)據(jù)快速簡單地處理結(jié)果�，F(xiàn)在可以在數(shù)據(jù)庫上執(zhí)行 之前需要在客戶端節(jié)點實現(xiàn)的工作：使開發(fā)人員能夠更聚焦于開發(fā)新功能。

改進的聚合

聚合管道是一個非常強大的方式，在MongoDB數(shù)據(jù)上執(zhí)行復(fù)雜的分析查詢時使用。聚合管道階段允許 來自一個集合一連串文檔的操作 要么通過 游標 返回給客戶端（與find相似），要么在一個最后的$out階段存儲在一個新的集合中。

在分析非常龐大的數(shù)據(jù)集時，對文檔的隨機樣本進行分析比對所有數(shù)據(jù)進行分析要高效很多。例如，如果你想對比 在咖啡店里簽到的數(shù)目與在酒吧簽到的數(shù)據(jù)，您可以不必檢索每個單一的簽到就能夠獲得一個較好的估計。在過去，這樣的取樣只能在應(yīng)用中實現(xiàn)，但是現(xiàn)在MongoDB引入了 $sample操作符，可以在聚合管道的任何階段使用。

MongoDB文檔可以存儲數(shù)據(jù)，也可以存儲簡單的值。盡管這個功能非常強大，但是在聚合階段并不需要對應(yīng)的在文檔中操作和過濾數(shù)組的能力，它們的作用被限制于分析的環(huán)境中。在處理數(shù)組時，MongoDB添加了新的操作符以提供更大的靈活性： $slice, $arrayElemAt, $concatArrays,$isArray, $filter, 以及 $min。

MongoDB 3.2 還增加了新的數(shù)學操作符，例如截斷、向上取整、向下取整、求絕對值、四舍五入、平方根、取對數(shù)以及標準差等操作。相關(guān)人員可以直接通過使用這些操作符，將代碼從客戶端層遷移到數(shù)據(jù)庫層，以較低的開發(fā)復(fù)雜性獲取更高的性能。

通過組合新的和已有的操作符，可以構(gòu)建聚合管道使用一個單一查詢得到復(fù)雜的結(jié)果。查閱文檔了解更多關(guān)于聚合管道的所有改進。

改進的文本檢索

對MongoDB中數(shù)據(jù)的文本檢索可以在數(shù)據(jù)庫中執(zhí)行，也可以使用一個外部的搜索引擎執(zhí)行。在數(shù)據(jù)庫中執(zhí)行檢索對管理員而言更加高效和簡單，因此如果可能的話，在數(shù)據(jù)庫中執(zhí)行是更佳的選項。

MongoDB通過增加對大小寫敏感檢索以及額外語言（包括阿拉伯語、波斯語、烏爾都語、簡體中文及繁體中文）的支持，擴展了數(shù)據(jù)庫內(nèi)文本檢索的用戶案例。為了提供對這些語言的支持，MongoDB企業(yè)高級版提供了與Basis Technology Rosette Linguistics Platform (RLP) 的集成，以實現(xiàn)基于語言的歸一化、分詞、斷句、詞干提取及分詞。

可以在文檔中找到關(guān)于文本檢索的更多信息。

數(shù)據(jù)庫管理員：MongoDB Compass

MongoDB的動態(tài)模式及富文檔模型使得開發(fā)人員更加高效，但是也使得對底層數(shù)據(jù)和結(jié)構(gòu)的探究和理解更加復(fù)雜，特別是對那些不熟悉MongoDB查詢語言的非開發(fā)人員而言。MongoDB Compass圖形化用戶界面允許用戶借助它在沒有任何MongoDB查詢語言基礎(chǔ)的情況下，理解數(shù)據(jù)庫中的數(shù)據(jù)結(jié)構(gòu)、執(zhí)行ad hoc查詢。典型的用戶包括：構(gòu)建新MongoDB項目的架構(gòu)師或者從一個工程師團隊接手數(shù)據(jù)庫、現(xiàn)在必須維護生產(chǎn)中數(shù)據(jù)庫的數(shù)據(jù)庫管理員，他們必須了解展示的數(shù)據(jù)類型、定義好合適的索引、判斷是否應(yīng)該添加文檔驗證規(guī)則來保證一致的文檔結(jié)構(gòu)。

直到現(xiàn)在，如果用戶希望了解他們數(shù)據(jù)的類型就不得不連接到MongoDB shell，然后寫查詢語句來逆向獲取文檔結(jié)構(gòu)、字段名稱和數(shù)據(jù)類型。類似地，任何想在數(shù)據(jù)上運行定制化查詢的用戶都需要了解MongoDB的查詢語言。

MongoDB Compass通過從一個集合中抽取文檔的子集為用戶提供了他們MongoDB模式的圖形化視圖。通過使用采樣，MongoDB Compass最小化數(shù)據(jù)庫支出并且能夠幾乎即時向用戶展示結(jié)果。

compass_document_overview-73295c5295


圖2：MongoDB Compass展示的文檔結(jié)構(gòu)和內(nèi)容

查詢數(shù)據(jù)

正如圖3展示的，可以通過在MongoDB Compass用戶接口簡單地選擇文檔元素來構(gòu)建和執(zhí)行一個查詢。通過選擇多個值，也可以構(gòu)建復(fù)雜的查詢。點擊一個按鈕就可以執(zhí)行該查詢并且同時以圖形化和一系列JSON文檔的形式查看結(jié)果。

compass_build_query-010a86ecf8

圖 3：使用MongoDB Compass交互式構(gòu)建和執(zhí)行數(shù)據(jù)庫查詢

無論數(shù)據(jù)庫多龐大，MongoDB Compass都可以對數(shù)據(jù)庫進行抽樣以提供一個快速的交互式體驗。如果需要得到完整結(jié)果，可以簡單地將查詢復(fù)制粘貼到一個MongoDB shell窗口中。

MongoDB 專業(yè)版和MongoDB企業(yè)高級版中都提供了MongoDB Compass。你可以在文檔中了解更多關(guān)于Compass的信息，并且在我們簡短的演示系列中查看它的具體功能：

第一部分：Compass介紹
第二部分：模式可視化
第三部分：可視化查詢構(gòu)建
你可以前往MongoDB下載中心體驗評估MongoDB Compass。

運維團隊

MongoDB Ops Manager和Cloud Manager 都是運行MongoDB的最佳方式，它們將類似于部署、擴展、升級及備份都簡化到一系列的點擊或者一個API調(diào)用。運維團隊使用Ops或Cloud Manager平臺之后可以提高10-20倍的生產(chǎn)效率。

MongoDB 3.2對Ops和Cloud Manager同時進行了改進，管理員可以：

將MongoDB與現(xiàn)有的應(yīng)用性能監(jiān)控平臺進行集成，在一個單一的虛擬管理平臺中可視化地了解整個IT資產(chǎn)全局的健康
通過使用Ops Manager對數(shù)據(jù)庫測報進行粒度的監(jiān)控，包括新的查詢分析器可視化來對任何MongoDB特有的問題進行進一步挖掘
使用Ops Manager自動工具來初始化零宕機維護和升級行為，例如在一個分片集群中推出新索引
對標準的、網(wǎng)絡(luò)掛載的文件系統(tǒng)中的數(shù)據(jù)庫創(chuàng)建即時的、連續(xù)的快照，并且從備份文件中恢復(fù)完整的、運行著MongoDB的集群。
應(yīng)用性能監(jiān)控集成：New Relic & AppDynamic

許多運維團隊使用應(yīng)用性能監(jiān)控（APM）平臺例如New Relic和AppDynamic在一個單一的管理用戶界面獲取對他們完整IT架構(gòu)的全局概覽，可以快速識別出有高風險會影響客戶體驗的問題并且定位到特定的組件中：設(shè)備、硬件架構(gòu)、網(wǎng)絡(luò)、API、應(yīng)用代碼、數(shù)據(jù)庫還是其它模塊。

MongoDB驅(qū)動程序已經(jīng)通過將查詢性能度量指標暴露給應(yīng)用性能管理工具的新API進行改進。管理員可以監(jiān)控每個操作花費的時間，找到需要進一步分析和優(yōu)化的、正在運行的慢查詢。

此外，Cloud Manager將會提供與New Relic平臺的打包集成。Cloud Manager中的關(guān)鍵度量指標將可以從應(yīng)用性能監(jiān)控中獲取，并用于可視化，使得用戶可以在剩余的應(yīng)用資產(chǎn)中監(jiān)控和關(guān)聯(lián)MongoDB健康。

apm-31ed29b9c0


圖4：將MongoDB集成到一個應(yīng)用性能的單一視圖

正如圖4展示的，應(yīng)用性能監(jiān)控的用戶接口中展示了Cloud Manager用戶所熟悉的度量指標總結(jié)。管理員也可以運行New Relic Insight 對監(jiān)控中的數(shù)據(jù)進行分析，生成儀表盤，提供對關(guān)鍵性能指標（KPIs）的實時追蹤。

如果運維團隊需要更細粒度的監(jiān)控指標，他們可以對Cloud Manager維護的100+系統(tǒng)度量指標進行進一步挖掘。例如，新的可視化查詢分析器幫助診斷正在運行的慢查詢，隨后可以通過增加一個新索引，并且將新索引自動地部署到集群中的每一個節(jié)點而解決這個問題。

查詢性能優(yōu)化：啟動快速和簡單查詢優(yōu)化

MongoDB數(shù)據(jù)庫分析工具收集可用于分析查詢性能的細粒度信息。然而，由于輸出非常難以解析，使得正在運行的慢查詢難以正確。此外，不得不單獨激活每個MongoDB實例的分析工具，將每個節(jié)點中的輸出進行手動整合以提供對整個部署的全局視圖。

Ops Manager和Cloud Manager已經(jīng)發(fā)布了新的可視化查詢分析器，為運維團隊和數(shù)據(jù)庫管理員提供了一個快速和方便的方式用于分析特定的查詢或者查詢族�？梢暬�查詢分析器（如圖5所示）展示了查詢和寫延遲隨著時間的變化趨勢，簡化了識別相同模式和特征的慢查詢及識別任何延遲峰值的操作。只需要在Ops Manager的用戶界面進行一個簡單的點擊，激活分析器，就可以在一個單獨的界面統(tǒng)一展示每個節(jié)點的度量指標。

profiler-32bd2838e7


圖5： MongoDB Ops Manager中的可視化查詢分析器

索引建議&自動化索引構(gòu)建

為了進一步簡化操作，可視化查詢分析器將會對其收集的數(shù)據(jù)進行分析，為新索引的構(gòu)建提供建議，以提高查詢性能。

一旦確定，這些新索引將會需要鋪開到生產(chǎn)系統(tǒng)中。為了最小化對真實系統(tǒng)的影響，運行滾動索引的最佳實踐是：從每個從節(jié)點開始，最后在原始的主節(jié)點和其它從節(jié)點之一進行換主之后，再在該節(jié)點上建立索引。滾動的過程可以手動執(zhí)行，但是Ops Manager和Cloud Manager現(xiàn)在可以在MongoDB復(fù)制集間自動化這個流程，降低了運維支出及由錯誤順序管理流程而產(chǎn)生故障的風險。

新索引選項：部分索引

從節(jié)點索引是MongoDB區(qū)分與其它NoSQL數(shù)據(jù)庫不同的地方之一：允許應(yīng)用使用多種方式高效地讀取它們的數(shù)據(jù)。然而，從節(jié)點索引確實帶來了一些消耗：

由于需要更新從節(jié)點索引，數(shù)據(jù)庫的寫入將會變得更加緩慢
需要內(nèi)存和存儲來保存從節(jié)點索引
部分索引在提供優(yōu)秀的查詢性能和消耗更少的系統(tǒng)資源之間有一個很好的平衡。例如，考慮一個訂單處理應(yīng)用：應(yīng)用會頻繁查詢訂單集合以展示某個特定用戶的所有未完成訂單。為了高效的性能，在集合的userID字段上創(chuàng)建一個索引是非常有必要的。然而，在一個給定的時間內(nèi)，只有非常小部分的訂單滿足條件。將索引限制在userID上只包含“活躍”狀態(tài)的訂單將會使得索引條目的數(shù)量從百萬級降低到數(shù)千條，節(jié)約了工作集內(nèi)存和磁盤空間，同時還進一步加速了查詢：因為更少的索引將會帶來更快的檢索。

通過在索引創(chuàng)建階段指定一個過濾表達式，一個用戶可以使得MongoDB只包括那些滿足特定條件的文檔。

在執(zhí)行數(shù)據(jù)庫find操作時，為了讓優(yōu)化器使用部分索引，應(yīng)用應(yīng)該包括用于過濾的值以及被索引的值。查閱文檔了解更多。

其它Ops Manager改進

除了上面討論的功能之外，還有一些其它的大量改進提高了運維團隊的生產(chǎn)效率，簡化了安裝和管理：

運維團隊現(xiàn)在可以使用Ops Manager和Cloud Manager安全可靠地自動化數(shù)據(jù)庫恢復(fù)。只需要幾個簡單的點擊就可以進行完整的開發(fā)、測試和恢復(fù)集群。
與現(xiàn)有存儲架構(gòu)進行集成，MongoDB備份文件目前可以被存儲在一個標準網(wǎng)絡(luò)掛載的文件系統(tǒng)中。
運維團隊只能對特定集合的備份進行配置，而不是整個數(shù)據(jù)庫，從而加速了備份并且減少了所需的存儲空間。這個改進在Cloud Manager平臺中可以看到。
現(xiàn)在可以直接通過集中的Ops Manager用戶接口進行所有應(yīng)用和備份組件的安裝和配置，并且也提供了一個用于健康監(jiān)控的、單一的一覽儀表盤。
備份架構(gòu)的改進提高了對第一個數(shù)據(jù)庫快照的讀取速度。
目前可以定義被排除的錯誤警報及維護窗口，在這個階段，Ops Manager和Cloud Manager的警報將不會被觸發(fā)。
從應(yīng)用性能管理集成到使用索引建議和自動化滾動索引構(gòu)建的可視化分析器、再到平臺簡化和自動化集群恢復(fù)，Ops Manager可以幫助您的團隊更加高效。