瞭解NoSQL

時間 2019-11-19

標籤瞭解 nosql 欄目 NoSQL 简体版

原文原文鏈接

近期老是提到NoSQL這個詞彙。起初僅僅知道，應該是一種數據庫而已，僅僅是這樣的數據庫眼下符合當前互聯網的需求，應用比較普遍。逐漸發現，當前的各個公司在招聘信息中會有掌握NoSQL的優先等要求。因而，抱着好奇的心理，來查了一些資料，並進行了整理，來分享給你們！

如下的內容來源於百度百科

NoSQL，泛指非關係型的數據庫。

隨着互聯網web2.0站點的興起，傳統的關係數據庫在應付web2.0站點，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很是多難以克服的問題。而非關係型的數據庫則由於其自己的特色獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤爲是大數據應用難題。web

雖然NoSQL流行語火起來才短短一年的時間，但是不能否認，現在已經開始了第二代運動。雖然早期的堆棧代碼僅僅能算是一種實驗，然而現在的系統已經更加的成熟、穩定。只是現在也面臨着一個嚴酷的事實：技術愈來愈成熟——以致於原來很是好的NoSQL數據存儲不得不進行重寫。也有少數人以爲這就是所謂的2.0版本號。這裏列出一些比較知名的工具。可以爲大數據創建高速、可擴展的存儲庫。

基本含義

NoSQL(NoSQL = Not Only SQL )，意即「不不過 SQL 」，是一項全新的數據庫革命性運動，早期就有人提出，發展至2009年趨勢愈加高漲。NoSQL的擁護者們提倡運用非關係型的數據存儲，相對於鋪天蓋地的關係型數據庫運用，這一律念無疑是一種全新的思惟的注入。

NNoSQL數據庫的四大分類

鍵值( Key-Value )存儲數據庫

這一類數據庫主要會使用到一個 哈希表。 這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來講的優點在於簡單、易部署。

但是假設DBA僅僅對部分值進行查詢或更新的時候。Key/value就顯得效率低下了。^[3] 舉好比：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.面試

列存儲數據庫。

這部分數據庫通常是用來應對分佈式存儲的海量數據。鍵仍然存在，但是它們的特色是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.

文檔型數據庫

文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相相似。

該類型的數據模型是版本號化的文檔。半結構化的文檔以特定的格式存儲，比方JSON。文檔型數據庫可以看做是鍵值數據庫的升級版，贊成之間嵌套鍵值。算法

而且文檔型數據庫比鍵值數據庫的查詢效率更高。如：CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB，已經開源。sql

圖形(Graph)數據庫

圖形結構的數據庫同其它行列以及剛性結構的SQL數據庫不一樣，它是使用靈活的圖形模型。並且能夠擴展到多個server上。

NoSQL數據庫沒有標準的查詢語言(SQL)，所以進行數據庫查詢需要制定數據模型。不少NoSQL數據庫都有REST式的數據接口或者查詢API。數據庫

^[2] 如：Neo4J, InfoGrid, Infinite Graph.緩存

所以，咱們總結NoSQL數據庫在下面的這幾種狀況下比較適用：一、數據模型比較簡單；二、需要靈活性更強的IT系統；三、對數據庫性能要求較高。四、不需要高度的數據一致性。五、對於給定key，比較easy映射覆雜值的環境。

3NoSQL數據庫的四大分類表格分析

分類	Examples舉例	典型應用場景	數據模型	長處	缺點
鍵值（key-value）	Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB	內容緩存，主要用於處理大量數據的高訪問負載，也用於一些日誌系統等等。	Key 指向 Value 的鍵值對，通常用hash table來實現	查找速度快	數據無結構化，一般僅僅被看成字符串或者二進制數據
列存儲數據庫	Cassandra, HBase, Riak	分佈式的文件系統	以列簇式存儲，將同一列數據存在一塊兒	查找速度快。可擴展性強。更easy進行分佈式擴展	功能相對侷限
文檔型數據庫	CouchDB, MongoDb	Web應用（與Key-Value相似，Value是結構化的，不一樣的是數據庫能夠了解Value的內容）	Key-Value相應的鍵值對，Value爲結構化數據	數據結構要求不嚴格。表結構可變，不需要像關係型數據庫同樣需要預先定義表結構	查詢性能不高。而且缺少統一的查詢語法。
圖形(Graph)數據庫	Neo4J, InfoGrid, Infinite Graph	社交網絡，推薦系統等。專一於構建關係圖譜安全	圖結構	利用圖結構相關算法。比方最短路徑尋址，N度關係查找等	很是多時候需要對整個圖作計算才幹得出需要的信息，而且這樣的結構不太好作分佈式的集羣方案。 ^[3] 網絡

