mongo資料庫本身就介於redis記憶體資料庫和mysql資料庫之間。

以下側重於mongo的優點。

mongo V redis，

1：redis受記憶體的限制，無法儲存海量的資料；mongo可以儲存海量的資料。

2：redis僅支援簡單的string、hash、list、set、zset資料結構，而mongo支援文件型的資料結構，可以說就是JSON字串，這種資料結構是多麼的靈活，使用是多麼的方便，想必不用過多介紹。

3：redis可以提供複雜的查詢嗎？mongo笑笑不語。

4：redis有內建資料分析功能(mapreduce)嗎？

再來看mongo V mysql

1：mongo的文件型資料結構，每一個文件可以對映為程式語言中的一個獨立物件，同一個集合的文件之間的資料結構完全不必相同，如此靈活的資料結構，可以輕鬆的適應業務邏輯變更。mysql這類的關係資料庫，怎麼比？

2：mongo的插入速度比MySQL更快。

3：mongo可以輕鬆的分散式擴充套件，不需要停機，不需要更改應用程式。

三者其實各有優缺點，對應不同的資料庫應用場景的。

什麼時候需要mongo？

不需要跨文件或跨表的事務，也不需要複雜的join查詢支援業務變更頻繁，導致資料結構需要頻繁更改需要大量的地理位置查詢，文字查詢海量資料儲存，且資料量快速增加

Mongo其實彌補了redis和mysql中的不足。個人在爬蟲中，經常採用mongo儲存爬取的資料，而redis儲存待爬取的連結和用於網頁去重。

mongodb的解決方案在幾乎所有情況下都不如nas…或者說nfs…說白話就是直接讀寫網路上的芳鄰的磁碟…

但只有一種情況例外…就是你不想讓開發者有權讀寫這個磁碟…mongodb的定位就是如此…僅此…

MongoDB 是一個基於分散式檔案儲存的資料庫，由 C++語言編寫。旨在為 WEB 應用提供可擴充套件的高效能資料儲存解決方案。

MongoDB 是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。它支援的資料結構非常鬆散，是類似 json 的 bson 格式，因此可以儲存比較複雜的資料型別。Mongo 最大的特點是它支援的查詢語言非常強大，其語法有點類似於面向物件的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。MongoDB 適用場景MongoDB 的主要目標是在鍵/值儲存方式（提供了高效能和高度伸縮性）和傳統的 RDBMS 系統（具有豐富的功能）之間架起一座橋樑，它集兩者的優勢於一身。Mongo 主要適用於以下場景：網站資料：Mongo 非常適合實時的插入，更新與查詢，並具備網站實時資料儲存所需的複製及高度伸縮性。快取：由於效能很高，Mongo 也適合作為資訊基礎設施的快取層。在系統重啟之後， 由 Mongo 搭建的持久化快取層可以避免下層的資料來源過載。大尺寸、低價值的資料：使用傳統的關係型資料庫儲存一些資料時可能會比較昂貴，在此之前，很多時候程式設計師往往會選擇傳統的檔案進行儲存。高伸縮性的場景：Mongo 非常適合由數十或數百臺伺服器組成的資料庫，Mongo 的路線圖中已經包含對 MapReduce 引擎的內建支援。用於物件及 JSON 資料的儲存：Mongo 的 BSON 資料格式非常適合文件化格式的儲存及查詢。MongoDB 的使用也會有一些限制，它不適合於以下幾個地方：高度事務性的系統：例如，銀行或會計系統。傳統的關係型資料庫目前還是更適用於需要大量原子性複雜事務的應用程式。傳統的商業智慧應用：針對特定問題的 BI 資料庫會產生高度最佳化的查詢方式。對於此類應用，資料倉庫可能是更合適的選擇。需要 SQL 的問題。MongoDB 原理MongoDB 復（副）本集與分片：

每個復（副）本集中儲存的資料是相同的，相當於主備方式的資料冗餘，目的是為了容災。分片是為了資料的拓展，按照片鍵進行結點劃分，資料根據片鍵儲存到對應的伺服器上。

2.MongoDB 部署方案

