大資料時代的資料儲存，非關係型資料庫MongoDB

文章相關：開發高效能的MongoDB應用—淺談MongoDB效能優化

爆炸式發展的NoSQL技術　

在過去的很長一段時間中，關係型資料庫（Relational Database Management System）一直是最主流的資料庫解決方案，他運用真實世界中事物與關係來解釋資料庫中抽象的資料架構。然而，在資訊科技爆炸式發展的今天，大資料已經成為了繼雲端計算，物聯網後新的技術革命，關係型資料庫在處理大資料量時已經開始吃力，開發者只能通過不斷地優化資料庫來解決資料量的問題，但優化畢竟不是一個長期方案，所以人們提出了一種新的資料庫解決方案來迎接大資料時代的到來——NoSQL（非關係型資料庫）。

NoSQL非常年輕，但他擁有的眾多優秀的特性已經讓眾多企業和開發者開始接受，讓我們來看一下來自於美國資料庫知識網站DB-engines上個月的資料庫排名情況。

從排名中可以看到MongoDB資料庫從眾多的RDBMS（關係型資料庫）中脫穎而出，已經成為第五名，並且還在不斷上升中。

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

為什麼選擇MongoDB？?

1.效能

在大資料時代中，大資料量的處理已經成了考量一個資料庫最重要的原因之一。而MongoDB的一個主要目標就是儘可能的讓資料庫保持卓越的效能，這很大程度地決定了MongoDB的設計。在一個以傳統機械硬碟為主導的年代，硬碟很可能會成為效能的短板，而MongoDB選擇了最大程度而利用記憶體資源用作快取來換取卓越的效能，並且會自動選擇速度最快的索引來進行查詢。MongoDB儘可能精簡資料庫，將盡可能多的操作交給客戶端，這種方式也是MongoDB能夠保持卓越效能的原因之一。

2.擴充套件

現在網際網路的資料量已經從過去的MB、GB變為了現在的TB級別，單一的資料庫顯然已經無法承受，擴充套件性成為重要的話題，然而現在的開發人員常常在選擇擴充套件方式的時候犯了難，到底是選擇橫向擴充套件還是縱向擴充套件呢？

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

橫向擴充套件（scale out）是以增加分割槽的方式將資料庫拆分成不同的區塊來分佈到不同的機器中來，這樣的優勢是擴充套件成本低但管理困難。

縱向擴充套件（scale up） 縱向擴充套件與橫向擴充套件不同的是他會將原本的伺服器進行升級，讓其擁有更強大的計算能力。這樣的優勢是易於管理無需考慮擴充套件帶來的眾多問題，但缺點也顯而易見，那就是成本高。一臺大型機的價格往往非常昂貴，並且這樣的升級在資料達到極限時，可能就找不到計算能力更為強大的機器了。

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

而MongoDB選擇的是更為經濟的橫向擴充套件，他可以很容易的將資料拆分至不同的伺服器中。而且在獲取資料時開發者也無需考慮多伺服器帶來的問題，MongoDB可以將開發者的請求自動路由到正確的伺服器中，讓開發者脫離橫向擴充套件帶來的弊病，更專注於程式的開發上。

3.使用

MongoDB採用的是NoSQL的設計方式，可以更加靈活的運算元據。在進行傳統的RDBMS中你一定遇到過幾十行甚至上百行的複雜SQL語句，傳統的RDBMS的SQL語句中包含著大量關聯，子查詢等語句，在增加複雜性的同時還讓效能調優變得更加困難。MongoDB的面向文件（document-oriented）設計中採用更為靈活的文件來作為資料模型用來取代RDBMS中的行，面向文件的設計讓開發人員獲取資料的方式更加靈活，甚至於開發人員僅用一條語句即可查詢複雜的巢狀關係，讓開發人員不必為了獲取資料而絞盡腦汁。

NoSQL對傳統資料庫設計思維的影響

1.預設計模式與動態模式

傳統資料庫設計思維中，專案的設計階段需要對資料庫表中的欄位名稱、欄位型別、進行規定，如果嘗試插入不符合設計的資料，資料庫不會接受這條資料以保證資料的完整性。

NoSQL採用的是對集合（類似”表”）中的文件（類似於”行”）進行動態追加，在建立集合之初不會對資料型別進行限定，任何文件都可以追加到任何集合中去，例如我們可以將這樣兩條文件新增到一個集合中去：

MongoDB中文件的格式類似於我們常見的JSON，由此可見，我們第一個擁有”name”、”song”兩個欄位，而第二個擁有”name”、”age”、”email”三個欄位，這在預設計模式中的資料庫是不可能插入成功的，但在MongoDB的動態模式是可以的，這樣做的優勢是我們不必為一些數量很少，但種類很多的欄位單獨設計一張表，可以將他們集中在單獨一張表進行儲存，但這樣做的弊病也是顯而易見的，我們在獲取資料時需要對同一張表的不同文件進行區分，增加了開發上的程式碼量。所以在設計之初需要權衡動態模式的優劣來選擇表中的資料型別。

2.正規化化與反正規化化

正規化化（normalization）是關係模型的發明者埃德加·科德於1970年提出這一概念，正規化化會將資料分散到不同的表中，利用關係模型進行關聯，由此帶來的優點是，在後期進行修改時，不會影響到與其關聯的資料，僅對自身修改即可完成。

反正規化化（denormalization）是針對正規化化提出的相反理念，反正規化化會將當前文件的資料集中存放在本表中，而不會採用拆分的方式進行儲存。

正規化化和反正規化化之間不存在優劣的問題，正規化化的好處是可以在我們寫入、修改、刪除時的提供更高效能，而反正規化化可以提高我們在查詢時的效能。當然NoSQL中是不存在關聯查詢的，以此提高查詢效能，但我們依舊可以以在表中儲存關聯表ID的方式進行正規化化。但由此可見，NoSQL的理念中反正規化化的地位是大於正規化化的。

MongoDB還年輕

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

1. MongoDB不支援事務，現在眾多的軟體依舊需要事務的管理，所以對於事務一致性要求較高的程式只能在軟體層面進行管理，而無法從資料庫進行管理。

2. 其他工具的支援範圍，MongoDB從釋出起到現在還不到5年的時間，所以會面臨著許多的語言沒有對應的工具包，所以如果你使用的語言沒有對應的包，可能是導致你無法使用MongoDB最大的阻礙。

3. 社群的資源量，這個問題同第二個問題一樣是因為MongoDB過於年輕導致的，相對於其他大型資料庫的社群而言，MongoDB顯然是無法與之相比的，然而社群往往也是一個重要考量因素之一，社群資源的匱乏會導致問題解決週期延長，從而拖延工作。

近幾年的技術發展之快是激動人心的，每年都會出現讓人眼前一亮的產品，然而它都需要經過時間的累積才能成為一個成熟的產品，MongoDB還需要成長，但他優秀的設計，肯定會讓越來越多的開發者接受它。