與關(guān)系型數(shù)據(jù)庫(kù)相比，MongoDB的優(yōu)點(diǎn)：
①弱一致性（最終一致），更能保證用戶(hù)的訪問(wèn)速度：
舉例來(lái)說(shuō)，在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)中，一個(gè)COUNT類(lèi)型的操作會(huì)鎖定數(shù)據(jù)集，這樣可以保證得到“當(dāng)前”情況下的精確值。這在某些情況下，例 如通過(guò)ATM查看賬戶(hù)信息的時(shí)候很重要，但對(duì)于Wordnik來(lái)說(shuō)，數(shù)據(jù)是不斷更新和增長(zhǎng)的，這種“精確”的保證幾乎沒(méi)有任何意義，反而會(huì)產(chǎn)生很大的延 遲。他們需要的是一個(gè)“大約”的數(shù)字以及更快的處理速度。

但某些情況下MongoDB會(huì)鎖住數(shù)據(jù)庫(kù)。如果此時(shí)正有數(shù)百個(gè)請(qǐng)求，則它們會(huì)堆積起來(lái)，造成許多問(wèn)題。我們使用了下面的優(yōu)化方式來(lái)避免鎖定：
每次更新前，我們會(huì)先查詢(xún)記錄。查詢(xún)操作會(huì)將對(duì)象放入內(nèi)存，于是更新則會(huì)盡可能的迅速。在主/從部署方案中，從節(jié)點(diǎn)可以使用“-pretouch”參數(shù)運(yùn)行，這也可以得到相同的效果。
使用多個(gè)mongod進(jìn)程。我們根據(jù)訪問(wèn)模式將數(shù)據(jù)庫(kù)拆分成多個(gè)進(jìn)程。
②文檔結(jié)構(gòu)的存儲(chǔ)方式，能夠更便捷的獲取數(shù)據(jù)。
對(duì)于一個(gè)層級(jí)式的數(shù)據(jù)結(jié)構(gòu)來(lái)說(shuō)，如果要將這樣的數(shù)據(jù)使用扁平式的，表狀的結(jié)構(gòu)來(lái)保存數(shù)據(jù)，這無(wú)論是在查詢(xún)還是獲取數(shù)據(jù)時(shí)都十分困難。
舉例1：
就拿一個(gè)“字典項(xiàng)”來(lái)說(shuō)，雖然并不十分復(fù)雜，但還是會(huì)關(guān)系到“定義”、“詞性”、“發(fā)音”或是“引用”等內(nèi)容。大部分工程師會(huì)將這種模型使用關(guān)系型數(shù)據(jù)庫(kù) 中的主鍵和外鍵表現(xiàn)出來(lái)，但把它看作一個(gè)“文檔”而不是“一系列有關(guān)系的表”豈不更好？使用 “dictionary.definition.partOfSpeech='noun'”來(lái)查詢(xún)也比表之間一系列復(fù)雜（往往代價(jià)也很高）的連接查詢(xún)方便 且快速。

舉例2：在一個(gè)關(guān)系型數(shù)據(jù)庫(kù)中，一篇博客（包含文章內(nèi)容、評(píng)論、評(píng)論的投票）會(huì)被打散在多張數(shù)據(jù)表中。在MongoDB中，能用一個(gè)文檔來(lái)表示一篇博客， 評(píng)論與投票作為文檔數(shù)組，放在正文主文檔中。這樣數(shù)據(jù)更易于管理，消除了傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)中影響性能和水平擴(kuò)展性的“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是一個(gè)面向文檔的數(shù)據(jù)庫(kù)，目前由10gen開(kāi)發(fā)并維護(hù)，它的功能豐富，齊全，完全可以替代MySQL。在使用MongoDB做產(chǎn)品原型的過(guò)程中，我們總結(jié)了MonogDB的一些亮點(diǎn)：
使用JSON風(fēng)格語(yǔ)法，易于掌握和理解：MongoDB使用JSON的變種BSON作為內(nèi)部存儲(chǔ)的格式和語(yǔ)法。針對(duì)MongoDB的操作都使用JSON風(fēng)格語(yǔ)法，客戶(hù)端提交或接收的數(shù)據(jù)都使用JSON形式來(lái)展現(xiàn)。相對(duì)于SQL來(lái)說(shuō)，更加直觀，容易理解和掌握。
Schema-less，支持嵌入子文檔：MongoDB是一個(gè)Schema-free的文檔數(shù)據(jù)庫(kù)。一個(gè)數(shù)據(jù)庫(kù)可以有多個(gè)Collection，每 個(gè)Collection是Documents的集合。Collection和Document和傳統(tǒng)數(shù)據(jù)庫(kù)的Table和Row并不對(duì)等。無(wú)需事先定義 Collection，隨時(shí)可以創(chuàng)建。
Collection中可以包含具有不同schema的文檔記錄。這意味著，你上一條記錄中的文檔有3個(gè)屬性，而下一條記錄的文檔可以有10個(gè)屬 性，屬性的類(lèi)型既可以是基本的數(shù)據(jù)類(lèi)型（如數(shù)字、字符串、日期等），也可以是數(shù)組或者散列，甚至還可以是一個(gè)子文檔（embeddocument）。這 樣，可以實(shí)現(xiàn)逆規(guī)范化（denormalizing）的數(shù)據(jù)模型，提高查詢(xún)的速度。

