大數(shù)據(jù)時代的數(shù)據(jù)存儲，非關(guān)系型數(shù)據(jù)庫MongoDB

爆炸式發(fā)展的NoSQL技術(shù)　
在過去的很長一段時間中，關(guān)系型數(shù)據(jù)庫（Relational Database Management System）一直是最主流的數(shù)據(jù)庫解決方案，他運(yùn)用真實(shí)世界中事物與關(guān)系來解釋數(shù)據(jù)庫中抽象的數(shù)據(jù)架構(gòu)。然而，在信息技術(shù)爆炸式發(fā)展的今天，大數(shù)據(jù)已經(jīng)成為了繼云計算，物聯(lián)網(wǎng)后新的技術(shù)革命，關(guān)系型數(shù)據(jù)庫在處理大數(shù)據(jù)量時已經(jīng)開始吃力，開發(fā)者只能通過不斷地優(yōu)化數(shù)據(jù)庫來解決數(shù)據(jù)量的問題，但優(yōu)化畢竟不是一個長期方案，所以人們提出了一種新的數(shù)據(jù)庫解決方案來迎接大數(shù)據(jù)時代的到來——NoSQL（非關(guān)系型數(shù)據(jù)庫）。

NoSQL非常年輕，但他擁有的眾多優(yōu)秀的特性已經(jīng)讓眾多企業(yè)和開發(fā)者開始接受，讓我們來看一下來自于美國數(shù)據(jù)庫知識網(wǎng)站DB-engines上個月的數(shù)據(jù)庫排名情況。

從排名中可以看到MongoDB數(shù)據(jù)庫從眾多的RDBMS（關(guān)系型數(shù)據(jù)庫）中脫穎而出，已經(jīng)成為第五名，并且還在不斷上升中。

如果將數(shù)據(jù)庫比喻成人類的話，那么MongoDB完全可以說是神童了，年僅5歲的他單槍匹馬挑戰(zhàn)一群叔叔級別的人物，并且按照近幾年的發(fā)展速度來看，他也即將超越PgSQL成為第四名，雖然距離前方三位有著NB爹的富二代還有一定的距離，但在這樣一個技術(shù)爆炸的年代還有什么不可能的事呢？

為什么選擇MongoDB？?
1.性能
在大數(shù)據(jù)時代中，大數(shù)據(jù)量的處理已經(jīng)成了考量一個數(shù)據(jù)庫最重要的原因之一。而MongoDB的一個主要目標(biāo)就是盡可能的讓數(shù)據(jù)庫保持卓越的性能，這很大程度地決定了MongoDB的設(shè)計。在一個以傳統(tǒng)機(jī)械硬盤為主導(dǎo)的年代，硬盤很可能會成為性能的短板，而MongoDB選擇了最大程度而利用內(nèi)存資源用作緩存來換取卓越的性能，并且會自動選擇速度最快的索引來進(jìn)行查詢。MongoDB盡可能精簡數(shù)據(jù)庫，將盡可能多的操作交給客戶端，這種方式也是MongoDB能夠保持卓越性能的原因之一。

2.擴(kuò)展
現(xiàn)在互聯(lián)網(wǎng)的數(shù)據(jù)量已經(jīng)從過去的MB、GB變?yōu)榱爽F(xiàn)在的TB級別，單一的數(shù)據(jù)庫顯然已經(jīng)無法承受，擴(kuò)展性成為重要的話題，然而現(xiàn)在的開發(fā)人員常常在選擇擴(kuò)展方式的時候犯了難，到底是選擇橫向擴(kuò)展還是縱向擴(kuò)展呢？

橫向擴(kuò)展（scale out）是以增加分區(qū)的方式將數(shù)據(jù)庫拆分成不同的區(qū)塊來分布到不同的機(jī)器中來，這樣的優(yōu)勢是擴(kuò)展成本低但管理困難。

縱向擴(kuò)展（scale up） 縱向擴(kuò)展與橫向擴(kuò)展不同的是他會將原本的服務(wù)器進(jìn)行升級，讓其擁有更強(qiáng)大的計算能力。這樣的優(yōu)勢是易于管理無需考慮擴(kuò)展帶來的眾多問題，但缺點(diǎn)也顯而易見，那就是成本高。一臺大型機(jī)的價格往往非常昂貴，并且這樣的升級在數(shù)據(jù)達(dá)到極限時，可能就找不到計算能力更為強(qiáng)大的機(jī)器了。

而MongoDB選擇的是更為經(jīng)濟(jì)的橫向擴(kuò)展，他可以很容易的將數(shù)據(jù)拆分至不同的服務(wù)器中。而且在獲取數(shù)據(jù)時開發(fā)者也無需考慮多服務(wù)器帶來的問題，MongoDB可以將開發(fā)者的請求自動路由到正確的服務(wù)器中，讓開發(fā)者脫離橫向擴(kuò)展帶來的弊病，更專注于程序的開發(fā)上。

3.使用
MongoDB采用的是NoSQL的設(shè)計方式，可以更加靈活的操作數(shù)據(jù)。在進(jìn)行傳統(tǒng)的RDBMS中你一定遇到過幾十行甚至上百行的復(fù)雜SQL語句，傳統(tǒng)的RDBMS的SQL語句中包含著大量關(guān)聯(lián)，子查詢等語句，在增加復(fù)雜性的同時還讓性能調(diào)優(yōu)變得更加困難。MongoDB的面向文檔（document-oriented）設(shè)計中采用更為靈活的文檔來作為數(shù)據(jù)模型用來取代RDBMS中的行，面向文檔的設(shè)計讓開發(fā)人員獲取數(shù)據(jù)的方式更加靈活，甚至于開發(fā)人員僅用一條語句即可查詢復(fù)雜的嵌套關(guān)系，讓開發(fā)人員不必為了獲取數(shù)據(jù)而絞盡腦汁。

