在雲棲社群上發起了乙個 mongodb 使用場景及運維管理問題交流**的技術話題，有近5000人關注了該話題討論，這裡就 mongodb 的使用場景做個簡單的總結，談談什麼場景該用 mongodb?
很多人比較關心 mongodb 的適用場景，也有使用者在話題裡分享了自己的業務場景，比如
案例1用在應用伺服器的日誌記錄，查詢起來比文字靈活，匯出也很方便。也是給應用練手，從外圍系統開始使用mongodb。
用在一些第三方資訊的獲取或者抓取，因為mongodb的schema-less，所有格式靈活，不用為了各種格式不一樣的資訊專門設計統一的格式，極大得減少開發的工作。
案例2mongodb之前有用過，主要用來儲存一些監控資料，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 儲存訂單資訊，訂單狀態在運送過程中會不斷更新，以 mongodb 內嵌陣列的形式來儲存，一次查詢就能將訂單所有的變更讀取出來。
物聯網場景，使用 mongodb 儲存所有接入的智慧型裝置資訊，以及裝置匯報的日誌資訊，並對這些資訊進行多維度的分析
……
應用不需要事務及複雜 join 支援
新應用，需求會變，資料模型無法確定，想快速迭代開發
應用需要2000-3000以上的讀寫qps（更高也可以）
應用需要tb甚至 pb 級別資料儲存
應用發展迅速，需要能快速水平擴充套件
應用要求儲存的資料不丟失
應用需要99.999%高可用
應用需要大量的地理位置查詢、文字查詢
mongodb適用和不適用的應用場景
近期考慮把訂單歷史資料從oracle資料庫遷移到nosql資料庫做歷史資料查詢和分析，一天千萬級資料。打算使用mongodb資料庫。使用nodejs做查詢和統計api，對併發請求量要求低，不知道有沒有前輩這樣玩過。我們如今僅僅用mongodo儲存日誌資料，做應用故障分析用。假設有前輩做個類似的歷史庫...
Hadoop學習筆記 哪些場景適用，哪些不適用。
hadoop不是萬能的，有些場景適用，有些不適用。hadoop設計的目的主要包括下面幾個方面，也就是所謂的適用場景 1 超大檔案 可以是幾百m，幾百t這個級別的檔案。2 流式資料訪問 hadoop適用於一次寫入，多次讀取的場景，也就是資料複製進去之後，長時間在這些資料上進行分析。3 商業硬體 也就是...
MongoDB的適用場景解析
很多人比較關心 mongodb 的適用場景，也有使用者在話題裡分享了自己的業務場景，比如 案例1用在應用伺服器的日誌記錄，查詢起來比文字靈活，匯出也很方便。也是給應用練手，從外圍系統開始使用mongodb。用在一些第三方資訊的獲取或者抓取，因為mongodb的schema less，所有格式靈活，不...