圖1 MongoDB是一個(gè)Schema-free的文檔數(shù)據(jù)庫(kù)

圖2是一個(gè)例子，作品和評(píng)論可以設(shè)計(jì)為一個(gè)collection，評(píng)論作為子文檔內(nèi)嵌在art的comments屬性中，評(píng)論的回復(fù)則作為 comment子文檔的子文檔內(nèi)嵌于replies屬性。按照這種設(shè)計(jì)模式，只需要按照作品id檢索一次，即可獲得所有相關(guān)的信息了。在MongoDB 中，不強(qiáng)調(diào)一定對(duì)數(shù)據(jù)進(jìn)行Normalize，很多場(chǎng)合都建議De-normalize，開(kāi)發(fā)人員可以扔掉傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)各種范式的限制，不需要把所有 的實(shí)體都映射為一個(gè)Collection，只需定義最頂級(jí)的class。MongoDB的文檔模型可以讓我們很輕松就能將自己的Object映射到 collection中實(shí)現(xiàn)存儲(chǔ)。

圖2 MongoDB支持嵌入子文檔

③內(nèi)置GridFS，支持大容量的存儲(chǔ)。
GridFS是一個(gè)出色的分布式文件系統(tǒng)，可以支持海量的數(shù)據(jù)存儲(chǔ)。
內(nèi)置了GridFS了MongoDB，能夠滿足對(duì)大數(shù)據(jù)集的快速范圍查詢(xún)。
④內(nèi)置Sharding。
提供基于Range的AutoSharding機(jī)制：一個(gè)collection可按照記錄的范圍，分成若干個(gè)段，切分到不同的Shard上。
Shards可以和復(fù)制結(jié)合，配合Replicasets能夠?qū)崿F(xiàn)Sharding+fail-over，不同的Shard之間可以負(fù)載均衡。查詢(xún)是對(duì) 客戶(hù)端是透明的。客戶(hù)端執(zhí)行查詢(xún)，統(tǒng)計(jì)，MapReduce等操作，這些會(huì)被MongoDB自動(dòng)路由到后端的數(shù)據(jù)節(jié)點(diǎn)。這讓我們關(guān)注于自己的業(yè)務(wù)，適當(dāng)?shù)?時(shí)候可以無(wú)痛的升級(jí)。MongoDB的Sharding設(shè)計(jì)能力最大可支持約20petabytes，足以支撐一般應(yīng)用。
這可以保證MongoDB運(yùn)行在便宜的PC服務(wù)器集群上。PC集群擴(kuò)充起來(lái)非常方便并且成本很低，避免了“sharding”操作的復(fù)雜性和成本。