NoSQL對傳統(tǒng)數(shù)據(jù)庫設(shè)計思維的影響
1.預(yù)設(shè)計模式與動態(tài)模式
傳統(tǒng)數(shù)據(jù)庫設(shè)計思維中，項(xiàng)目的設(shè)計階段需要對數(shù)據(jù)庫表中的字段名稱、字段類型、進(jìn)行規(guī)定，如果嘗試插入不符合設(shè)計的數(shù)據(jù)，數(shù)據(jù)庫不會接受這條數(shù)據(jù)以保證數(shù)據(jù)的完整性。

MySQL

--數(shù)據(jù)庫字段:NAME, SONG

INSERT INTO T_INFO VALUES('John','Come Together'); --成功

INSERT INTO T_INFO VALUES('小明', 20, 'xiaoming@111.com'); --失敗
--數(shù)據(jù)庫字段:NAME, SONG

INSERT INTO T_INFO VALUES('John','Come Together'); --成功

INSERT INTO T_INFO VALUES('小明', 20, 'xiaoming@111.com'); --失敗
NoSQL采用的是對集合（類似”表”）中的文檔（類似于”行”）進(jìn)行動態(tài)追加，在創(chuàng)建集合之初不會對數(shù)據(jù)類型進(jìn)行限定，任何文檔都可以追加到任何集合中去，例如我們可以將這樣兩條文檔添加到一個集合中去：

MySQL

{"name" : "John", "song" : "Come Together"}

{"name" : "小明", "age":"20", "email" : "xiaoming@111.com"}
{"name" : "John", "song" : "Come Together"}

{"name" : "小明", "age":"20", "email" : "xiaoming@111.com"}
MongoDB中文檔的格式類似于我們常見的JSON，由此可見，我們第一個擁有”name”、”song”兩個字段，而第二個擁有”name”、”age”、”email”三個字段，這在預(yù)設(shè)計模式中的數(shù)據(jù)庫是不可能插入成功的，但在MongoDB的動態(tài)模式是可以的，這樣做的優(yōu)勢是我們不必為一些數(shù)量很少，但種類很多的字段單獨(dú)設(shè)計一張表，可以將他們集中在單獨(dú)一張表進(jìn)行存儲，但這樣做的弊病也是顯而易見的，我們在獲取數(shù)據(jù)時需要對同一張表的不同文檔進(jìn)行區(qū)分，增加了開發(fā)上的代碼量。所以在設(shè)計之初需要權(quán)衡動態(tài)模式的優(yōu)劣來選擇表中的數(shù)據(jù)類型。

2.范式化與反范式化
范式化（normalization）是關(guān)系模型的發(fā)明者埃德加·科德于1970年提出這一概念，范式化會將數(shù)據(jù)分散到不同的表中，利用關(guān)系模型進(jìn)行關(guān)聯(lián)，由此帶來的優(yōu)點(diǎn)是，在后期進(jìn)行修改時，不會影響到與其關(guān)聯(lián)的數(shù)據(jù)，僅對自身修改即可完成。

反范式化（denormalization）是針對范式化提出的相反理念，反范式化會將當(dāng)前文檔的數(shù)據(jù)集中存放在本表中，而不會采用拆分的方式進(jìn)行存儲。

范式化和反范式化之間不存在優(yōu)劣的問題，范式化的好處是可以在我們寫入、修改、刪除時的提供更高性能，而反范式化可以提高我們在查詢時的性能。當(dāng)然NoSQL中是不存在關(guān)聯(lián)查詢的，以此提高查詢性能，但我們依舊可以以在表中存儲關(guān)聯(lián)表ID的方式進(jìn)行范式化。但由此可見，NoSQL的理念中反范式化的地位是大于范式化的。

MongoDB還年輕
MongoDB又有眾多卓越的設(shè)計，但MongoDB依然存在著許多不擅長的問題，其中包括：

1. MongoDB不支持事務(wù)，現(xiàn)在眾多的軟件依舊需要事務(wù)的管理，所以對于事務(wù)一致性要求較高的程序只能在軟件層面進(jìn)行管理，而無法從數(shù)據(jù)庫進(jìn)行管理。

2. 其他工具的支持范圍，MongoDB從發(fā)布起到現(xiàn)在還不到5年的時間，所以會面臨著許多的語言沒有對應(yīng)的工具包，所以如果你使用的語言沒有對應(yīng)的包，可能是導(dǎo)致你無法使用MongoDB最大的阻礙。

3. 社區(qū)的資源量，這個問題同第二個問題一樣是因?yàn)镸ongoDB過于年輕導(dǎo)致的，相對于其他大型數(shù)據(jù)庫的社區(qū)而言，MongoDB顯然是無法與之相比的，然而社區(qū)往往也是一個重要考量因素之一，社區(qū)資源的匱乏會導(dǎo)致問題解決周期延長，從而拖延工作。

近幾年的技術(shù)發(fā)展之快是激動人心的，每年都會出現(xiàn)讓人眼前一亮的產(chǎn)品，然而它都需要經(jīng)過時間的累積才能成為一個成熟的產(chǎn)品，MongoDB還需要成長，但他優(yōu)秀的設(shè)計，肯定會讓越來越多的開發(fā)者接受它