在MongoDB的網(wǎng)站上，它這樣自我介紹：做以前你從未能做的事(Do What You Could Never Do Before)。為什么MongoDB敢這樣說?它有什么長處與不足?今天我們給大家拋磚引玉。

一、 MongoDB是什么?

“需求是創(chuàng)新之母。” 雖然這是句老話，但現(xiàn)在依然很受用!

過去的十年，我們將數(shù)據(jù)生成、存儲和分析的臨界點推上一個全新的高度。這個大躍進是我們向數(shù)字化的數(shù)據(jù)驅(qū)動的經(jīng)濟又近了一步;這個大躍進也創(chuàng)造了它自身的需要。而這些問題及其解決方法通常都在大數(shù)據(jù)的保護傘之下。

想象一下：如今，臉書和谷歌產(chǎn)生了更多的數(shù)據(jù)，它們加在一起超過了前幾年的全球數(shù)據(jù)總量。伴隨數(shù)據(jù)生成的高速增長，隨之而來是存儲和規(guī)模的問題。看，所有人都希望臉書上的訂閱能夠被瞬間加載——我們憎恨端著手機和電腦在那兒傻傻等著它加載?？苫仡^想想，什么架構(gòu)才能使我們有這樣快速體驗?數(shù)百萬的用戶同時向數(shù)據(jù)庫請求實時信息。再加上非結(jié)構(gòu)化數(shù)據(jù)和系統(tǒng)需求(讓您可以快速添加新功能)，這看上去更像是一個不可能完成的任務(wù)。

傳統(tǒng)的數(shù)據(jù)庫很難應(yīng)付這種需求，且提升規(guī)模所需的成本令人望而卻步。本文給大家介紹一個新型的數(shù)據(jù)存儲系統(tǒng)，大家管它叫做MongoDB。它提供了無架構(gòu)設(shè)計、高性能、高可用性和自動規(guī)模伸縮，這是當(dāng)前所需要但傳統(tǒng)RDBMS系統(tǒng)無法滿足的性質(zhì)。

維基上這么描述MongoDB

MongoDB(源自huMONGOus一詞，意為“堆積如山的”)是一個跨平臺的面向文檔的NoSQL數(shù)據(jù)庫。MongoDB避開了傳統(tǒng)的基于表格的關(guān)系型數(shù)據(jù)庫結(jié)構(gòu)，代之以具有動態(tài)結(jié)構(gòu)的類JSON文檔格式(MongoDB稱之為BSON)，從而使一些特定類型應(yīng)用的數(shù)據(jù)整合更容易、更快。在GNU Affero和Apach許可下發(fā)布的MongoDB是一個免費的開源軟件。

二、有誰在用MongoDB?

下面只列舉其中一部分。實際上，MongoDB在全球已有一千萬次以上的下載量，目前有三十萬人正在學(xué)習(xí)MongoDB。

三、對比傳統(tǒng)關(guān)系型數(shù)據(jù)庫

將關(guān)系型數(shù)據(jù)庫和MongoDB進行比較，就好似在比較一只獅子和一只老虎一般。雖然都是食肉動物，但是一個是獨自狩獵，另一個則是群體出動。SQL(老虎)有著一個固定的數(shù)據(jù)模型，其中的數(shù)據(jù)需要遵循架構(gòu)的設(shè)計，這有助于組織分析例如銷售統(tǒng)計類的結(jié)構(gòu)化數(shù)據(jù)。而另一方，MongoDB(獅子)是一個基于文檔的數(shù)據(jù)庫，它以文檔的形式存儲數(shù)據(jù)。雖然他們的方法不同，但依據(jù)組織化的需求，這兩者都需要數(shù)據(jù)存儲并選擇數(shù)據(jù)庫類型。

四、使用MongoDB有什么優(yōu)點?

從上面的附圖你可以發(fā)現(xiàn)，當(dāng)服務(wù)器上的查詢數(shù)量增加時，MongoDB就明顯是一個勝利者。MongoDB 非常適用于實時分析，它有著低延遲以及針對需求的高可用性。

MongoDB已經(jīng)進入了前沿領(lǐng)域，因為各類組織需要分析半結(jié)構(gòu)化、非結(jié)構(gòu)化以及地理或空間數(shù)據(jù)，更因為現(xiàn)今世界原先的結(jié)構(gòu)化數(shù)據(jù)正在被快速的改變。

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫系統(tǒng)不能完全應(yīng)付得了這些需求，因為它們固有的結(jié)構(gòu)不允許它們處理這樣的需求。雖然關(guān)系型數(shù)據(jù)庫系統(tǒng)也在改變，來迎合數(shù)據(jù)的大爆發(fā)，但最適合處理當(dāng)今數(shù)據(jù)的數(shù)據(jù)庫仍是像MongoDB這類文檔數(shù)據(jù)庫。

#p#

五、MongoDB的局限性是什么?

以下列舉了一些MongoDB的限制。

1.最大的文件不能超過16MB

2.最大文件嵌套層級為100(指文件嵌套文件再嵌套文件)

3.索引區(qū)不能超過1024字節(jié)。

4.每個集合最多為64個索引。

5.創(chuàng)建一個復(fù)合索引最多使用31個字段。

6.全文本搜索和地理位置索引是互斥的。

7.在32位機器上，一個固定集合(capped collection)中的文件數(shù)量大小是有限制的。但64位機器上則對文件數(shù)量大小沒有限制。

8.在Windows系統(tǒng)上，MongoDB不能存儲超過4TB的數(shù)據(jù)(去除日志后為8TB)

9.在單個復(fù)制集中最多可有12個節(jié)點。

10.在單個復(fù)制集中最多可有7個投票節(jié)點。

11.如要回滾超過300MB的數(shù)據(jù)，需要進行人工干預(yù)。

12.在分片集群(sharded cluster)中無法使用組命令。

13.在分片集群中無法使用 $isolated, $snapshot, geoSearch。

14.你無法在 $where中涉及到數(shù)據(jù)庫對象。

15.為了分片一個集合，它必須小于256GB。

16.在分片集群中對單條記錄(非多條)的更新/移出必須包含分片密鑰。同樣命令針對多條記錄執(zhí)行時則可以不包含分片密鑰。

17.分片密鑰最大值為512字節(jié)。

18.一旦分片完成，一個集合的分片密鑰值將無法改變。

除了這些限制以外，在關(guān)系型數(shù)據(jù)庫系統(tǒng)中用約束來防止數(shù)據(jù)被意外刪除的功能在MongoDB或其他NoSQL數(shù)據(jù)庫系統(tǒng)中無法實現(xiàn)。 也可能有其它問題，例如像下面列示的這個，為了存儲多層數(shù)據(jù)而違反了標(biāo)準(zhǔn)范式。

一個用戶有許多朋友，并可能其中之一就是他自己。人們可能反復(fù)對自身進行點贊、評論或兩者皆有的行為動作。這種類型的反復(fù)模式使得它更難將一個活動流反規(guī)范化(de-normalize)為一份獨立的文檔

MongoDB也像其它科技一般，非常公平的共享了它的局限性和缺陷，并且隨著版本更新，它們將很有希望被解決。