什麼場景應該用 MongoDB ?

2021-09-23 17:56:01 字數 1797 閱讀 9189

月初在雲棲社群上發起了乙個 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 就越合適。

mongodb 特性

優勢事務支援

mongodb 目前只支援單文件事務,需要複雜事務支援的場景暫時不適合

靈活的文件模型

json 格式儲存最接近真實物件模型,對開發者友好,方便快速開發迭代

高可用複製集

滿足資料高可靠、服務高可用的需求,運維簡單,故障自動切換

可擴充套件分片集群

海量資料儲存,服務能力水平擴充套件

高效能mmapv1、wiredtiger、mongorocks(rocksdb)、in-memory 等多引擎支援滿足各種場景需求

強大的索引支援

地理位置索引可用於構建 各種 o2o 應用、文字索引解決搜尋的需求、ttl索引解決歷史資料自動過期的需求

gridfs

解決檔案儲存的需求

aggregation & mapreduce

解決資料分析場景需求,使用者可以自己寫查詢語句或指令碼,將請求都分發到 mongodb 上完成

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

應用特徵

yes / no

應用不需要事務及複雜 join 支援

必須 yes

新應用,需求會變,資料模型無法確定,想快速迭代開發

?應用需要2000-3000以上的讀寫qps(更高也可以)

?應用需要tb甚至 pb 級別資料儲存

?應用發展迅速,需要能快速水平擴充套件

?應用要求儲存的資料不丟失

?應用需要99.999%高可用

?應用需要大量的地理位置查詢、文字查詢

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

什麼場景應該用 MongoDB ?

很多人比較關心 mongodb 的適用場景,也有使用者在話題裡分享了自己的業務場景,比如 案例1 1.用在應用伺服器的日誌記錄,查詢起來比文字靈活,匯出也很方便。也是給應用練手,從外圍系統開始使用mongodb。2.用在一些第三方資訊的獲取或者抓取,因為mongodb的schema less,所有格...

什麼場景應該用 MongoDB ?

案例1 1.用在應用伺服器的日誌記錄,查詢起來比文字靈活,匯出也很方便。2.用在一些第三方資訊的獲取或者抓取,因為mongodb的schema less,所有格式靈活,不用為了各種格式不一樣的資訊專門設計統一的格式,極大得減少開發的工作。案例2 主要用來儲存一些監控資料,no schema 對開發人...

什麼場景應該用 MongoDB

月初在雲棲社群上發起了乙個 mongodb 使用場景及運維管理問題交流 的技術話題,有近5000人關注了該話題討論,這裡就 mongodb 的使用場景做個簡單的總結,談談什麼場景該用 mongodb?很多人比較關心 mongodb 的適用場景,也有使用者在話題裡分享了自己的業務場景,比如 案例1 1...