MongoDB 與傳統關係型數據庫mysql比較

①弱一致性（最終一致），更能保證用戶的訪問速度：
舉例來講，在傳統的關係型數據庫中，一個COUNT類型的操做會鎖定數據集，這樣能夠保證獲得「當前」狀況下的精確值。這在某些狀況下，例 如經過ATM查看帳戶信息的時候很重要，但對於Wordnik來講，數據是不斷更新和增加的，這種「精確」的保證幾乎沒有任何意義，反而會產生很大的延 遲。他們須要的是一個「大約」的數字以及更快的處理速度。

但某些狀況下MongoDB會鎖住數據庫。若是此時正有數百個請求，則它們會堆積起來，形成許多問題。咱們使用了下面的優化方式來避免鎖定：
每次更新前，咱們會先查詢記錄。查詢操做會將對象放入內存，因而更新則會盡量的迅速。在主/從部署方案中，從節點可使用「-pretouch」參數運行，這也能夠獲得相同的效果。 
使用多個mongod進程。咱們根據訪問模式將數據庫拆分紅多個進程。 
②文檔結構的存儲方式，可以更便捷的獲取數據。
對於一個層級式的數據結構來講，若是要將這樣的數據使用扁平式的，表狀的結構來保存數據，這不管是在查詢仍是獲取數據時都十分困難。
舉例1：
就拿一個「字典項」來講，雖然並不十分複雜，但仍是會關係到「定義」、「詞性」、「發音」或是「引用」等內容。大部分工程師會將這種模型使用關係型數據庫 中的主鍵和外鍵表現出來，但把它看做一個「文檔」而不是「一系列有關係的表」豈不更好？使用 「dictionary.definition.partOfSpeech='noun'」來查詢也比表之間一系列複雜（每每代價也很高）的鏈接查詢方便 且快速。

舉例2：在一個關係型數據庫中，一篇博客（包含文章內容、評論、評論的投票）會被打散在多張數據表中。在MongoDB中，能用一個文檔來表示一篇博客， 評論與投票做爲文檔數組，放在正文主文檔中。這樣數據更易於管理，消除了傳統關係型數據庫中影響性能和水平擴展性的「JOIN」操做。

CODE↓

> db.blogposts.save({ title : "My First Post", author: {name : "Jane", id :1},
  comments : [{ by: "Abe", text: "First" },
              { by : "Ada", text : "Good post" }]
})

> db.blogposts.find( { "author.name" : "Jane" } )

> db.blogposts.findOne({ title : "My First Post", "author.name": "Jane",
  comments : [{ by: "Abe", text: "First" },
              { by : "Ada", text : "Good post" } ]
})
> db.blogposts.find( { "comments.by" : "Ada" } )

> db.blogposts.ensureIndex( { "comments.by" : 1 } );

 

舉例③：
MongoDB是一個面向文檔的數據庫，目前由10gen開發並維護，它的功能豐富，齊全，徹底能夠替代MySQL。在使用MongoDB作產品原型的過程當中，咱們總結了MonogDB的一些亮點：
使用JSON風格語法，易於掌握和理解：MongoDB使用JSON的變種BSON做爲內部存儲的格式和語法。針對MongoDB的操做都使用JSON風格語法，客戶端提交或接收的數據都使用JSON形式來展示。相對於SQL來講，更加直觀，容易理解和掌握。
Schema-less，支持嵌入子文檔：MongoDB是一個Schema-free的文檔數據庫。一個數據庫能夠有多個Collection，每 個Collection是Documents的集合。Collection和Document和傳統數據庫的Table和Row並不對等。無需事先定義 Collection，隨時能夠建立。
Collection中能夠包含具備不一樣schema的文檔記錄。 這意味着，你上一條記錄中的文檔有3個屬性，而下一條記錄的文檔能夠有10個屬 性，屬性的類型既能夠是基本的數據類型（如數字、字符串、日期等），也能夠是數組或者散列，甚至還能夠是一個子文檔（embed document）。這 樣，能夠實現逆規範化（denormalizing）的數據模型，提升查詢的速度。

 

③內置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中，提到有以下幾個方面：
一、空間的預分配：爲避免造成過多的硬盤碎片，mongodb每次空間不足時都會申請生成一大塊的硬盤空間，並且申請的量從64M、128M、256M那 樣的指數遞增，直到2G爲單個文件的最大致積。隨着數據量的增長，你能夠在其數據目錄裏看到這些整塊生成容量不斷遞增的文件。

二、字段名所佔用的空間：爲了保持每一個記錄內的結構信息用於查詢，mongodb須要把每一個字段的key-value都以BSON的形式存儲，若是 value域相對於key域並不大，好比存放數值型的數據，則數據的overhead是最大的。一種減小空間佔用的方法是把字段名儘可能取短一些，這樣佔用 空間就小了，但這就要求在易讀性與空間佔用上做爲權衡了。我曾建議做者把字段名做個index，每一個字段名用一個字節表示，這樣就不用擔憂字段名取多長 了。但做者的擔心也不無道理，這種索引方式須要每次查詢獲得結果後把索引值跟原值做一個替換，再發送到客戶端，這個替換也是挺耗費時間的。如今的實現算是 拿空間來換取時間吧。

三、刪除記錄不釋放空間：這很容易理解，爲避免記錄刪除後的數據的大規模挪動，原記錄空間不刪除，只標記「已刪除」便可，之後還能夠重複利用。

四、能夠按期運行db.repairDatabase()來整理記錄，但這個過程會比較緩慢

③MongoDB沒有如MySQL那樣成熟的維護工具，這對於開發和IT運營都是個值得注意的地方。