MongoDB 的叢集部署方案中有三類角色：實際資料儲存結點（Shared Sever）、配置檔案儲存結點（Config Sever）和路由接入結點（Route Server）。客戶端直接與路由結點相連，從配置結點上查詢資料，根據查詢結果到實際的儲存結點上查詢和儲存資料。MongoDB 讀寫資料的流程如圖：寫入資料時，先由客戶端訪問路由結點，向配置結點獲取相關資訊後，將資料寫入儲存結點。讀取資料時，由客戶端訪問路由結點，向配置結點獲取相關資訊後，對儲存結點進行訪問， 獲取到相應資料，再經由路由結點將資料返回至客戶端。對於複本集，又有主和從兩種角色，寫資料和讀資料也是不同，寫資料的過程是隻寫到主結點中，由主結點以非同步的方式同步到從結點中。而讀資料則只要從任一結點中讀取，具體到哪個結點讀取是可以指定的。對於 MongoDB 的分片，假設我們以某一索引鍵（ID）為片鍵，ID 的區間[0,50），劃分成 5 個chunk，分別儲存到 3 個片伺服器中，可以進行如下分片：當資料量很大，需要增加片伺服器時，只需移動 chunk 來均分資料即可。配置結點：儲存配置檔案的伺服器其實儲存的是片鍵與 chunk 以及 chunk 與 server 的對映關係。路由結點：路由角色的結點在分片的情況下起到負載均衡的作用。MongoDB 和 MySQL 的區別MySQL 是關係型資料庫優點：在不同的引擎上有不同的儲存方式。查詢語句是傳統的 SQL 語句，擁有成熟的體系，成熟度很高。缺點：在處理海量資料時，效率會顯著變慢。2、MongoDB 介於關係資料庫和非關係資料庫之間，面向集合的、模式自由的文件型資料庫。多個鍵值對有序地放置在一起即是文件，文件是 MongoDB 中資料的基本單元，類似關係資料庫的行。MongoDB 中的查詢語法是獨特的，有點類似 Javascript 面向物件的查詢語言。儲存方式：虛擬記憶體+持久化。查詢語句：獨特的 MongoDB 的查詢方式。架構特點：可以透過副本集，以及分片來實現高可用。資料處理：資料儲存在硬碟上，需要經常讀取的資料(熱資料)會被載入到物理記憶體中，從而達到高速讀寫的效果。成熟度與廣泛度：新興資料庫，成熟度較低，Nosql 資料庫中最為接近關係型資料庫，比較完善的資料庫之一，適用人群不斷增長。優點：讀寫速度快。在適量級的記憶體的 MongoDB 的速度是十分快速的，透過將熱資料儲存在物理記憶體中，使得熱資料的讀寫變得十分快速。高擴充套件性。儲存的資料格式是類似 json 的 bson 格式。缺點：

不支援事務。

3、MongoDB 與 MySQL 命令對比

傳統的關係資料庫一般由資料庫（database）、表（table）、記錄（record）三個層次概念組成，MongoDB 是由資料庫（database）、集合（collection）、文件物件（document）三個層次組成。MongoDB 對於關係型資料庫裡的表，但是集合中不包括列、行和關係概念，這體現了模式自由的特點。MongoDB 備份方式檔案快照備份檔案快照備份基於作業系統，透過 Linux 的 LVM 特性對 MongoDB 資料檔案所在的裝置進行備份。正是由於這種備份方式使用作業系統級別的工具，故而兼備了高可靠性和高效率。不過這樣也導致了宿主環境必須要給予支援。檔案快照備份的特點：優點：支援時間點高可靠性、高效率增量備份缺點：需要作業系統支援需要開啟日誌功能，否則無法保證資料的有效性和一致性其他：可以獲取分片叢集的一致快照，需要關閉叢集均衡器並在大致相同的時刻從叢集的每個分片和配置伺服器上抓取快照。沒有開啟日誌功能時，備份前需要完全完成寫操作，備份過程中將停止任何寫操作(MMAPv1)。開啟日誌功能後，在快照時 MMAPv1 無需停止寫操作達到一致狀態，Wired Tiger 透過最後的檢查點達到一致狀態（檢查點為每 2G 資料或每分鐘一次）。檔案快照建立的是整個磁碟的映象，所以把資料檔案、配置、日誌放在一個邏輯磁碟上會節約空間。2、mongodump 備份/mongorestore 恢復執行 mongodump 命令讀取 MongoDB 資料庫，可以生成一個備份檔案，該備份檔案格式為BJSON，執行 mongorestore 命令可以透過讀取該備份檔案將 MongoDB 資料庫恢復。使用這種方式進行備份時，對於小型的 MongoDB 叢集而言，佔用空間更少，也更高效；但是對於大型的 MongoDB 叢集，效率則不是很高。在備份的過程中，可以繼續修改資料，會記錄與 oplog 中；備份的資料也不包括本地資料庫、索引，故而恢復資料庫時必須重建索引；此外備份還會產生網路流量，影響當前mongod 效能。一旦備份資料超過系統記憶體，查詢操作就會產生錯誤。執行備份時一定要有對應的訪問控制權限。mongodump 不同版本之間不能互相相容，無法使用較新的版本備份老資料。