4

對於NoSQL並無一個明白的範圍和定義，但是他們都廣泛存在如下一些共同特徵：

不需要提早定義模式：不需要共同特徵事先定義數據模式，提早定義表結構。數據中的每條記錄均可能有不一樣的屬性和格式。

當插入數據時，並不需要預先定義它們的模式。數據結構
無共享架構：相對於將所有數據存儲的存儲區域網絡中的全共享架構。NoSQL每每將數據劃分後存儲在各個本地server上。因爲從本地磁盤讀取數據的性能每每好於經過網絡傳輸讀取數據的性能，從而提升了系統的性能。
彈性可擴展：可以在系統執行的時候，動態添加或者刪除結點。不需要停機維護。數據可以本身主動遷移。
分區：相對於將數據存放於同一個節點，NoSQL數據庫需要將數據進行分區。將記錄分散在多個節點上面。並且一般分區的同一時候還要作複製。這樣既提升了並行性能，又能保證沒有單點失效的問題。
異步複製：和RAID存儲系統不一樣的是。NoSQL中的複製，每每是基於日誌的異步複製。

這樣。數據就可以儘快地寫入一個節點，而不會被網絡傳輸引發拖延。缺點是並不老是能保證一致性，這種方式在出現問題的時候。可能會丟失少許的數據。架構
BASE：相對於事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。

BASE是終於一致性和軟事務。

NoSQL數據庫並無一個統一的架構，兩種NoSQL數據庫之間的不一樣，甚至遠遠超過兩種關係型數據庫的不一樣。

可以說，NoSQL各有所長。成功的NoSQL一定特別適用於某些場合或者某些應用，在這些場合中會遠遠賽過關係型數據庫和其它的NoSQL。

NoSQL數據庫的四大分類

鍵值(Key-Value)存儲數據庫
這一類數據庫主要會使用到一個哈希表。這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來講的優點在於簡單、易部署。但是假設DBA僅僅對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。

[3] 舉好比：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存儲數據庫。
這部分數據庫通常是用來應對分佈式存儲的海量數據。鍵仍然存在。但是它們的特色是指向了多個列。這些列是由列家族來安排的。

如：Cassandra, HBase, Riak.
文檔型數據庫
文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相相似。該類型的數據模型是版本號化的文檔。半結構化的文檔以特定的格式存儲，比方JSON。文檔型數據庫可以看做是鍵值數據庫的升級版。贊成之間嵌套鍵值。而且文檔型數據庫比鍵值數據庫的查詢效率更高。如：CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB，已經開源。

圖形(Graph)數據庫
圖形結構的數據庫同其它行列以及剛性結構的SQL數據庫不一樣，它是使用靈活的圖形模型，並且能夠擴展到多個server上。

NoSQL數據庫沒有標準的查詢語言(SQL)，所以進行數據庫查詢需要制定數據模型。不少NoSQL數據庫都有REST式的數據接口或者查詢API。

[2] 如：Neo4J, InfoGrid, Infinite Graph.
所以，咱們總結NoSQL數據庫在下面的這幾種狀況下比較適用：一、數據模型比較簡單；二、需要靈活性更強的IT系統。三、對數據庫性能要求較高；四、不需要高度的數據一致性；五、對於給定key，比較easy映射覆雜值的環境。

3NoSQL數據庫的四大分類表格分析

