Redis之NoSql入門和概述(二)

2. 什麼是NoSQL？

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL )，意即「不只僅是SQL」，泛指非關係型的數據庫。隨着互聯網web2.0網站的興起，傳統的關係數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了不少難以克服的問題，而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤爲是大數據應用難題，包括超大規模數據的存儲

2.2經常使用的NoSql數據庫

NoSQL數據庫種類繁多，這些類型的數據存儲不須要固定的模式，無需多餘操做就能夠橫向擴展，經常使用的Redis、Memcache、Mongdb、Hbase等。

2.3NoSql數據庫特色

*易擴展

NoSQL數據庫種類繁多，可是一個共同的特色都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就很是容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

*大數據量高性能

NoSQL數據庫都具備很是高的讀寫性能，尤爲在大數據量下，一樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。通常MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，因此NoSQL在這個層面上來講就要性能高不少了

*多樣靈活的數據模型

NoSQL無需事先爲要存儲的數據創建字段，隨時能夠存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件很是麻煩的事情。若是是很是大數據量的表，增長字段簡直就是一個噩夢

2.4NOSql數據庫與關係型數據庫比較

	NoSql數據庫	關係型數據庫
比較	- 表明着不只僅是SQL - 沒有聲明性查詢語言 -無預約義的模式（數據格式） -鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫 - 最終一致性，而非ACID屬性 - 非結構化和不可預知的數據 - CAP定理 - 高性能，高可用性和可伸縮性	- 高度組織化結構化數據 - 結構化查詢語言（SQL） - 數據和關係都存儲在單獨的表中。 - 數據操縱語言，數據定義語言 - 嚴格的一致性 - 基礎事務

2.4在分佈式數據庫中CAP原理CAP+BASE

2.4.1傳統的ACID分別是什麼？

事務在當今的企業系統無處不在，即便在高併發環境下也能夠提供數據的完整性。一個事務是一個只包含全部讀/寫操做成功的集合 ，一句話就是多條SQL語句，要麼全部執行成功，要麼全部執行失敗。ACID也就是事務的四個特色（原則）

原子性（Atomicity）

原子性是指事務是一個不可分割的工做單位，事務中的操做要麼都發生，要麼都不發生。

一致性（Consistency）

事務先後數據的完整性必須保持一致。

隔離性（Isolation）

事務的隔離性是多個用戶併發訪問數據庫時，數據庫爲每個用戶開啓的事務，不能被其餘事務的操做數據所幹擾，多個併發事務之間要相互隔離。

持久性（Durability）

持久性是指一個事務一旦被提交，它對數據庫中數據的改變就是永久性的，接下來即便數據庫發生故障也不該該對其有任何影響

2.4.2CAP原理

CAP原則又稱CAP定理，指的是在一個分佈式系統中，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。

一致性（C）

是指更新操做成功並返回客戶端後，全部節點在同一時間的數據徹底一致，這就是分佈式的一致性。一致性的問題在併發系統中不可避免，對於客戶端來講，一致性指的是併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。

可用性（A）

服務一直可用，並且是正常響應時間。好的可用性主要是指系統可以很好的爲用戶服務，不出現用戶操做失敗或者訪問超時等用戶體驗很差的狀況。

分區容錯性（P）：

即分佈式系統在遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性或可用性的服務。分區容錯性要求可以使應用雖然是一個分佈式系統，而看上去卻好像是在一個能夠運轉正常的總體。好比如今的分佈式系統中有某一個或者幾個機器宕掉了，其餘剩下的機器還可以正常運轉知足系統需求，對於用戶而言並無什麼體驗上的影響。

2.4.3CAP的3進2原則

CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。也就是說要麼AP，要麼CP，要麼AC，不存在CAP，

可是而因爲當前的網絡硬件確定會出現延遲丟包等問題，因此分區容忍性是咱們必須須要實現的。因此咱們只能在一致性和可用性之間進行權衡，要麼AP，要麼CP

備註：分佈式架構的時候必須作出取捨，一致性和可用性之間取一個平衡。多餘大多數web應用，其實並不須要強一致性。所以犧牲C換取P，這是目前分佈式數據庫產品的方向

2.4.4 經典CAP圖

CAP理論的核心是：一個分佈式系統不可能同時很好的知足一致性，可用性和分區容錯性這三個需求，最多隻能同時較好的知足兩個。

根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三 大類：

CA - 單點集羣，知足一致性，可用性的系統，一般在可擴展性上不太強大。

CP - 知足一致性，分區容忍必的系統，一般性能不是特別高。

AP - 知足可用性，分區容忍性的系統，一般可能對一致性要求低一

2.4.5一致性與可用性的決擇

CA 傳統Oracle數據庫 AP 大多數網站架構的選擇 CP Redis、Mongodb

對於web2.0網站來講，關係數據庫的不少主要特性卻每每無用武之地

數據庫事務一致性需求

　　不少web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求並不高。容許實現最終一致性。

數據庫的寫實時性和讀實時性需求

　　對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出來這條數據的，可是對於不少web應用來講，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒以後，個人訂閱者纔看到這條動態是徹底能夠接受的。

對複雜的SQL查詢，特別是多表關聯查詢的需求

　　任何大數據量的web系統，都很是忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。