大概六年前，在為ZDNet撰寫文章時(shí)，我們?cè)?jīng)認(rèn)真思考過一個(gè)問題：MongoDB未來(lái)要走向何方？隨著時(shí)間推移，答案已經(jīng)逐漸浮出水面：要讓數(shù)據(jù)庫(kù)更具可擴(kuò)展性，支持開發(fā)者編寫好的各種應(yīng)用程序。為此，MongoDB增加了原生搜索功能，以支持內(nèi)容管理；物聯(lián)網(wǎng)用例也獲得了時(shí)序數(shù)據(jù)支持；另外還有變更流，可幫助電商應(yīng)用快速預(yù)測(cè)出下一最佳行動(dòng)。

順帶一說(shuō)，MongoDB的客戶還需要一種能夠與開發(fā)工具良好匹配、易于上手的云解決方案。結(jié)果就是Atlas，這項(xiàng)托管云服務(wù)目前占MongoDB整體業(yè)務(wù)的60%。

但還有另外一個(gè)重要部分值得關(guān)注——分析。

剛開始，MongoDB被設(shè)計(jì)成了一套可操作數(shù)據(jù)庫(kù)。主要用于管理在線訂閱者的個(gè)人資料等用例，借此提供更好的游戲或娛樂體驗(yàn)。它還可以捕捉汽車遠(yuǎn)程信息，借此跟蹤組件的運(yùn)行狀態(tài)；隨時(shí)訪問臨床患者數(shù)據(jù)，管理醫(yī)療保健服務(wù)；或者為電子商務(wù)應(yīng)用提供支持，實(shí)現(xiàn)無(wú)縫化的購(gòu)物體驗(yàn)。

千萬(wàn)別誤會(huì)，并不是說(shuō)MongoDB只關(guān)注寫入側(cè)。只是作為其最早的增強(qiáng)功能之一，MongoDB聚合框架能夠很好地解決多步“分組”查詢，而這正是交易型數(shù)據(jù)庫(kù)的典型特征。

但平心而論，與大多數(shù)其他操作型數(shù)據(jù)庫(kù)一樣，MongoDB直到最近才剛剛得到重視。畢竟大家可能很難想象要在一套操作型數(shù)據(jù)庫(kù)中，執(zhí)行涵蓋多個(gè)表（或文檔集合）的復(fù)雜查詢。

一、為什么要引入分析？

大多數(shù)操作型應(yīng)用程序的共同之處是一旦添加了分析功能，其實(shí)用性將馬上飛升。例如，分析可以幫助汽車制造商增強(qiáng)預(yù)防性維護(hù)，醫(yī)療保健服務(wù)商能夠確定最佳護(hù)理方案，電子商務(wù)或游戲廠商則可以改善客戶交互、防止客戶流失。這些出于決策優(yōu)化而設(shè)計(jì)出的分析功能，是對(duì)操作型數(shù)據(jù)庫(kù)的良好補(bǔ)充。

把分析跟交易型數(shù)據(jù)庫(kù)聯(lián)系起來(lái)絕不是什么新鮮想法，HTAP、translytical或增強(qiáng)型交易數(shù)據(jù)庫(kù)都是分析廠商們拿出的相應(yīng)成果。

云原生提出的計(jì)算與存儲(chǔ)彼此分離的理念，則讓我們有了另一個(gè)在不影響性能或吞吐量的情況下、將操作數(shù)據(jù)處理與分析加以結(jié)合的好機(jī)會(huì)。最近亮相的Oracle MySQL HeatWaev和谷歌AlloyDB，正是大廠在這個(gè)方向上的積極嘗試。

大多數(shù)此類混合數(shù)據(jù)庫(kù)都會(huì)使用專為分析而設(shè)計(jì)的柱狀表，對(duì)傳統(tǒng)行存儲(chǔ)進(jìn)行補(bǔ)充。順帶一提，它們也都使用相同的常見關(guān)系數(shù)據(jù)結(jié)構(gòu)，確保轉(zhuǎn)換更加簡(jiǎn)便易行。與之對(duì)應(yīng)，如果引入包含分層和嵌套數(shù)據(jù)結(jié)構(gòu)的文檔模型，那么轉(zhuǎn)譯過程往往會(huì)更加困難。

那么，MongoDB是不是也該擁有自己的分析功能？這還是要看我們?nèi)绾味x“分析”。如前所述，如果我們向交易中引入智能化操作分析，那么應(yīng)用程序的實(shí)用性將大大增強(qiáng)。所以只要把范圍設(shè)定在快速?zèng)Q策分析，而非復(fù)雜的分析建模，那么答案就是肯定的。