分類 Examples舉例典型應用場景數據模型長處缺點
鍵值（key-value）[3] Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB 內容緩存，主要用於處理大量數據的高訪問負載，也用於一些日誌系統等等。[3] Key 指向 Value 的鍵值對。通常用hash table來實現[3] 查找速度快數據無結構化，一般僅僅被看成字符串或者二進制數據[3]
列存儲數據庫[3] Cassandra, HBase, Riak 分佈式的文件系統以列簇式存儲。將同一列數據存在一塊兒查找速度快，可擴展性強。更easy進行分佈式擴展功能相對侷限
文檔型數據庫[3] CouchDB, MongoDb Web應用（與Key-Value相似，Value是結構化的，不一樣的是數據庫能夠了解Value的內容） Key-Value相應的鍵值對，Value爲結構化數據數據結構要求不嚴格。表結構可變。不需要像關係型數據庫同樣需要預先定義表結構查詢性能不高，而且缺少統一的查詢語法。
圖形(Graph)數據庫[3] Neo4J, InfoGrid, Infinite Graph 社交網絡。推薦系統等。

專一於構建關係圖譜圖結構利用圖結構相關算法。比方最短路徑尋址，N度關係查找等很是多時候需要對整個圖作計算才幹得出需要的信息，而且這樣的結構不太好作分佈式的集羣方案。[3]
4共同特徵

對於NoSQL並無一個明白的範圍和定義。但是他們都廣泛存在如下一些共同特徵：
不需要提早定義模式：不需要事先定義數據模式，提早定義表結構。

數據中的每條記錄均可能有不一樣的屬性和格式。當插入數據時。並不需要預先定義它們的模式。

無共享架構：相對於將所有數據存儲的存儲區域網絡中的全共享架構。NoSQL每每將數據劃分後存儲在各個本地server上。

因爲從本地磁盤讀取數據的性能每每好於經過網絡傳輸讀取數據的性能，從而提升了系統的性能。
彈性可擴展：可以在系統執行的時候。動態添加或者刪除結點。不需要停機維護，數據可以本身主動遷移。

分區：相對於將數據存放於同一個節點，NoSQL數據庫需要將數據進行分區，將記錄分散在多個節點上面。並且一般分區的同一時候還要作複製。這樣既提升了並行性能。又能保證沒有單點失效的問題。

異步複製：和RAID存儲系統不一樣的是，NoSQL中的複製，每每是基於日誌的異步複製。

這樣，數據就可以儘快地寫入一個節點。而不會被網絡傳輸引發拖延。缺點是並不老是能保證一致性。這種方式在出現問題的時候。可能會丟失少許的數據。
BASE：相對於事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。BASE是終於一致性和軟事務。
NoSQL數據庫並無一個統一的架構，兩種NoSQL數據庫之間的不一樣，甚至遠遠超過兩種關係型數據庫的不一樣。可以說，NoSQL各有所長。成功的NoSQL一定特別適用於某些場合或者某些應用，在這些場合中會遠遠賽過關係型數據庫和其它的NoSQL。
5適用場景

NoSQL數據庫在下面的這幾種狀況下比較適用：一、數據模型比較簡單；二、需要靈活性更強的IT系統；三、對數據庫性能要求較高。四、不需要高度的數據一致性。五、對於給定key。比較easy映射覆雜值的環境。
6發展示狀

計算機體系結構在數據存儲方面要求具有龐大的水平擴展性。而NoSQL致力於改變這一現狀。Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型數據庫。
NoSQL項目的名字上看不出什麼一樣之處，但是，它們一般在某些方面一樣：它們可以處理超大量的數據。
這場革命仍然需要等待。的確，NoSQL對大型企業來講還不是主流，但是，一兩年以後很是可能就會變個樣子。在NoSQL運動的最新一次聚會中，來自世界各地的150人擠滿了CBS Interactive的一間會議室。

分享他們如何推翻緩慢而昂貴的關係數據庫的暴政的經驗。如何使用更有效和更廉價的方法來管理數據。

「關係型數據庫給你強加了太多東西。它們要你強行改動對象數據。以知足RDBMS （relational database management system。關係型數據庫管理系統）的需要，」在NoSQL擁護者們看來，基於NoSQL的替代方案「僅僅是給你所需要的」。
水平擴展性(horizontal scalability)指能夠鏈接多個軟硬件的特性,這樣能夠將多個server從邏輯上當作一個實體。
7挑戰

