1. 程式人生 > >什麼場景應該用 MongoDB ?

什麼場景應該用 MongoDB ?

月初在雲棲社群上發起了一個 MongoDB 使用場景及運維管理問題交流探討 的技術話題,有近5000人關注了該話題討論,這裡就 MongoDB 的使用場景做個簡單的總結,談談什麼場景該用 MongoDB?

很多人比較關心 MongoDB 的適用場景,也有使用者在話題裡分享了自己的業務場景,比如

案例1

  1. 用在應用伺服器的日誌記錄,查詢起來比文字靈活,匯出也很方便。也是給應用練手,從外圍系統開始使用MongoDB。

  2. 用在一些第三方資訊的獲取或者抓取,因為MongoDB的schema-less,所有格式靈活,不用為了各種格式不一樣的資訊專門設計統一的格式,極大得減少開發的工作。

案例2

  1. mongodb之前有用過,主要用來儲存一些監控資料,No schema 對開發人員來說,真的很方便,增加欄位不用改表結構,而且學習成本極低。

案例3

  1. 使用MongoDB做了O2O快遞應用,·將送快遞騎手、快遞商家的資訊(包含位置資訊)儲存在 MongoDB,然後通過 MongoDB 的地理位置查詢,這樣很方便的實現了查詢附近的商家、騎手等功能,使得快遞騎手能就近接單,目前在使用MongoDB 上沒遇到啥大的問題,官網的文件比較詳細,很給力。

經常跟一些同學討論 MongoDB 業務場景時,會聽到類似『你這個場景 mysql 也能解決,沒必要一定用 MongoDB』的聲音,的確,並沒有某個業務場景必須要使用 MongoDB才能解決,但使用 MongoDB 通常能讓你以更低的成本解決問題(包括學習、開發、運維等成本)

,下面是 MongoDB 的主要特性,大家可以對照自己的業務需求看看,匹配的越多,用 MongoDB 就越合適。

MONGODB 特性 優勢
事務支援 MongoDB 目前只支援單文件事務,需要複雜事務支援的場景暫時不適合
靈活的文件模型 JSON 格式儲存最接近真實物件模型,對開發者友好,方便快速開發迭代
高可用複製集 滿足資料高可靠、服務高可用的需求,運維簡單,故障自動切換
可擴充套件分片叢集 海量資料儲存,服務能力水平擴充套件
高效能 mmapv1、wiredtiger、mongorocks(rocksdb)、in-memory 等多引擎支援滿足各種場景需求
強大的索引支援 地理位置索引可用於構建 各種 O2O 應用、文字索引解決搜尋的需求、TTL索引解決歷史資料自動過期的需求
Gridfs 解決檔案儲存的需求
aggregation & mapreduce 解決資料分析場景需求,使用者可以自己寫查詢語句或指令碼,將請求都分發到 MongoDB 上完成

從目前阿里雲 MongoDB 雲資料庫上的使用者看,MongoDB 的應用已經滲透到各個領域,比如遊戲、物流、電商、內容管理、社交、物聯網、視訊直播等,以下是幾個實際的應用案例。

  • 遊戲場景,使用 MongoDB 儲存遊戲使用者資訊,使用者的裝備、積分等直接以內嵌文件的形式儲存,方便查詢、更新

  • 物流場景,使用 MongoDB 儲存訂單資訊,訂單狀態在運送過程中會不斷更新,以 MongoDB 內嵌陣列的形式來儲存,一次查詢就能將訂單所有的變更讀取出來。

  • 社交場景,使用 MongoDB 儲存儲存使用者資訊,以及使用者發表的朋友圈資訊,通過地理位置索引實現附近的人、地點等功能

  • 物聯網場景,使用 MongoDB 儲存所有接入的智慧裝置資訊,以及裝置彙報的日誌資訊,並對這些資訊進行多維度的分析

  • 視訊直播,使用 MongoDB 儲存使用者資訊、禮物資訊等

  • ……

如果你還在為是否應該使用 MongoDB,不如來做幾個選擇題來輔助決策(注:以下內容改編自 MongoDB 公司 TJ 同學的某次公開技術分享)。

應用特徵 YES / NO
應用不需要事務及複雜 join 支援 必須 Yes
新應用,需求會變,資料模型無法確定,想快速迭代開發
應用需要2000-3000以上的讀寫QPS(更高也可以)
應用需要TB甚至 PB 級別資料儲存 ?
應用發展迅速,需要能快速水平擴充套件 ?
應用要求儲存的資料不丟失 ?
應用需要99.999%高可用 ?
應用需要大量的地理位置查詢、文字查詢

如果上述有1個 Yes,可以考慮 MongoDB,2個及以上的 Yes,選擇 MongoDB 絕不會後悔。