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

　　在過去的很長(zhǎng)一段時(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)成為了繼云計(jì)算，物聯(lián)網(wǎng)后新的技術(shù)革命，關(guān)系型數(shù)據(jù)庫在處理大數(shù)據(jù)量時(shí)已經(jīng)開始吃力，開發(fā)者只能通過不斷地優(yōu)化數(shù)據(jù)庫來解決數(shù)據(jù)量的問題，但優(yōu)化畢竟不是一個(gè)長(zhǎng)期方案，所以人們提出了一種新的數(shù)據(jù)庫解決方案來迎接大數(shù)據(jù)時(shí)代的到來——NoSQL（非關(guān)系型數(shù)據(jù)庫）。

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

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

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

為什么選擇MongoDB？

1.性能

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

2.擴(kuò)展

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

——————————————————————————————————————————————————————————————

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

　　縱向擴(kuò)展（scale up） 縱向擴(kuò)展與橫向擴(kuò)展不同的是他會(huì)將原本的服務(wù)器進(jìn)行升級(jí)，讓其擁有更強(qiáng)大的計(jì)算能力。這樣的優(yōu)勢(shì)是易于管理無需考慮擴(kuò)展帶來的眾多問題，但缺點(diǎ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í)開發(fā)者也無需考慮多服務(wù)器帶來的問題，MongoDB可以將開發(fā)者的請(qǐng)求自動(dòng)路由到正確的服務(wù)器中，讓開發(fā)者脫離橫向擴(kuò)展帶來的弊病，更專注于程序的開發(fā)上。

3.使用

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

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

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

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

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

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

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

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

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

2.范式化與反范式化

　　范式化（normalization）是關(guān)系模型的發(fā)明者埃德加·科德于1970年提出這一概念，范式化會(huì)將數(shù)據(jù)分散到不同的表中，利用關(guān)系模型進(jìn)行關(guān)聯(lián)，由此帶來的優(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)劣的問題，范式化的好處是可以在我們寫入、修改、刪除時(shí)的提供更高性能，而反范式化可以提高我們?cè)诓樵儠r(shí)的性能。當(dāng)然NoSQL中是不存在關(guān)聯(lián)查詢的，以此提高查詢性能，但我們依舊可以以在表中存儲(chǔ)關(guān)聯(lián)表ID的方式進(jìn)行范式化。但由此可見，NoSQL的理念中反范式化的地位是大于范式化的。

MongoDB還年輕

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

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

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

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

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