雖然大多數NoSQL數據存儲系統都已被部署於實際應用中，但概括其研究現狀，還有不少挑戰性問題。
已有key-value數據庫產品大可能是面向特定應用自治構建的，缺少通用性；
已有產品支持的功能有限（不支持事務特性），致使其應用具備必定的侷限性；
已有一些研究成果和改進的NoSQL數據存儲系統，但它們都是針對不一樣應用需求而提出的對應解決方式，如支持組內事務特性、彈性事務等，很是少從全局考慮系統的通用性。也沒有造成系列化的研究成果；
缺少相似關係數據庫所具備的強有力的理論(如armstrong公理系統)、技術（如成熟的基於啓示式的優化策略、兩段封鎖協議等）、標準規範（如SQL語言）的支持。
眼下，HBase數據庫時安全特性最無缺的NoSQL數據庫產品之中的一個，而其它的NoSQL數據庫多數沒有提供內建的安全機制，但隨着NoSQL的發展，愈來愈多的人開始意識到安全的重要。部分NoSQL產品逐漸開始提供一些安全方面的支持。
隨着雲計算、互聯網等技術的發展，大數據普遍存在，同一時候也呈現出了不少雲環境下的新型應用，如社交網絡網、移動服務、協做編輯等。這些新型應用對海量數據管理或稱雲數據管理系統也提出了新的需求。如事務的支持、系統的彈性等。同一時候雲計算時代海量數據管理系統的設計目標爲可擴展性、彈性、容錯性、自管理性和「強一致性」。

眼下，已有系統經過支持可任意增減節點來知足可擴展性；經過副本策略保證系統的容錯性。基於監測的狀態消息協調實現系統的自管理性。「彈性」的目標是知足Pay-per-use 模型，以提升系統資源的利用率。該特性是已有典型NoSQL數據庫系統所不無缺的，但倒是雲系統應具備的典型特色；「強一致性」主要是新應用的需求。

NoSQL數據庫在下面的這幾種狀況下比較適用：一、數據模型比較簡單。二、需要靈活性更強的IT系統；三、對數據庫性能要求較高；四、不需要高度的數據一致性；五、對於給定key。比較easy映射覆雜值的環境。

6發展示狀

計算機體系結構在數據存儲方面要求具有龐大的水平擴展性，而NoSQL致力於改變這一現狀。

Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型數據庫。

NoSQL項目的名字上看不出什麼一樣之處。但是，它們一般在某些方面一樣：它們可以處理超大量的數據。

這場革命仍然需要等待。

的確，NoSQL對大型企業來講還不是主流，但是，一兩年以後很是可能就會變個樣子。在NoSQL運動的最新一次聚會中。來自世界各地的150人擠滿了CBS Interactive的一間會議室。

分享他們如何推翻緩慢而昂貴的關係數據庫的暴政的經驗，如何使用更有效和更廉價的方法來管理數據。

「關係型數據庫給你強加了太多東西。

它們要你強行改動對象數據。以知足RDBMS （relational database management system。關係型數據庫管理系統）的需要。」在NoSQL擁護者們看來。基於NoSQL的替代方案「僅僅是給你所需要的」。

水平擴展性(horizontal scalability)指能夠鏈接多個軟硬件的特性,這樣能夠將多個server從邏輯上當作一個實體。

7挑戰

雖然大多數NoSQL數據存儲系統都已被部署於實際應用中。但概括其研究現狀，還有不少挑戰性問題。

已有key-value數據庫產品大可能是面向特定應用自治構建的。缺少通用性。
已有產品支持的功能有限（不支持事務特性），致使其應用具備必定的侷限性；
已有一些研究成果和改進的NoSQL數據存儲系統，但它們都是針對不一樣應用需求而提出的對應解決方式，如支持組內事務特性、彈性事務等，很是少從全局考慮系統的通用性。也沒有造成系列化的研究成果；
缺少相似關係數據庫所具備的強有力的理論(如armstrong公理系統)、技術（如成熟的基於啓示式的優化策略、兩段封鎖協議等）、標準規範（如SQL語言）的支持。
眼下，HBase數據庫時安全特性最無缺的NoSQL數據庫產品之中的一個，而其它的NoSQL數據庫多數沒有提供內建的安全機制，但隨着NoSQL的發展，愈來愈多的人開始意識到安全的重要，部分NoSQL產品逐漸開始提供一些安全方面的支持。

