月初在雲棲社群上發起了乙個 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...