什么場景應該用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 就越合適。
| 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 絕不會后悔。
