如何學習及選擇大數據非關系型數據庫NoSQL

是的，NoSQL（非關系型數據庫）簡單來說，關系模型指的就是二維表格模型，而一個關系型數據庫就是由二維表及其之間的聯系組成的一個數據組織。 NoSQL最普遍的解釋是“非關系型的”，強調Key-Value Stores和文檔數據庫的優點，而不是單純的反對RDBMS。

成都創新互聯公司網站建設服務商，為中小企業提供成都網站建設、成都做網站服務，網站設計，綿陽服務器托管等一站式綜合服務型公司，專業打造企業形象網站，讓您在眾多競爭對手中脫穎而出成都創新互聯公司。

非關系型數據庫特點

1.可以處理超大量的數據。

2.運行在便宜的PC服務器集群上。PC集群擴充起來非常方便并且成本很低，避免了“sharding”操作的復雜性和成本。

3.擊碎了性能瓶頸。NoSQL的支持者稱，通過NoSQL架構可以省去將Web或Java應用和數據轉換成SQL友好格式的時間，執行速度變得更快。

4.沒有過多的操作。

5.支持者來源于社區。因為NoSQL項目都是開源的，因此它們缺乏供應商提供的正式支持。這一點它們與大多數開源項目一樣，不得不從社區中尋求支持。

為什么海量數據場景中NoSQL越來越重要

本質是因為：隨著互聯網的進一步發展與各行業信息化建設進程加快、參與者的增多，人們對軟件有了更多更新的要求，需要軟件不僅能實現功能，而且要求保證許多人可以共同參與使用，因而軟件所需承載的數據量和吞吐量必須達到相應的需求。而目前的關系型數據庫在某些方面有一些缺點，導致不能滿足需要。

具體則需要對比關系型數據庫與Nosql之間的區別可以得出

關系型數據庫

關系型數據庫把所有的數據都通過行和列的二元表現形式表示出來。

關系型數據庫的優勢：

1.?保持數據的一致性（事務處理）

2.由于以標準化為前提，數據更新的開銷很小（相同的字段基本上都只有一處）

3.?可以進行Join等復雜查詢

其中能夠保持數據的一致性是關系型數據庫的最大優勢。

關系型數據庫的不足：

不擅長的處理

1.?大量數據的寫入處理（這點尤為重要）

2.?為有數據更新的表做索引或表結構（schema）變更

3.?字段不固定時應用

4.?對簡單查詢需要快速返回結果的處理

--大量數據的寫入處理

讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站已使用主從復制技術實現讀寫分離，以提高讀寫性能和讀庫的可擴展性。

所以在進行大量數據操作時，會使用數據庫主從模式。數據的寫入由主數據庫負責，數據的讀入由從數據庫負責，可以比較簡單地通過增加從數據庫來實現規模化，但是數據的寫入卻完全沒有簡單的方法來解決規模化問題。

第一，要想將數據的寫入規模化，可以考慮把主數據庫從一臺增加到兩臺，作為互相關聯復制的二元主數據庫使用，確實這樣可以把每臺主數據庫的負荷減少一半，但是更新處理會發生沖突，可能會造成數據的不一致，為了避免這樣的問題，需要把對每個表的請求分別分配給合適的主數據庫來處理。

第二，可以考慮把數據庫分割開來，分別放在不同的數據庫服務器上，比如將不同的表放在不同的數據庫服務器上，數據庫分割可以減少每臺數據庫服務器上的數據量，以便減少硬盤IO的輸入、輸出處理，實現內存上的高速處理。但是由于分別存儲字不同服務器上的表之間無法進行Join處理，數據庫分割的時候就需要預先考慮這些問題，數據庫分割之后，如果一定要進行Join處理，就必須要在程序中進行關聯，這是非常困難的。

--為有數據更新的表做索引或表結構變更

在使用關系型數據庫時，為了加快查詢速度需要創建索引，為了增加必要的字段就一定要改變表結構，為了進行這些處理，需要對表進行共享鎖定，這期間數據變更、更新、插入、刪除等都是無法進行的。如果需要進行一些耗時操作，例如為數據量比較大的表創建索引或是變更其表結構，就需要特別注意，長時間內數據可能無法進行更新。

