什麼場景應該用 MongoDB ?
月初在雲棲社群上發起了一個 MongoDB 使用場景及運維管理問題交流探討 的技術話題,有近5000人關注了該話題討論,這裡就 MongoDB 的使用場景做個簡單的總結,談談什麼場景該用 MongoDB?
很多人比較關心 MongoDB 的適用場景,也有使用者在話題裡分享了自己的業務場景,比如
案例1
-
用在應用伺服器的日誌記錄,查詢起來比文字靈活,匯出也很方便。也是給應用練手,從外圍系統開始使用MongoDB。
-
用在一些第三方資訊的獲取或者抓取,因為MongoDB的schema-less,所有格式靈活,不用為了各種格式不一樣的資訊專門設計統一的格式,極大得減少開發的工作。
案例2
-
mongodb之前有用過,主要用來儲存一些監控資料,No schema 對開發人員來說,真的很方便,增加欄位不用改表結構,而且學習成本極低。
案例3
-
使用MongoDB做了O2O快遞應用,·將送快遞騎手、快遞商家的資訊(包含位置資訊)儲存在 MongoDB,然後通過 MongoDB 的地理位置查詢,這樣很方便的實現了查詢附近的商家、騎手等功能,使得快遞騎手能就近接單,目前在使用MongoDB 上沒遇到啥大的問題,官網的文件比較詳細,很給力。
經常跟一些同學討論 MongoDB 業務場景時,會聽到類似『你這個場景 mysql 也能解決,沒必要一定用 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 絕不會後悔。