原文地址：http://www.mongoing.com/archives/3609
使用案列
-
案例1
- 用在應用伺服器的日誌記錄，查詢起來比文字靈活，匯出也很方便。也是給應用練手，從外圍系統開始使用MongoDB。
- 用在一些第三方資訊的獲取或者抓取，因為MongoDB的schema-less，所有格式靈活，不用為了各種格式不一樣的資訊專門設計統一的格式，極大得減少開發的工作。
-
案例2
MongoDB之前有用過，主要用來儲存一些監控資料，No schema 對開發人員來說，真的很方便，增加欄位不用改表結構，而且學習成本極低。
-
案例3
使用MongoDB做了O2O快遞應用，將送快遞騎手、快遞商家的資訊（包含位置資訊）儲存在MongoDB，然後通過 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，不如來做幾個選擇題來輔助決策（注：以下內容改編自MongoDB公司TJ同學的某次公開技術分享）。
| 應用特徵 | YES / NO |
|---|---|
| 應用不需要事務及複雜 join 支援 | 必須 Yes |
| 新應用，需求會變，資料模型無法確定，想快速迭代開發 | ？ |
| 應用需要2000-3000以上的讀寫QPS（更高也可以） | ？ |
| 應用需要TB甚至 PB 級別資料儲存 | ? |
| 應用發展迅速，需要能快速水平擴充套件 | ? |
| 應用要求儲存的資料不丟失 | ? |
| 應用需要99.999%高可用 | ? |
| 應用需要大量的地理位置查詢、文字查詢 | ？ |
如果上述有1個 Yes，可以考慮 MongoDB，2個及以上的 Yes，選擇 MongoDB 絕不會後悔。
如果讀完覺得有收穫的話，歡迎點贊、關注、加公眾號【牛覓技術】，查閱更多精彩歷史！！！：
