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

　　在過去的很長一段時間中，關(guān)系型數(shù)據(jù)庫（Relational Database Management System）一直是最主流的數(shù)據(jù)庫解決方案，他運用真實世界中事物與關(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的一個主要目標就是盡可能的讓數(shù)據(jù)庫保持卓越的性能，這很大程度地決定了MongoDB的設(shè)計。在一個以傳統(tǒng)機械硬盤為主導的年代，硬盤很可能會成為性能的短板，而MongoDB選擇了最大程度而利用內(nèi)存資源用作緩存來換取卓越的性能，并且會自動選擇速度最快的索引來進行查詢。MongoDB盡可能精簡數(shù)據(jù)庫，將盡可能多的操作交給客戶端，這種方式也是MongoDB能夠保持卓越性能的原因之一。

2.擴展

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

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

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

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

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

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

3.使用

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

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

1.預設(shè)計模式與動態(tài)模式

　  傳統(tǒng)數(shù)據(jù)庫設(shè)計思維中，項目的設(shè)計階段需要對數(shù)據(jù)庫表中的字段名稱、字段類型、進行規(guī)定，如果嘗試插入不符合設(shè)計的數(shù)據(jù)，數(shù)據(jù)庫不會接受這條數(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采用的是對集合（類似"表"）中的文檔（類似于"行"）進行動態(tài)追加，在創(chuàng)建集合之初不會對數(shù)據(jù)類型進行限定，任何文檔都可以追加到任何集合中去，例如我們可以將這樣兩條文檔添加到一個集合中去：

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

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

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

2.范式化與反范式化

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

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

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

MongoDB還年輕

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

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

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

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

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