⑤第三方支持豐富。(這是與其他的NoSQL相比，MongoDB也具有的優(yōu)勢(shì))
現(xiàn)在網(wǎng)絡(luò)上的很多NoSQL開(kāi)源數(shù)據(jù)庫(kù)完全屬于社區(qū)型的，沒(méi)有官方支持，給使用者帶來(lái)了很大的風(fēng)險(xiǎn)。
而開(kāi)源文檔數(shù)據(jù)庫(kù)MongoDB背后有商業(yè)公司10gen為其提供供商業(yè)培訓(xùn)和支持。
而且MongoDB社區(qū)非常活躍，很多開(kāi)發(fā)框架都迅速提供了對(duì)MongDB的支持。不少知名大公司和網(wǎng)站也在生產(chǎn)環(huán)境中使用MongoDB，越來(lái)越多的創(chuàng)新型企業(yè)轉(zhuǎn)而使用MongoDB作為和Django，RoR來(lái)搭配的技術(shù)方案。
⑥性能優(yōu)越：
在使用場(chǎng)合下，千萬(wàn)級(jí)別的文檔對(duì)象，近10G的數(shù)據(jù)，對(duì)有索引的ID的查詢(xún)不會(huì)比mysql慢，而對(duì)非索引字段的查詢(xún)，則是全面勝出。 mysql實(shí)際無(wú)法勝任大數(shù)據(jù)量下任意字段的查詢(xún)，而mongodb的查詢(xún)性能實(shí)在讓我驚訝。寫(xiě)入性能同樣很令人滿意，同樣寫(xiě)入百萬(wàn)級(jí)別的數(shù) 據(jù)，mongodb比我以前試用過(guò)的couchdb要快得多，基本10分鐘以下可以解決。補(bǔ)上一句，觀察過(guò)程中mongodb都遠(yuǎn)算不上是CPU殺手。

與關(guān)系型數(shù)據(jù)庫(kù)相比，MongoDB的缺點(diǎn)：
①mongodb不支持事務(wù)操作。
所以事務(wù)要求嚴(yán)格的系統(tǒng)（如果銀行系統(tǒng)）肯定不能用它。(這點(diǎn)和優(yōu)點(diǎn)①是對(duì)應(yīng)的)
②mongodb占用空間過(guò)大。
關(guān)于其原因，在官方的FAQ中，提到有如下幾個(gè)方面：
1、空間的預(yù)分配：為避免形成過(guò)多的硬盤(pán)碎片，mongodb每次空間不足時(shí)都會(huì)申請(qǐng)生成一大塊的硬盤(pán)空間，而且申請(qǐng)的量從64M、128M、256M那 樣的指數(shù)遞增，直到2G為單個(gè)文件的最大體積。隨著數(shù)據(jù)量的增加，你可以在其數(shù)據(jù)目錄里看到這些整塊生成容量不斷遞增的文件。

2、字段名所占用的空間：為了保持每個(gè)記錄內(nèi)的結(jié)構(gòu)信息用于查詢(xún)，mongodb需要把每個(gè)字段的key-value都以BSON的形式存儲(chǔ)，如果 value域相對(duì)于key域并不大，比如存放數(shù)值型的數(shù)據(jù)，則數(shù)據(jù)的overhead是最大的。一種減少空間占用的方法是把字段名盡量取短一些，這樣占用 空間就小了，但這就要求在易讀性與空間占用上作為權(quán)衡了。我曾建議作者把字段名作個(gè)index，每個(gè)字段名用一個(gè)字節(jié)表示，這樣就不用擔(dān)心字段名取多長(zhǎng) 了。但作者的擔(dān)憂也不無(wú)道理，這種索引方式需要每次查詢(xún)得到結(jié)果后把索引值跟原值作一個(gè)替換，再發(fā)送到客戶(hù)端，這個(gè)替換也是挺耗費(fèi)時(shí)間的。現(xiàn)在的實(shí)現(xiàn)算是 拿空間來(lái)?yè)Q取時(shí)間吧。

3、刪除記錄不釋放空間：這很容易理解，為避免記錄刪除后的數(shù)據(jù)的大規(guī)模挪動(dòng)，原記錄空間不刪除，只標(biāo)記“已刪除”即可，以后還可以重復(fù)利用。

4、可以定期運(yùn)行db.repairDatabase()來(lái)整理記錄，但這個(gè)過(guò)程會(huì)比較緩慢

③MongoDB沒(méi)有如MySQL那樣成熟的維護(hù)工具，這對(duì)于開(kāi)發(fā)和IT運(yùn)營(yíng)都是個(gè)值得注意的地方。