什麼場景應該用MongoDB ？

原文地址：http://www.mongoing.com/archives/3609

使用案列

• 案例1

  1. 用在應用服務器的日誌記錄，查找起來比文本靈活，導出也很方便。也是給應用練手，從外圍系統開始使用MongoDB。
  2. 用在一些第三方信息的獲取或者抓取，由於MongoDB的schema-less，全部格式靈活，不用爲了各類格式不同的信息專門設計統一的格式，極大得減小開發的工做。

• 案例2

  MongoDB以前有用過，主要用來存儲一些監控數據，No schema 對開發人員來講，真的很方便，增長字段不用改表結構，並且學習成本極低。

• 案例3

  使用MongoDB作了O2O快遞應用，將送快遞騎手、快遞商家的信息（包含位置信息）存儲在MongoDB，而後經過 MongoDB的地理位置查詢，這樣很方便的實現了查找附近的商家、騎手等功能，使得快遞騎手能就近接單，目前在使用MongoDB上沒遇到啥大的問題，官網的文檔比較詳細，很給力。

MongoDB特性

常常跟一些同窗討論MongoDB業務場景時，會聽到相似【你這個場景 mysql 也能解決，不必必定用 MongoDB】的聲音，的確，並無某個業務場景必需要使用 MongoDB才能解決，但使用 MongoDB 一般能讓你以更低的成本解決問題（包括學習、開發、運維等成本），下面是 MongoDB 的主要特性，你們能夠對照本身的業務需求看看，匹配的越多，用 MongoDB 就越合適。

MONGODB 特性	優點
事務支持	MongoDB 目前只支持單文檔事務，須要復瑣事務支持的場景暫時不適合。
靈活的文檔模型	JSON 格式存儲最接近真實對象模型，對開發者友好，方便快速開發迭代。
高可用複製集	知足數據高可靠、服務高可用的需求，運維簡單，故障自動切換。
可擴展分片集羣	海量數據存儲，服務能力水平擴展。
高性能	mmapv一、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 毫不會後悔。

---

若是讀完以爲有收穫的話，歡迎點贊、關注、加公衆號【牛覓技術】，查閱更多精彩歷史！！！：