mongodb的缺點有：1、mongodb不支持事務操作；2、使用mongodb數據庫存儲數據占用空間過大；3、mongodb沒有如mysql那樣成熟的維護工具；4、mongodb在集群分片中的數據分布不均勻；5、在mongodb中持續插入大量數據，其寫入性能會有較大波動；6、使用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、支持復制集、主備、互為主備、自動分片等特性