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

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

但還有另外一個重要部分值得關注——分析。

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

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

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

一、為什么要引入分析？

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

把分析跟交易型數據庫聯系起來絕不是什么新鮮想法，HTAP、translytical或增強型交易數據庫都是分析廠商們拿出的相應成果。

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

大多數此類混合數據庫都會使用專為分析而設計的柱狀表，對傳統行存儲進行補充。順帶一提，它們也都使用相同的常見關系數據結構，確保轉換更加簡便易行。與之對應，如果引入包含分層和嵌套數據結構的文檔模型，那么轉譯過程往往會更加困難。

那么，MongoDB是不是也該擁有自己的分析功能？這還是要看我們如何定義“分析”。如前所述，如果我們向交易中引入智能化操作分析，那么應用程序的實用性將大大增強。所以只要把范圍設定在快速決策分析，而非復雜的分析建模，那么答案就是肯定的。

二、無法一蹴而就的事業

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

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

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

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

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

三、有沒有可能對接SQL？

其實引入SQL的想法在MongoDB發展早期一直備受反對，當時有聲音認為MongoDB永遠不該成為關系數據庫。但是，理性終將戰勝情緒。

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

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

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

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

四、以人為本

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

雖然MongoDB仍然認為文檔模型優于并有望取代關系模型（只是一家之言），但相信大家都認同一點：為了進一步擴大影響范圍，MongoDB必須接納那些以往被忽略的受眾群體。要想雙贏，兩大陣營應該團結一致、實現簡化；對于某些操作用例，我們不必將數據移動并轉移至獨立的數據倉庫目標，而是簡化為在統一平臺內操作，最終將數據提取轉化為更簡單的數據復制。

五、意不在取代數據倉庫、

數據湖或智能湖倉

MongoDB絕不是要取代獨立的數據倉庫、數據湖或智能湖倉。目前復雜建模與發現已經成為分析工作中的重要組成部分，所以必須與操作型系統分別執行。更重要的是，在操作型數據庫中支持分析，最大的意義其實是實現流程內聯并盡可能實時化。

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

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