--字段不固定時的應用

如果字段不固定，利用關系型數據庫也是比較困難的，有人會說，需要的時候加個字段就可以了，這樣的方法也不是不可以，但在實際運用中每次都進行反復的表結構變更是非常痛苦的。你也可以預先設定大量的預備字段，但這樣的話，時間一長很容易弄不清除字段和數據的對應狀態，即哪個字段保存有哪些數據。

--對簡單查詢需要快速返回結果的處理? （這里的“簡單”指的是沒有復雜的查詢條件）

這一點稱不上是缺點，但不管怎樣，關系型數據庫并不擅長對簡單的查詢快速返回結果，因為關系型數據庫是使用專門的sql語言進行數據讀取的，它需要對sql與越南進行解析，同時還有對表的鎖定和解鎖等這樣的額外開銷，這里并不是說關系型數據庫的速度太慢，而只是想告訴大家若希望對簡單查詢進行高速處理，則沒有必要非使用關系型數據庫不可。

NoSQL數據庫

關系型數據庫應用廣泛，能進行事務處理和表連接等復雜查詢。相對地，NoSQL數據庫只應用在特定領域，基本上不進行復雜的處理，但它恰恰彌補了之前所列舉的關系型數據庫的不足之處。

優點：

易于數據的分散

各個數據之間存在關聯是關系型數據庫得名的主要原因，為了進行join處理，關系型數據庫不得不把數據存儲在同一個服務器內，這不利于數據的分散，這也是關系型數據庫并不擅長大數據量的寫入處理的原因。相反NoSQL數據庫原本就不支持Join處理，各個數據都是獨立設計的，很容易把數據分散在多個服務器上，故減少了每個服務器上的數據量，即使要處理大量數據的寫入，也變得更加容易，數據的讀入操作當然也同樣容易。

典型的NoSQL數據庫

臨時性鍵值存儲（memcached、Redis）、永久性鍵值存儲（ROMA、Redis）、面向文檔的數據庫（MongoDB、CouchDB）、面向列的數據庫（Cassandra、HBase）

一、 鍵值存儲

它的數據是以鍵值的形式存儲的，雖然它的速度非常快，但基本上只能通過鍵的完全一致查詢獲取數據，根據數據的保存方式可以分為臨時性、永久性和兩者兼具 三種。

（1）臨時性

所謂臨時性就是數據有可能丟失，memcached把所有數據都保存在內存中，這樣保存和讀取的速度非常快，但是當memcached停止時，數據就不存在了。由于數據保存在內存中，所以無法操作超出內存容量的數據，舊數據會丟失。總結來說：

。在內存中保存數據

。可以進行非常快速的保存和讀取處理

。數據有可能丟失

（2）永久性

所謂永久性就是數據不會丟失，這里的鍵值存儲是把數據保存在硬盤上，與臨時性比起來，由于必然要發生對硬盤的IO操作，所以性能上還是有差距的，但數據不會丟失是它最大的優勢。總結來說：

。在硬盤上保存數據

。可以進行非常快速的保存和讀取處理（但無法與memcached相比）

。數據不會丟失

（3） 兩者兼備

Redis屬于這種類型。Redis有些特殊，臨時性和永久性兼具。Redis首先把數據保存在內存中，在滿足特定條件（默認是?15分鐘一次以上，5分鐘內10個以上，1分鐘內10000個以上的鍵發生變更）的時候將數據寫入到硬盤中，這樣既確保了內存中數據的處理速度，又可以通過寫入硬盤來保證數據的永久性，這種類型的數據庫特別適合處理數組類型的數據。總結來說：

。同時在內存和硬盤上保存數據

。可以進行非常快速的保存和讀取處理

。保存在硬盤上的數據不會消失（可以恢復）

。適合于處理數組類型的數據

二、面向文檔的數據庫

MongoDB、CouchDB屬于這種類型，它們屬于NoSQL數據庫，但與鍵值存儲相異。

（1）不定義表結構

即使不定義表結構，也可以像定義了表結構一樣使用，還省去了變更表結構的麻煩。

（2）可以使用復雜的查詢條件