隨着雲計算、互聯網等技術的發展。大數據普遍存在，同一時候也呈現出了不少雲環境下的新型應用，如社交網絡網、移動服務、協做編輯等。這些新型應用對海量數據管理或稱雲數據管理系統也提出了新的需求，如事務的支持、系統的彈性等。同一時候雲計算時代海量數據管理系統的設計目標爲可擴展性、彈性、容錯性、自管理性和「強一致性」。眼下，已有系統經過支持可任意增減節點來知足可擴展性；經過副本策略保證系統的容錯性。基於監測的狀態消息協調實現系統的自管理性。「彈性」的目標是知足Pay-per-use 模型。以提升系統資源的利用率。該特性是已有典型NoSQL數據庫系統所不無缺的，但倒是雲系統應具備的典型特色。「強一致性」主要是新應用的需求。

如下的內容借鑑：http://www.infoq.com/cn/news/2011/01/nosql-why/

NOSQL的優點

易擴展

NoSQL數據庫種類繁多，但是一個共同的特色都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就很easy擴展。

也無形之間。在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL數據庫都具備很是高的讀寫性能，尤爲在大數據量下。相同表現優秀。這得益於它的無關係性，數據庫的結構簡單。

通常MySQL使用Query Cache。每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用。Cache性能不高。而NoSQL的Cache是記錄級的。是一種細粒度的Cache，因此NoSQL在這個層面上來講就要性能高很是多了。

靈活的數據模型

NoSQL無需事先爲要存儲的數據創建字段，隨時可以存儲本身定義的數據格式。而在關係數據庫裏，增刪字段是一件很麻煩的事情。假設是很大數據量的表。添加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤爲明顯。

高可用

NoSQL在不太影響性能的狀況，就可以方便的實現高可用的架構。比方Cassandra，HBase模型，經過複製模型也能實現高可用。

總結

NoSQL數據庫的出現。彌補了關係數據（比方MySQL）在某些方面的不足，在某些方面能極大的節省開發成本和維護成本。

MySQL和NoSQL都有各自的特色和使用的應用場景，二者的緊密結合將會給web2.0的數據庫發展帶來新的思路。

讓關係數據庫關注在關係上。NoSQL關注在存儲上。

傳統關係數據庫的瓶頸

傳統的關係數據庫具備不錯的性能。高穩定型，久經歷史考驗，而且使用簡單，功能強大。同一時候也積累了大量的成功案例。

在互聯網領域，MySQL成爲了絕對靠前的王者，絕不誇張的說，MySQL爲互聯網的發展作出了卓越的貢獻。

在90年代，一個站點的訪問量通常都不大，用單個數據庫全然可以輕鬆應付。在那個時候，不少其它的都是靜態網頁，動態交互類型的站點很少。

到了近期10年。站點開始高速發展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。

在初期。論壇的流量事實上也不大。假設你接觸網絡比較早。你可能還記得那個時候還有文本型存儲的論壇程序，可以想象通常的論壇的流量有多大。

Memcached+MySQL

後來。隨着訪問量的上升。差點兒大部分使用MySQL架構的站點在數據庫上都開始出現了性能問題，web程序再也不只專一在功能上。同一時候也在追求性能。

程序猿們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力。但是當訪問量繼續增大的時候，多臺web機器經過文件緩存不能共享。大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就天然的成爲一個很時尚的技術產品。

Memcached做爲一個獨立的分佈式的緩存server，爲多個webserver提供了一個共享的高性能緩存服務。在Memcachedserver上，又發展了依據hash算法來進行多臺Memcached緩存服務的擴展，而後又出現了一致性hash來解決添加或下降緩存server致使又一次hash帶來的大量緩存失效的弊端。當時，假設你去面試，你說你有Memcached經驗，確定會加分的。