二、無(wú)法一蹴而就的事業(yè)

MongoDB已經(jīng)開始嘗試支持分析功能。它從可視化開始，著手提供自己的圖表功能與商務(wù)智能（BI）連接器，現(xiàn)在的MongoDB在Tableaus與Qliks端看來(lái)已經(jīng)幾乎與MySQL無(wú)異。雖然一圖勝萬(wàn)言，但對(duì)于分析來(lái)說(shuō)，可視化還只是萬(wàn)里長(zhǎng)征第一步。MongoDB盡管能提供趨勢(shì)快照，但還無(wú)法進(jìn)一步實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)（往往涉及更復(fù)雜的查詢），也無(wú)法完全回答“為什么”會(huì)出現(xiàn)哪些狀況。

MongoDB決心已定，開始通過分析提升自身競(jìng)爭(zhēng)力。但在這個(gè)分析復(fù)雜度愈發(fā)高企的時(shí)代，它顯然無(wú)法取代Snowflake、Redshift、Databricks或者其他專業(yè)分析方案。但MongoDB分析面向的也并非數(shù)據(jù)分析師，而是應(yīng)用程序開發(fā)者。回到操作型數(shù)據(jù)庫(kù)的首要原則——盡量別把它，跟需要高度復(fù)雜的連接及/或高并發(fā)查詢扯在一起。只要能讓開發(fā)者構(gòu)建起更好的應(yīng)用程序，MongoDB就算是成功了。

Atlas能夠靈活預(yù)留專門的分析節(jié)點(diǎn)。MongoDB也將在不久后，全面允許客戶在更適合分析的節(jié)點(diǎn)上選擇不同的計(jì)算實(shí)例。這些節(jié)點(diǎn)將提供在線數(shù)據(jù)復(fù)制功能，借此實(shí)現(xiàn)近實(shí)時(shí)分析。

但這還只是第一步：由于Atlas可運(yùn)行在多種云環(huán)境上，因此客戶還可以選擇更多其他實(shí)例。不過大家無(wú)需擔(dān)心，MongoDB未來(lái)將推出規(guī)范性指南，同時(shí)提供機(jī)器學(xué)習(xí)方案幫助大家自動(dòng)選擇最適應(yīng)工作負(fù)載的實(shí)例類型。

對(duì)分析的嘗試當(dāng)然不可能止步于此，去年預(yù)覽發(fā)布的Atlas Serverless將于本周推出正式版。剛剛起步的分析自然也將成為受益者，因?yàn)榉治鲱惞ぷ髫?fù)載一般與交易事務(wù)不同、突發(fā)峰值往往更多。

三、有沒有可能對(duì)接SQL？

其實(shí)引入SQL的想法在MongoDB發(fā)展早期一直備受反對(duì)，當(dāng)時(shí)有聲音認(rèn)為MongoDB永遠(yuǎn)不該成為關(guān)系數(shù)據(jù)庫(kù)。但是，理性終將戰(zhàn)勝情緒。

本周，MongoDB引入了新的接口，可用于讀取Atlas數(shù)據(jù)。這是一種全新結(jié)構(gòu)，采用不同于BI連接器的通道。Atlas SQL將是MongoDB為數(shù)據(jù)提供SQL接口的第一次真正嘗試，其思路絕不是簡(jiǎn)單把JSON扁平化以使其在Tableau中看起來(lái)像MySQL，而是提供更加精細(xì)的視圖、反映JSON文檔架構(gòu)的豐富性。

但SQL接口編寫工作不可能一蹴而就，所以預(yù)計(jì)Atlas SQL將在未來(lái)幾年內(nèi)逐漸發(fā)展完善。畢竟要想與各類SQL工具（不止是可視化）實(shí)現(xiàn)全面集成，MongoDB還得在豐富的數(shù)據(jù)倉(cāng)庫(kù)選項(xiàng)上多下工夫。我們還希望看到對(duì)upserts等操作的支持，分析平臺(tái)沒有了這些核心功能，就相當(dāng)于分析表中失去了行插入功能。

與Atlas SQL接口一同推出預(yù)覽版的全新列存儲(chǔ)索引，則意在提高分析查詢的性能水平。同樣的，這還僅僅只是開始。例如，MongoDB用戶目前仍需要手動(dòng)設(shè)置列存儲(chǔ)索引、指定字段。但從長(zhǎng)遠(yuǎn)來(lái)看，我們可以通過分析訪問模式來(lái)實(shí)現(xiàn)自動(dòng)化。設(shè)想一下：后續(xù)我們可以豐富元數(shù)據(jù)以分析字段基數(shù)，添加Bloom過濾器以進(jìn)一步優(yōu)化掃描功能，也可以繼續(xù)完善查詢計(jì)劃器。

