一、MongoDB 資料庫定位
首先我們來看一下 MongoDB 是什麼樣的資料庫。資料庫分兩大類：
1. OLTP（Online Transaction Processing）聯機事務處理。 2. OLAP（On-Line Analytical Processing）聯機分析處理。
OLTP 指手機應用、網頁應用，有互動式的。需求資料庫能夠提供毫秒級的響應。
OLAP 指可以在晚上跑一個批，做分析處理，跑完以後把結果寫到表裡面，第二天來 拿結果。
OLTP 和 OLAP 最大的差別就是時效性的差別。
MongoDB 是 OLTP 型的資料庫，跟 Oracle、MySQL、SQL Server 等 OLTP 型 資料庫對标。MySQL 能做的事情，MongoDB 都可以做，隻不過做法不一樣。從 MongoDB 4.0 開始完全支援跟交易相關的強事務。
MongoDB 的三個優點：
第一，橫向擴充能力，資料量或并發量增加時候架構可以自動擴充。MongoDB 是原 生的分布式資料庫，通過分片技術，可以做到 TB 甚至 PB 級的資料量，以及數千數萬數十 萬到百萬級的并發，或者是連接配接數等等。MySQL 就需要一些特定的分庫分表，或者第三方 的解決方案。
第二，靈活模型，适合疊代開發，資料模型多變場景。現在的開發都是講究快速疊代， 往往在第一個版本出來的時候，需求是不完整的，這個時候有一個比較靈活的、不固定結構 的資料庫，在開發時間上會節省非常多。
第三，JSON 資料結構，适合微服務/REST API。REST API 的後面其實都是我們 現在用的都是一種 REST 或者 JSON 的資料結構，而 MongoDB 是一種非常原生的支援。
二、選型考量
基于技術需求選擇 MongoDB
第一個名額：資料量。假設單表裡面要儲存的處理資料超過億或者 10 億的級别，而且 使用挺頻繁，這個時候就可以考慮使用 MongoDB。這種場景下如果用 MySQL 做分庫分 表，效率、穩定性、可靠性肯定沒法跟 MongoDB 相比。
第二個名額，資料結構模型不确定，或者明确會多變。比如疊代開發的場景下， MongoDB 允許過程中快速疊代，不需要去修改它的 Schema，繼續可以支援你的業務。
第三個名額，高并發讀寫，MongoDB 通過分片直接支援。比如線上應用，網上可能 是有很大很多的使用者一起使用，并發性會非常高，這個時候考慮到 MongoDB 的分布式分 片叢集，可以支撐非常大的并發。基于單機的，比如說 Oracle、MySQL、SQL Server 可能都會有很大的瓶頸。
其他還有一些場景可以選擇 MongoDB，如跨地區叢集、地理位置查詢、輕松支援異 構資料與大寬表做海量資料的分析， MongoDB 都是非常明顯的優勢。
基于場景選擇 MongoDB
基于場景選擇 MongoDB 比較常見的有：移動/小程式 APP、電商、内容管理、物聯 網、SaaS 應用、主機分流、實時分析、資料中台等。
移動應用: 對網際網路公司來說，移動/小程式 APP 是必不可少的，它的特點是： 它是 基于 REST API/JSON 進行互動，采用的是網際網路公司的疊代式開發，兩個星期一個疊代、 一個版本，著名的網際網路公司每天都會出版本，月月新、周周新、天天新，手機移動的場景 下，會有非常多的地理位置。 成功的 APP 使用者往往不是幾萬幾十萬，甚至百萬千萬上億， 像微信、位元組、抖音等移動應用場景， MongoDB 都能夠支撐。
位元組跳動: 位元組去年的分享，一年前的時候，他們正在大量的遷移 MySQL 的應用到 MongoDB 上面來。主要的考量就是并發量和資料量達到一定地步以後，MySQL 叢集的 性能不能穩定工作，毛刺比較多。另外就是擴容困難，和業務疊代速度跟不上。他們一天要 釋出幾十個版本，即使 DBA 響應時間再快，也快不過疊代，DBA 就幹脆把這個步驟省掉。 位元組的場景非常多，去年就已經有 150 多個叢集，350 多個使用者項目。今年應該更多了。 他們使用的場景有幾大類，線上 TP 業務，和地理位置相關的查詢業務，遊戲，以及中台系 統的中繼資料資訊等，都需要通過 MongoDB 支撐。
主機分流/讀寫分離：這個場景在金融行業比較常見。
金融行業的特點是業務系統、交易系統用的很多的都是 IBM 或者小型機，上面運作 DB2 或者比較老的關系資料庫。特點是按量付費，它并不是買斷的，每讀一次寫一次都有 額外的計費，叫 MIPS。最近幾年，銀行在做大量手機端的開發，把交易資料放到手機端， 手機端對交易資料的讀的流量猛增。根據某個銀行的統計，現 99%的流量都是讀流量，對 成本增加非常高。
還有關系業務模型改動非常困難，想去創新，想去增加一些新的業務，需要非常高的成 本。有一個政策，是把這些資料拿出來，做讀寫分離，用另外一種資料庫來支援這種讀。
在這樣的場景下，MongoDB 是非常好的選擇。相比關系資料庫 MongoDB 是基于内 存的一種讀寫，它的分布式可以把海量資料、幾年的曆史資料拿過來放到熱資料庫裡面，讓 其支撐手機端的交易查詢。比如海外的花旗銀行，國内的中國銀行。
主機分流案例：中國銀行
業務需求是在手機銀行裡支撐曆史交易資料的查詢，其他的金融月曆應用。比如查詢三 年的賬單，三年資料每天都有 6000 萬，月末的時候還有幾個億，加上三年算下來有幾百幾 千億的資料，是非常海量的資料。他們最終是選擇了 MongoDB 分片叢集來做這樣的事情。
上圖所示是架構圖，首先它的借記卡系統和信用卡系統是基于 Oracle 做的，使用 CDC 的技術，是實時資料庫同步的機制，把資料從庫裡邊：“增删改”都拿出來，然後通 過 Spark 進行計算處理，然後放到 MongoDB 的叢集裡面，再變成 JSON 檔案的格式， 再通過 API 的後端，把資料暴露出去給手機 APP 的前端。
通過這種方式，資料實時的從主機系統同步過來，通過 API 的方式，可以提供非常高 效率、高性能的查詢給到手機 APP，保證使用者的體驗。這種場景是比較常見的金融資料的 查詢庫，很多銀行都在使用。
資料中台 它的架構是把企業多個業務系統資料彙聚到一個中台，通過治理服務出去， 快速的提高企業的業務響應能力，形成大中台小前端的方式。場景特點：
- 多源系統資料彙聚場景，資料模型多樣化。
- 存儲量較大，需要能夠分布式存儲。
- 快速業務響應能力意味着快速資料模組化和快速釋出。
- 支援企業所有業務系統的資料需求，查詢性能需要保證。
基于資料中台場景的特性，MongoDB 的結構非常适合多中繼資料的聚合。 比如大的差 異性字段，字段的個數、屬性的個數、都是不一樣的。這個時候建一張新的 Schema 允許 過程中快速疊代，不需要去修改它的 Schema 結構是非常困難的。通過 JSON 的這種動 态模型，很容易把它結合起來。MongoDB 的橫向擴充能力，可以讓一套系統支撐多套業 務系統的資料存儲。 MongoDB 還有記憶體緩存的讀寫能力，或者是快速高并發的讀能力， 可以支撐資料中台業務。
MongoDB 選型考量總結：
- JSON 動态結構支援異構資料非常輕松。 原生的橫向擴充能力（通過分片）。
- 基于記憶體緩存的讀寫能力，可以提供多套業務系統使用同一份資料。
三、場景舉例
資料中台案例 – 周生生全管道實時資料服務平台：
周生生珠寶在中港台澳各地有數百家門店，在建立資料服務平台之前，中廣台澳各地有 很多套業務系統，有銷售、庫存、商品、會員等等，資料散落在這些系統中間，并沒有統一。
訂單跨地業務，需要完整的最新的庫存資訊。
基于這些建構了資料中台系統，使用 Tapdata 實時同步功能，基于 Logminer 和 CDC 機制，把資料從 Oracle 裡面把它抽出來，實時同步到 MongoDB。過程中采用實時 處理能力，把基于關系模型的各種多表合并成一個 JSON，實時的固化視圖放在 MongoDB 裡面。它的價值就是能夠存儲數十億筆資料，同時能夠提供毫秒級的響應。
另外一點，提供中港台跨地區分布，保證使用者能夠最快通路資料。然後結合 API 能力， 讓前端開發小程式的時候，原先需要幾個星期幾個月，通過中台可以降到數天， 整個效率 提高非常多。這些都依賴于 MongoDB 資料庫非常強的整合能力和查詢能力，也是中台所 需要資料的特性。如下圖所示：
實時分析
場景的特點：
- 個性化、推薦系統、标簽等場景需要對所有使用者進行海量計算，效率很低且資料不實時。
- 采用實時分析可以針對性的分析，并且資料實時。
- 要求快速計算，秒級響應。
- 資料庫系統需能夠支撐大量資料，及快速資料聚合分析能力。
比如，晚上他會把全量的使用者行為資料整個跑一遍，結合其他的資料跑出一些個性化的 标簽，然後放到一個關系庫裡面。 第二天當你通路就會得到結果。
這種做法有缺陷，效率很低。因為活躍使用者比例很低，是以每天晚上都在跑 100%的用 戶，對計算資源的需求非常大，其中 90%的資料都是沒用的，因為很多使用者沒有登陸使用。 是以有些實時的場景推進系統，比如根據你第一個網頁點選的内容，給你推薦一些相關的信 息，這個時候就沒法做到了。
MongoDB 可以做快速的聚合性計算，做統計分析，得到這種結果，推薦相應的資訊。 另外如果給足夠的記憶體，也可以在記憶體裡面計算。MongoDB 選型考量:
- 使用 MongoDB 緩存機制，利用記憶體計算加速。
- 使用 MongoDB 聚合架構，實作統計分析功能。
- 使用 MongoDB 的靈活結構存儲中間結果。
- 滿足大多數簡單實時統計分析場景。
世界頂級航旅服務商：億級資料量實時分析
世界級的這種航旅服務商可以支撐世界上大部分的航空公司的票務查詢、訂票、選票、 票價計算等等場景。
每天要處理 16 億的預定等相關的請求與分析。所謂的分析就是要根據使用者查詢的目的 地、時間段，推薦比較合适的路線，或者相應的航旅産品酒店之類。如果想事先計算，100 多家航空公司的所有會員，使用者量太大，根本沒法計算。
另外一種場景，使用 MongoDB 實時計算能力，在幾十台實體機上部署了很多的微分 片，把資料打散在這些機器上，當有需求過來，可以通過并行機制，很快的把使用者的資料基 于 ID、目的地、時間段進行過濾，輸入的分析資料就比全量資料少了幾個數量級。通過 MongoDB 的實時資料分析能力，得出推薦的結果。
電商
電商場景的特點是：商品資訊特别多不好管理，因為不同的商品有非常不同的屬性，大 家去過淘寶京東就知道了，資訊是包羅萬象。資料庫模式設計困難，當并發通路量大的時候， 壓力也是非常大。
- 商品資訊包羅萬象。
- 商品的屬性不同品類差異很大。
- 資料庫模式設計困難。
- 并發通路量大，特别是促銷。
MongoDB 在電商場景下有非常獨特的優勢，JSON 動态模型，可以允許同一張商品 表裡面有不同的字段類型。比如同一張表可以有自行車、衣服、電腦，電腦可能是有 50 個 字段，自行車可能有 30 個字段，衣服可能有 20 個字段都沒問題。
- JSON 模型無需固定格式，可以記錄不同商品屬性。
- 可變模型适合疊代。
- 并發性能保證。
- 京東商城 / 小紅書 / 思科。
世界頂級網絡裝置生産商：電商平台重構
思科是一個做網絡裝置的公司，兩年前把基于 Oracle 的電商系統，整個遷移到了 MongoDB 上面，這是每年幾百億美元的流水,包括商品資訊、訂單、使用者互動。
遷移過來以後，14 個關系型表集合成 1 個集合，非常高效。 60 個索引優化到 7 個， 因為表的數量少了，效率增加了非常多。代碼量減少了 12 萬。之前的 3~5 秒頁面重新整理時間 降低了小于一秒，都是非常實際的價值呈現。
内容管理是部落格、營銷系統、内容管理系統，涉及到的都是非結構化、半結構化、多結 構化的資料管理。
- 内容資料多樣，文本，圖檔，視訊。
- 擴充困難，資料量爆發增長。
傳統資料庫隻能做結構化資料。當有文本、PDF、音頻、視訊需要統一管理，關系數 據庫就吃力了。MongoDB 的 JSON 可以支援各種結構的資料，甚至二進制的資料，文本、 日志更不在話下，它的分片結構可以支撐海量資料。
是以 Gartner 魔力象限裡面最頂上的兩位，Adobe AEM 和 Sitecore 兩個 CMS 文 檔管理系統的軟體，都是用的 MongoDB 來做資料管理和存儲。
- JSON 結構可以支援非結構化資料。
- 分片架構可以解決擴充問題。 Adobe AEM / Sitecore。
物聯網的場景特點是：
- 傳感器的資料結構往往是半結構化
- 傳感器數量很大，采集頻繁
- 資料量很容易增長到數億到百億
首先它有非常多的傳感器，每個傳感器都是不同廠家提供的，它并沒有标準的資料模型。 管理看上去是一個傳感器，但實際上它有非常不同的資料類型和屬性。這個時候有 JSON 模型就非常有優勢。
另外傳感器是機器資料，頻繁的時候可以每秒都一次，5 秒一次，甚至每 100 毫秒一 次，資料不斷的進到系統裡面。如果沒有能夠支撐高并發海量資料的系統，是無法支撐資料 庫的，資料很快就增長了百億、千億級
因為這個原因，類似于華為 / Bosch / Mindsphere 這些著名的物聯網平台，後面都 是采用 MongoDB。 MongoDB 選型考量總結：
- JSON 結構可以支援半結構化資料 使用分片能力支撐海量資料
- JSON 資料更加容易和其他系統通過 REST API 進行內建 華為 / Bosch / Mindsphere
MongoDB 什麼時候不太适用？
- MongoDB 模型設計不建議太多分表設計，關聯能力較弱。
- 傳統資料倉庫：建立各種次元表，然後使用大量關聯進行分析。
- 大型 ERP 軟體，一級資料對象數量較多（超過數十數百），必須依賴于各種關聯。
- 資料結構模型非常成熟固定，并且資料量不大，如财務系統。MongoDB 的彈性模型 和分布式沒有意義。 團隊沒有 MongoDB 能力，也沒有時間讓工程師學習新技術。
快速掌握MongoDB核心技術幹貨目錄
| 電子書下載下傳：《玩轉MongoDB從入門到實戰》 | https://developer.aliyun.com/article/780915 |
| 走進 MongoDB | https://developer.aliyun.com/article/781079 |
| MongoDB聚合架構 | https://developer.aliyun.com/article/781095 |
| 複制集使用及原理介紹 | https://developer.aliyun.com/article/781137 |
| 分片叢集使用及原理介紹 | https://developer.aliyun.com/article/781104 |
| ChangeStreams 使用及原理 | https://developer.aliyun.com/article/781107 |
| 事務功能使用及原理介紹 | https://developer.aliyun.com/article/781111 |
| MongoDB最佳實踐一 | https://developer.aliyun.com/article/781139 |
| MongoDB最佳實踐二 | https://developer.aliyun.com/article/781141 |