哪些場景下使用MongoDB
為什麼需要MongoDB
MongoDB與MySQL的區別
關於MongoDB與MySQL的區別可以參考網上關於NoSQL與MySQL的區別，以下是找到的網上的關於兩者區別的截圖：
總體上講：
由於MongoDB獨特的資料處理方式，可以將熱點資料載入到記憶體，故而對查詢來講，會非常快（當然也會非常消耗記憶體）；同時由於採用了BSON的方式儲存資料，故而對JSON格式資料具有非常好的支援性以及友好的表結構修改性，文件式的儲存方式，資料友好可見；資料庫的分片叢集負載具有非常好的擴充套件性以及非常不錯的自動故障轉移（大讚）。
不足：資料庫的查詢採用了特有的查詢方式，有一定的學習成本（不高）；索引不咋滴；鎖只能提供到collection級別，還做不到行級鎖；沒有事務機制（不能回滾啊）；學習資料肯定沒有MySQL的多。
MongoDB與Hadoop的區別
MongoDB側重於對資料進行操作的應用系統，而Hadoop則側重於對資料進行分析統計的應用。
MongoDB能夠滿足對資料庫讀寫效能具有極高要求的應用場景（很消耗memory的），一般這些應用的響應延遲會要求控制在10ms以下，甚至更低。而Hadoop由於每一次的讀寫操作會包含大量資料（Hadoop更適合少次操作大批量資料的場景），通過聚集分析處理大量資料，這種分析一般都會走MapReduce，會造成很高的延遲（數分鐘到數小時不等）
不適合MongoDB的場景
如果業務中存在大量複雜的事務邏輯操作，則不要用MongoDB資料庫
一般來講，我會將MySQL中的部分表遷移到MongoDB中，主要是涉及到車輛歷史軌跡以及溫溼度資料等機器採集到的資料，而訂單資料、客戶資料等資訊，仍然放到MySQL資料庫中，主要是因為這兩類資料實時採集，實時更新，會隨著時間的推移，專案的擴大（PAAS服務），造成非常巨大的資料量，而一般MySQL在單表資料量超過500萬後，效能就會下降的比較快，雖然可以通過分表的方式進行處理，但是隨著時間的增長，仍然會給我帶來比較大的麻煩（如查詢等），這樣，就不如將其放到MongoDB中儲存，查詢什麼的都會比較方便，不過需要注意根據片鍵分片哦。
在開發過程中遇到問題如何求助
常見的問題一般都可以在網上找到答案。
可以百度搜索如https://segmentfault.com/t/mongodb，github之類的網站查詢對應的問題
參考連結
mongodb與關係型資料庫相比的優缺點
與關係型資料庫相比，MongoDB的優點：
①弱一致性（最終一致），更能保證使用者的訪問速度：
舉例來說，在傳統的關係型資料庫中，一個COUNT型別的操作會鎖定資料集，這樣可以保證得到“當前”情況下的較精確值。這在某些情況下，例 如通過ATM檢視賬戶資訊的時候很重要，但對於Wordnik來說，資料是不斷更新和增長的，這種“較精確”的保證幾乎沒有任何意義，反而會產生很大的延 遲。他們需要的是一個“大約”的數字以及更快的處理速度。
但某些情況下MongoDB會鎖住資料庫。如果此時正有數百個請求，則它們會堆積起來，造成許多問題。我們使用了下面的優化方式來避免鎖定：
每次更新前，我們會先查詢記錄。查詢操作會將物件放入記憶體，於是更新則會盡可能的迅速。在主/從部署方案中，從節點可以使用“-pretouch”引數執行，這也可以得到相同的效果。
使用多個mongod程序。我們根據訪問模式將資料庫拆分成多個程序。
②文件結構的儲存方式，能夠更便捷的獲取資料。
對於一個層級式的資料結構來說，如果要將這樣的資料使用扁平式的，表狀的結構來儲存資料，這無論是在查詢還是獲取資料時都十分困難。
③內建GridFS，支援大容量的儲存。
GridFS是一個出色的分散式檔案系統，可以支援海量的資料儲存。
內建了GridFS了MongoDB，能夠滿足對大資料集的快速範圍查詢。
④內建Sharding。
提供基於Range的Auto Sharding機制：一個collection可按照記錄的範圍，分成若干個段，切分到不同的Shard上。
Shards可以和複製結合，配合Replica sets能夠實現Sharding+fail-over，不同的Shard之間可以負載均衡。查詢是對 客戶端是透明的。客戶端執行查詢，統計，MapReduce等操作，這些會被MongoDB自動路由到後端的資料節點。這讓我們關注於自己的業務，適當的 時候可以無痛的升級。MongoDB的Sharding設計能力較大可支援約20 petabytes，足以支撐一般應用。
這可以保證MongoDB執行在便宜的PC伺服器叢集上。PC叢集擴充起來非常方便並且成本很低，避免了“sharding”操作的複雜性和成本。
⑤第三方支援豐富。(這是與其他的NoSQL相比，MongoDB也具有的優勢)
現在網路上的很多NoSQL開源資料庫完全屬於社群型的，沒有官方支援，給使用者帶來了很大的風險。
而開源文件資料庫MongoDB背後有商業公司10gen為其提供供商業培訓和支援。
而且MongoDB社群非常活躍，很多開發框架都迅速提供了對MongDB的支援。不少知名大公司和網站也在生產環境中使用MongoDB，越來越多的創新型企業轉而使用MongoDB作為和Django，RoR來搭配的技術方案。
⑥效能優越：
在使用場合下，千萬級別的文件物件，近10G的資料，對有索引的ID的查詢不會比mysql慢，而對非索引欄位的查詢，則是全面勝出。 mysql實際無法勝任大資料量下任意欄位的查詢，而mongodb的查詢效能實在讓我驚訝。寫入效能同樣很令人滿意，同樣寫入百萬級別的數 據，mongodb比我以前試用過的couchdb要快得多，基本10分鐘以下可以解決。補上一句，觀察過程中mongodb都遠算不上是CPU殺手。
與關係型資料庫相比，MongoDB的缺點：
①mongodb不支援事務操作。
所以事務要求嚴格的系統（如果銀行系統）肯定不能用它。(這點和優點①是對應的)
②mongodb佔用空間過大。
關於其原因，在官方的FAQ中，提到有如下幾個方面：
1、空間的預分配：為避免形成過多的硬碟碎片，mongodb每次空間不足時都會申請生成一大塊的硬碟空間，而且申請的量從64M、128M、256M那 樣的指數遞增，直到2G為單個檔案的較大體積。隨著資料量的增加，你可以在其資料目錄裡看到這些整塊生成容量不斷遞增的檔案。
2、欄位名所佔用的空間：為了保持每個記錄內的結構資訊用於查詢，mongodb需要把每個欄位的key-value都以BSON的形式儲存，如果 value域相對於key域並不大，比如存放數值型的資料，則資料的overhead是較大的。一種減少空間佔用的方法是把欄位名儘量取短一些，這樣佔用 空間就小了，但這就要求在易讀性與空間佔用上作為權衡了。我曾建議作者把欄位名作個index，每個欄位名用一個位元組表示，這樣就不用擔心欄位名取多長 了。但作者的擔憂也不無道理，這種索引方式需要每次查詢得到結果後把索引值跟原值作一個替換，再發送到客戶端，這個替換也是挺耗費時間的。現在的實現算是 拿空間來換取時間吧。
3、刪除記錄不釋放空間：這很容易理解，為避免記錄刪除後的資料的大規模挪動，原記錄空間不刪除，只標記“已刪除”即可，以後還可以重複利用。
4、可以定期執行db.repairDatabase()來整理記錄，但這個過程會比較緩慢
③MongoDB沒有如MySQL那樣成熟的維護工具，這對於開發和IT運營都是個值得注意的地方。
MongoDB適合儲存一些關係簡單、資料量又很大的資料，比如我們的平臺上虛擬機器的監控資訊，包括記憶體、IO、CPU、網路等資料，每隔幾秒就採集一次資料，每週、每月，量很大，而且舊的監控資料也不會保留太長時間，就使用的mongodb來儲存這些資料；
另外mongodb的叢集部署相對比較簡單，易於擴充套件；比如主從複製，在mongo.conf配置幾個引數就OK了；分片叢集的配置也比較簡單。還支援使用命令列來進行動態地新增和刪除節點；
Mongodb的優點與不足
（1）Mongodb的不足之處
1、在叢集分片中的資料分佈不均勻
2、單機可靠性比較差
3、大資料量持續插入，寫入效能有較大波動
4、磁碟空間佔用比較大
（2）Mongodb的過人之處
1、無模式
2、查詢與索引方式靈活，是最像SQL的Nosql
3、支援複製集、主備、互為主備、自動分片等特性
Mongodb與redis相比較：
mongoDB 原始碼語言是C++,redis也是C或C++,
mongodb 檔案儲存是BSON格式類似JSON，或自定義的二進位制格式。
mongodb與redis效能都很依賴記憶體的大小，mongodb 有豐富的資料表達、索引；最類似於關係資料庫，支援豐富的查詢語言，redis資料豐富，較少的IO ，這方面mongodb優勢明顯。
mongodb不支援事物，靠客戶端自身保證，redis支援事物，比較弱，僅能保證事物中的操作按順序執行，這方面 redis優於mongodb。
mongodb對海量資料的訪問效率提升，redis 較小資料量的效能及運算,這方面 mongodb效能優於redis .monbgodb 有mapredurce功能，提供資料分析，redis 沒有 ，這方面 mongodb優於redis 。