接下來(lái)是Atlas Data Lake，負(fù)責(zé)為云對(duì)象存儲(chǔ)中的JSON文檔提供聯(lián)合視圖。Atlas Data Lake在改造完成后，將針對(duì)多個(gè)Atlas集群和云對(duì)象存儲(chǔ)提供更多的通用聯(lián)合查詢功能。新的存儲(chǔ)層會(huì)自動(dòng)將Atlas集群數(shù)據(jù)集提取到云對(duì)象存儲(chǔ)和內(nèi)部技術(shù)目錄  （并非Alation）組合當(dāng)中，借此加快分析查詢。

四、以人為本

長(zhǎng)期以來(lái)，MongoDB一直是開發(fā)者們最喜歡的數(shù)據(jù)庫(kù)之一。這是因?yàn)殚_發(fā)者熱愛JavaScript和JSON，目前JS在Tiobe人氣指數(shù)中排名第七。而JavaScript、JSON和文檔模型將是MongoDB的永恒主題。但很遺憾，由于MongoDB此前一直刻意回避SQL，所以也就失去了相應(yīng)的龐大人才庫(kù)——SQL開發(fā)者同樣體量龐大，讓這一查詢語(yǔ)言在人氣指數(shù)中位列第九。現(xiàn)在，是時(shí)候做出改變了。

雖然MongoDB仍然認(rèn)為文檔模型優(yōu)于并有望取代關(guān)系模型（只是一家之言），但相信大家都認(rèn)同一點(diǎn)：為了進(jìn)一步擴(kuò)大影響范圍，MongoDB必須接納那些以往被忽略的受眾群體。要想雙贏，兩大陣營(yíng)應(yīng)該團(tuán)結(jié)一致、實(shí)現(xiàn)簡(jiǎn)化；對(duì)于某些操作用例，我們不必將數(shù)據(jù)移動(dòng)并轉(zhuǎn)移至獨(dú)立的數(shù)據(jù)倉(cāng)庫(kù)目標(biāo)，而是簡(jiǎn)化為在統(tǒng)一平臺(tái)內(nèi)操作，最終將數(shù)據(jù)提取轉(zhuǎn)化為更簡(jiǎn)單的數(shù)據(jù)復(fù)制。

五、意不在取代數(shù)據(jù)倉(cāng)庫(kù)、

數(shù)據(jù)湖或智能湖倉(cāng)

MongoDB絕不是要取代獨(dú)立的數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖或智能湖倉(cāng)。目前復(fù)雜建模與發(fā)現(xiàn)已經(jīng)成為分析工作中的重要組成部分，所以必須與操作型系統(tǒng)分別執(zhí)行。更重要的是，在操作型數(shù)據(jù)庫(kù)中支持分析，最大的意義其實(shí)是實(shí)現(xiàn)流程內(nèi)聯(lián)并盡可能實(shí)時(shí)化。

換言之，MongoDB將由此實(shí)現(xiàn)與Snowflakes或者Databricks的全面協(xié)同。大家可以在數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖或智能湖倉(cāng)中開發(fā)用于識(shí)別異常值的模型，再將結(jié)果整理為一個(gè)相對(duì)簡(jiǎn)單、易于處理的分類、預(yù)測(cè)或規(guī)范模型。這樣只要交易中出現(xiàn)異常，該模型就會(huì)被自動(dòng)觸發(fā)。

如今，在MongoDB中實(shí)現(xiàn)這樣的閉環(huán)流程已經(jīng)頗具可行性，但具體方法仍然非常復(fù)雜。大家需要將MongoDB中的變更流、觸發(fā)器和函數(shù)拼湊起來(lái)，共同組織成某種封閉式的分析反饋循環(huán)。相信在不久的將來(lái)，MongoDB將把這些復(fù)雜性要素隱藏在后臺(tái)，直接提供簡(jiǎn)單易用的閉環(huán)與近實(shí)時(shí)分析選項(xiàng)。這絕不是憑空想象，而是技術(shù)發(fā)展趨勢(shì)的必然結(jié)果。如今，MongoDB已經(jīng)踏上了這段分析探索之旅，我們也期待著它能早傳捷報(bào)。