mongodb與mysql相比的優缺點

與關聯式資料庫相比，MongoDB的優點：

①弱一致性（最終一致），更能保證使用者的存取速度：

        舉例來說，在傳統的關聯式資料庫中，一個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 } );

舉例3：
        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中，提到有以下幾個面向：

1.空間的預先分配：為避免形成過多的硬碟碎片，mongodb每次空間不足時都會申請產生一大塊的硬碟空間，而且申請的量從64M、128M、256M那樣的指數遞增，直到2G為單一文件的最大體積。隨著資料量的增加，你可以在其資料目錄中看到這些整塊產生容量不斷遞增的檔案。

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

3、刪除記錄不釋放空間：這很容易理解，為避免記錄刪除後的資料的大規模挪動，原記錄空間不刪除，只標記「已刪除」即可，以後還可以重複利用。

4、可以定期執行db.repairDatabase()來整理記錄，但這個過程會比較緩慢。

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

由於上傳附件及文字限制，有時部分圖片、文字可能顯示不了，詳情請見：http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000725&idx=3&sn=1e135403774b200 rd
歡迎大家一起交流。
掃描以下二維碼，獲取更多更精美文章！ (掃碼關注有意不到的驚喜的哦！！）

訂閱號碼二維碼.jpg (39.39 KB, 下載次數: 0)

下載附件

2016-6-2 18:37 上傳

關注我們微信訂閱號碼（ uniguytech100） 與服務號碼（uniguytech），獲取更多更精美文章！
也歡迎加入【大家技術網討論QQ群】，群號：256175955，請備註你個人的介紹！讓我們一起聊聊it的那些事吧！