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

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

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

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

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

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

— 1 —

為什么要引入分析？

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

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

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

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

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

— 2 —

無法一蹴而就的事業(yè)

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

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

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

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

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

— 3 —

有沒有可能對接SQL？

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

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

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

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

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

— 4 —

以人為本

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

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

— 5 —

意不在取代數(shù)據(jù)倉庫、數(shù)據(jù)湖或智能湖倉

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

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

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