跟鍵值存儲不同的是，面向文檔的數據庫可以通過復雜的查詢條件來獲取數據，雖然不具備事務處理和Join這些關系型數據庫所具有的處理能力，但初次以外的其他處理基本上都能實現。

三、?面向列的數據庫

Cassandra、HBae、HyperTable屬于這種類型，由于近年來數據量出現爆發性增長，這種類型的NoSQL數據庫尤其引入注目。

普通的關系型數據庫都是以行為單位來存儲數據的，擅長以行為單位的讀入處理，比如特定條件數據的獲取。因此，關系型數據庫也被成為面向行的數據庫。相反，面向列的數據庫是以列為單位來存儲數據的，擅長以列為單位讀入數據。

面向列的數據庫具有搞擴展性，即使數據增加也不會降低相應的處理速度（特別是寫入速度），所以它主要應用于需要處理大量數據的情況。另外，把它作為批處理程序的存儲器來對大量數據進行更新也是非常有用的。但由于面向列的數據庫跟現行數據庫存儲的思維方式有很大不同，故應用起來十分困難。

總結：關系型數據庫與NoSQL數據庫并非對立而是互補的關系，即通常情況下使用關系型數據庫，在適合使用NoSQL的時候使用NoSQL數據庫，讓NoSQL數據庫對關系型數據庫的不足進行彌補。

為什么選擇NoSQL數據庫如此困難

傳統觀念中 NoSQL數據庫非常適合某些數據類型，如：非關系數據源。同時，NoSQL被吹捧為最適合Web應用程序的優秀平臺。然而他適合大多數數據，特別是web應用程序的數據是相關型。那么，這是否可以給你一個堅持使用RDMS的理由呢？也不一定，即使很困難，我們還是要做出選擇。

評估NoSQL是一個很茅盾的理論，一些人認為，應該將所有文檔數據存儲在一個文檔中，做鏈接代碼就是褻瀆神明。另外一部分人認為，存儲應用文檔，加入代碼，才是合理選擇。與此同時，不同的數據庫，需要在文檔中限制嵌套數據數量。有的人會鼓勵文檔引用。這是NoSQL數據模型的基本部分，也沒有一個明確的共識。

曾經有一篇很熱的帖子"Why you should never use XYZ"，我想，讀到這里，一定會有人搜索這篇文章。當然，這種文章各式各樣，太過于籠統的標題也沒什么幫助。毫無疑問，會有人會搜索這個文章，然后再找

到這個文章，進一步深入，找到該文章的方法遠比成功（理解問題）的故事多。很難知道誰提供了一個有效的技術問題，誰又誤讀了這個問題（或者缺少證據證明其觀點）。

有大量選擇，RDBMS的世界，選擇就很容易。你有4或5個目標，大家工作方式差不多，來選擇環境、預算支持的平臺。對于成熟的產品，風險比較小。 NoSQL的世界，有很多數據庫引擎功能選擇。每一個有自己的獨特優勢，也有致命弱點。所以選擇很難， NoSQL項目生命周期短，嘗試新項目或者流行項目也會有風險。上次，我的的項目是在 CouchDB上，而現在似乎停擺了。

做出這個痛苦決定的原因是，這可能是一個案例：你需要做一大堆工作，才能知道，你做出的選擇對與錯。你可以實體化你的數據模型，了解他與系統的工作情況，但是，這只有你正真撞到南墻，才可以找到裂縫（答案）。以我為例，我建的應用程序是關系數據庫，移動文件存儲的主要因素是，需要一個無模式設計來達到我的目標。使用NoSQL 數據庫存儲關系型數據庫并不是我們所常說的，雖然，這種事常常發生。

現在我在用 Couchbase 和 MongoDB，Mongo對我沒多大吸引力，不過鑒于他非常流行，對于引起來說，很有好處。當然，很多都可以以同樣的方式流行。PHP很流行，因為他的易用性，而不是因為他很好。

新聞標題：學習nosql的原因,談談NoSQL數據庫誕生的原因和優缺點
本文路徑：http://www.yijiale78.com/article6/dsccjig.html

成都網站建設公司_創新互聯，為您提供小程序開發、外貿網站建設、定制開發、企業網站制作、手機網站建設、網站維護

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