[MongoDB]MongoDB的優缺點及與關係型數據庫的比較
彙總：
1. [MongoDB]安裝MongoDB
2. [MongoDB]Mongo基本使用：
3. [MongoDB]MongoDB的優缺點及與關係型數據庫的比較
4. [MongoDB]MongoDB與JAVA結合使用CRUD
參考：http://www.cnblogs.com/hoojo/archive/2011/06/01/2066119.html
介紹：MongoDB是一個基於分佈式文件存儲的數據庫。由C++語言編寫。旨在爲WEB應用提供可擴展的高性能數據存儲解決方案。
特點：高性能、易部署、易使用，存儲數據非常方便。
主要功能特性有：
Ø 面向集合存儲，易存儲對象類型的數據
Ø 模式自由
Ø 支持動態查詢
Ø 支持完全索引，包含內部對象
Ø 支持查詢
Ø 支持複製和故障恢復
Ø 使用高效的二進制數據存儲，包括大型對象（如視頻等）
Ø 自動處理碎片，以支持雲計算層次的擴展性
Ø 支持RUBY，PYTHON，JAVA，C++，PHP等多種語言
Ø 文件存儲格式爲BSON（一種JSON的擴展）
Ø 可通過網絡訪問
使用原理
所謂"面向集合"（Collenction-Oriented），意思是數據被分組存儲在數據集中，被稱爲一個集合（Collenction)。每個集合在數據庫中都有一個唯一的標識名，並且可以包含無限數目的文檔。集合的概念類似關係型數據庫（RDBMS）裏的表（table），不同的是它不需要定義任何模式（schema)。
模式自由（schema-free)，意味着對於存儲在mongodb數據庫中的文件，我們不需要知道它的任何結構定義。如果需要的話，你完全可以把不同結構的文件存儲在同一個數據庫裏。
存儲在集合中的文檔，被存儲爲鍵-值對的形式。鍵用於唯一標識一個文檔，爲字符串類型，而值則可以是各種複雜的文件類型。我們稱這種存儲形式爲BSON（Binary JSON）。
參考：
http://blog.sina.com.cn/s/blog_966e430001019s8v.html
與關係型數據庫相比，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 } );
舉例③：
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運營都是個值得注意的地方
