傳統關係數據庫與分佈式數據庫知識點

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

NoSQL數據庫種類繁多,但是一個共同的特點都是去掉關係數據庫的關係型特性。
數據之間無關係,這樣就非常容易擴展。也無形之間,在架構的層面上帶來了可擴展的能力。
大數據量高性能
NoSQL數據庫都具有非常高的讀寫性能,尤其在大數據量下,同樣表現優秀。
這得益於它的無關係性,數據庫的結構簡單。
一般MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,
在針對web2.0的交互頻繁的應用,Cache性能不高。而NoSQL的Cache是記錄級的,
是一種細粒度的Cache,所以NoSQL在這個層面上來說就要性能高很多了
多樣靈活的數據模型
NoSQL無需事先爲要存儲的數據建立字段,隨時可以存儲自定義的數據格式。而在關係數據庫裏,增刪字段是一件非常麻煩的事情。如果是非常大數據量的表,增加字段簡直就是一個噩夢
傳統RDBMS VS NOSQL
RDBMS

- 高度組織化結構化數據
- 結構化查詢語言(SQL)
- 數據和關係都存儲在單獨的表中。
- 數據操縱語言,數據定義語言
- 嚴格的一致性
- 基礎事務
NoSQL
- 代表着不僅僅是SQL
- 沒有聲明性查詢語言
- 沒有預定義的模式
-鍵 - 值對存儲,列存儲,文檔存儲,圖形數據庫
- 最終一致性,而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能,高可用性和可伸縮性
大數據的3V+3高
大數據時代的3V

海量Volume
多樣Variety
實時Velocity
互聯網需求的3高
高併發
高可擴
高性能
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數據庫不同,它是使用靈活的圖形模型,並且能夠擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL),因此進行數據庫查詢需要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。[2] 如:Neo4J, InfoGrid, Infinite Graph.
因此,我們總結NoSQL數據庫在以下的這幾種情況下比較適用:1、數據模型比較簡單;2、需要靈活性更強的IT系統;3、對數據庫性能要求較高;4、不需要高度的數據一致性;5、對於給定key,比較容易映射覆雜值的環境。
NoSQL數據庫的四大分類表格分析



分佈式系統(distributed system)

 由多臺計算機和通信的軟件組件通過計算機網絡連接(本地網絡或廣域網)組成。分佈式系統是建立在網絡之上的軟件系統。正是因爲軟件的特性,所以分佈式系統具有高度的內聚性和透明性。因此,網絡和分佈式系統之間的區別更多的在於高層軟件(特別是操作系統),而不是硬件。分佈式系統可以應用在在不同的平臺上如:Pc、工作站、局域網和廣域網上等。

傳統關係型數據庫遵循ACID

規則事務在英文中是transaction,它有如下四個特性:
1、A (Atomicity) 原子性
原子性很容易理解,也就是說事務裏的所有操作要麼全部做完,要麼都不做,事務成功的條件是事務裏的所有操作都成功,只要有一個操作失敗,整個事務就失敗,需要回滾。比如銀行轉賬,從A賬戶轉100元至B賬戶,分爲兩個步驟:1)從A賬戶取100元;2)存入100元至B賬戶。這兩步要麼一起完成,要麼一起不完成,如果只完成第一步,第二步失敗,錢會莫名其妙少了100元。
2、C (Consistency) 一致性
一致性也比較容易理解,也就是說數據庫要一直處於一致的狀態,事務的運行不會改變數據庫原本的一致性約束。
3、I (Isolation) 獨立性
所謂的獨立性是指併發的事務之間不會互相影響,如果一個事務要訪問的數據正在被另外一個事務修改,只要另外一個事務未提交,它所訪問的數據就不受未提交事務的影響。比如現有有個交易是從A賬戶轉100元至B賬戶,在這個交易還未完成的情況下,如果此時B查詢自己的賬戶,是看不到新增加的100元的
4、D (Durability) 持久性
持久性是指一旦事務提交後,它所做的修改將會永久的保存在數據庫上,即使出現宕機也不會丟失。



在分佈式數據庫中CAP原理CAP+BASE:
CAP概念:
C:Consistency:強一致性,A:Availability:可用性,P:Partition tolerance:分區容錯性。
CAP理論的核心是:一個分佈式系統不可能同時很好的滿足一致性,可用性和分區容錯性這三個需求, 
最多隻能同時較好的滿足兩個。
因此,根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類: 
CA - 單點集羣,滿足一致性,可用性的系統,通常在可擴展性上不太強大。(msyql/Oracle); 
CP - 滿足一致性,分區容忍性的系統,通常性能不是特別高。(Redis/mongdb); 
AP - 滿足可用性,分區容忍性的系統,通常可能對一致性要求低一些。(大多數網站架構選擇如淘寶,京東);
BASE就是爲了解決關係數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
BASE其實是下面三個術語的縮寫: 

基本可用(Basically Available) 

基本可用是指分佈式系統在出現故障的時候,允許損失部分可用性,即保證核心可用。
電商大促時,爲了應對訪問量激增,部分用戶可能會被引導到降級頁面,服務層也可能只提供降級服務。這就是損失部分可用性的體現。

軟狀態(Soft state) 

軟狀態是指允許系統存在中間狀態,而該中間狀態不會影響系統整體可用性。分佈式存儲中一般一份數據至少會有三個副本,允許不同節點間副本同步的延時就是軟狀態的體現。mysql replication的異步複製也是一種體現。

最終一致(Eventually consistent)

最終一致性是指系統中的所有數據副本經過一定時間後,最終能夠達到一致的狀態。弱一致性和強一致性相反,最終一致性是弱一致性的一種特殊情況。


它的思想是通過讓系統放鬆對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。爲什麼這麼說呢,緣由就在於大型系統往往由於地域分佈和極高性能的要求,不可能採用分佈式事務來完成這些指標,要想獲得這些指標,我們必須採用另外一種方式來完成,這裏BASE就是解決這個問題的辦法。


簡單來講:
1分佈式:不同的多臺服務器上面部署不同的服務模塊(工程),他們之間通過Rpc/Rmi之間通信和調用,對外提供服務和組內協作。

2集羣:不同的多臺服務器上面部署相同的服務模塊,通過分佈式調度軟件進行統一的調度,對外提供服務和訪問。

ACID和BASE的區別與聯繫
ACID是傳統數據庫常用的設計理念,追求強一致性模型。BASE支持的是大型分佈式系統,提出通過犧牲強一致性獲得高可用性
ACID和BASE代表了兩種截然相反的設計哲學,在分佈式系統設計的場景中,系統組件對一致性要求是不同的,因此ACID和BASE又會結合使用。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章