大資料時代的資料存放區，非關係型資料庫MongoDB（一）

標籤：style   blog   http   io   color   os   使用   sp   strong   

爆炸式發展的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.預設計模式與動態模式

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

--資料庫欄位:NAME, SONGINSERT INTO T_INFO VALUES(‘John‘,‘Come Together‘);  --成功INSERT INTO T_INFO VALUES(‘小明‘, 20, ‘[email protected]‘);  --失敗

　

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

{"name" : "John", "song" : "Come Together"}{"name" : "小明",  "age":"20", "email" : "[email protected]"}

　　

　　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還需要成長，但他優秀的設計，肯定會讓越來越多的開發人員接受它。

 

大資料時代的資料存放區，非關係型資料庫MongoDB（一）