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

爆炸式發(fā)展的NoSQL技術(shù)　

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

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

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

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

為什么選擇MongoDB？?

1.性能

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

2.擴(kuò)展

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

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

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

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

3.使用

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

NoSQL對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)思維的影響

1.預(yù)設(shè)計(jì)模式與動(dòng)態(tài)模式

傳統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)思維中，項(xiàng)目的設(shè)計(jì)階段需要對(duì)數(shù)據(jù)庫(kù)表中的字段名稱(chēng)、字段類(lèi)型、進(jìn)行規(guī)定，如果嘗試插入不符合設(shè)計(jì)的數(shù)據(jù)，數(shù)據(jù)庫(kù)不會(huì)接受這條數(shù)據(jù)以保證數(shù)據(jù)的完整性。

NoSQL采用的是對(duì)集合（類(lèi)似”表”）中的文檔（類(lèi)似于”行”）進(jìn)行動(dòng)態(tài)追加，在創(chuàng)建集合之初不會(huì)對(duì)數(shù)據(jù)類(lèi)型進(jìn)行限定，任何文檔都可以追加到任何集合中去，例如我們可以將這樣兩條文檔添加到一個(gè)集合中去：

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

2.范式化與反范式化

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

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

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

MongoDB還年輕

MongoDB又有眾多卓越的設(shè)計(jì)，但MongoDB依然存在著許多不擅長(zhǎng)的問(wèn)題，其中包括：

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

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

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

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