1. 程式人生 > >大數據時代的數據存儲,非關系型數據庫MongoDB

大數據時代的數據存儲,非關系型數據庫MongoDB

字段名 b數 重要 到來 子查詢 自動選擇 依然 還在 工具

爆炸式發展的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.預設計模式與動態模式
傳統數據庫設計思維中,項目的設計階段需要對數據庫表中的字段名稱、字段類型、進行規定,如果嘗試插入不符合設計的數據,數據庫不會接受這條數據以保證數據的完整性。

MySQL

--數據庫字段:NAME, SONG

INSERT INTO T_INFO VALUES(‘John‘,‘Come Together‘); --成功

INSERT INTO T_INFO VALUES(‘小明‘, 20, ‘[email protected]‘); --失敗
--數據庫字段:NAME, SONG

INSERT INTO T_INFO VALUES(‘John‘,‘Come Together‘); --成功

INSERT INTO T_INFO VALUES(‘小明‘, 20, ‘[email protected]‘); --失敗
NoSQL采用的是對集合(類似”表”)中的文檔(類似於”行”)進行動態追加,在創建集合之初不會對數據類型進行限定,任何文檔都可以追加到任何集合中去,例如我們可以將這樣兩條文檔添加到一個集合中去:

MySQL

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

{"name" : "小明", "age":"20", "email" : "[email protected]"}
{"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