MongoDB 應用場景?

01-15

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絕不會後悔。

em, 無意發現，優酷公司用它來存儲評論信息

我供職的公司使用它構建垂直小型電子商務平台持久層

其他案例歡迎補充

感覺除了銀行，高並發的交易等大型系統需要傳統 rdbms 的事務支持

總之如果你需要高性能的存儲服務，那麼推薦 MongoDB，

比如用於存儲大型網站的用戶個人信息，sns 數據
比如用於構建在其它存儲層之上的Cache層。
...

地理搜索、零散文件、對事務無要求的數據。正在用它替代mysql

關於MongoDB的使用場景，曾經寫過一篇介紹的文章，詳細請移步什麼場景應該用 MongoDB ？，使用場景主要由其核心3大特性決定，靈活文檔模型 + 高可用複製集 + 可擴展分片集群

手頭正好有一個場景很適合。

在設計一個問卷系統，需要支持多個問卷，不同題型，產生的數據按題型分散存在mysql的多個表（不同的題型需要不同的表來存儲選項和回答，總共用了十幾張表。）

將用戶回答數據導出成excel時，需要對十幾個表進行操作，生成excel效率非常的慢。如果用非同步下載的話，除了會帶來數據及時性的問題外，還無法滿足個性化下載的需求。

索性就單獨用表來存儲問卷結果。由於每份問卷的內容不同，需要每份問卷都建一個表來存放數據。

如果採用mysql資料庫存放，會導致表數量隨著問卷的增加而增加，感覺並不是特別好。如果用mongodb來存的話，就很合適了，完全可以把mongodb當成一個文件夾來用，不用擔心凌亂無序的問題。

這個解決方案有點為了用而用，但從效果來看還是不錯的。如果有更好的方案，希望各位大佬不吝賜教。

沒有事務型要求的資料庫都可以用Mongo,但實際上很多應用資料庫幾乎沒有不要求事務的。

能用RDBMS的還是盡量用RDBMS。反正我司的mongo讓我是用吐了

大數據，模擬關係型資料庫，不固定的欄位，lbs

【問題描述】

當前版本Ceilometer模塊採用的後端存儲為Mongodb(一種Nosql的文檔資料庫)。

Mongodb有多種部署形態具體使用那種部署形態。

MasterSlave Replication（主備單活）
- 當前mongodb的官網已明確不推薦使用此模式
- 優點：簡潔
- 缺點：可靠性和及其讀寫性能較差
- 備註：之前公司使用此模式昨晚小場景的poc演示使用
ReplicaSet（集群模式）
- 一主兩備

只有primary(主)節點可以進行寫操作，即只有主節點可以接受客戶端driver的寫請求。然後oplog功能再非同步將數據拷貝至各個備節點。各個備節點可水平擴展。各個備節可開啟讀取功能（默認關閉）主節點故障後，集群會從備節點選舉出新的主節點。如下圖：

優點：較於有仲裁節點的情況，多了一個備節點，可以多一份文檔備份，增加了可靠性。
缺點：小概率情況下，主節點掛掉後，各備節點公平競爭導致選舉失敗，從而似的集群無可寫節點。
備註：之前公司採用此種模式

一主一備一仲裁(**當前版本採用的模式**)

節點個數為偶數時，受限於選舉演算法，為增加選舉的可靠性，指導文檔建議增加一個仲裁節點，見上圖。優點：增加了主節點掛掉後的選舉成功的可靠性。缺點：當前模式下浪費了一個節點（192.168.1.43）備註：當前模式下沒有開啟備節點的讀取功能，建議打開。已驗證：（1）往主節點插入數據，能從備節點查到之前插入的數據（2）停掉主節點，備節點能變成主節點提供服務。（3）恢復主節點，備節點也能恢復其備的角色，而不是繼續充當主的角色

Sharding （分片模式）

主要應對大數據量及其高吞吐（highthroughput）場景，此模式下mongodb提供的自動分片功能。
優點：在上述場景下會一定程度改善mogodb的性能問題
缺點：數據量不大的情況下，性能較集群模式差。