redis筆記 （番外篇）——從RDBMS到NoSQL的架構演化及CAP原理

1. 從RDBMS到NoSQL的架構演化

互聯網時代背景下大機遇，爲何用nosql

1 單機MySQL的美好年代

在90年代，一個網站的訪問量通常都不大，用單個數據庫徹底能夠輕鬆應付。
在那個時候，更多的都是靜態網頁，動態交互類型的網站很少。

上述架構下，咱們來看看數據存儲的瓶頸是什麼？
1.數據量的總大小 一個機器放不下時
2.數據的索引（B+ Tree）一個機器的內存放不下時
3.訪問量(讀寫混合)一個實例不能承受
 若是出現了上述1 or 3個上述瓶頸，架構開始演化到下一個階段：

2 Memcached(緩存)+MySQL+垂直拆分

後來，隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序再也不僅僅專一在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力，可是當訪問量繼續增大的時候，多臺web機器經過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就天然的成爲一個很是時尚的技術產品。

 Memcached做爲一個獨立的分佈式的緩存服務器，爲多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，而後又出現了一致性hash來解決增長或減小緩存服務器致使從新hash帶來的大量緩存失效的弊端

侷限性：Memcached只能緩解數據庫的讀取壓力。對於大量寫入的應用場景沒法緩解。

（本文轉載請註明出處：https://my.oschina.net/happyBKs/blog/1557597）

3 Mysql主從讀寫分離

因爲數據庫的寫入壓力增長，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製技術來達到讀寫分離，以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。

 

4 分表分庫+水平拆分+mysql集羣 

 在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。

PS： MyISAM引擎用的是表鎖，InnoDB引擎用的是行鎖

 同時，開始流行使用分表分庫來緩解寫壓力和數據增加的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster集羣，但性能也不能很好知足互聯網的要求，只是在高可靠性上提供了很是大的保證。

分庫：將業務相關的數據表放在同一個庫中。同時，還能夠按照數據的冷熱、相關性來分庫。

當同一張表的數據量很大時，也須要分庫分表。如記錄ID1-100000的進1號庫，100001-200000進2號庫。。。

5 MySQL的擴展性瓶頸

MySQL數據庫也常常存儲一些大文本字段，致使數據庫表很是的大，在作數據庫恢復的時候就致使很是的慢，不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小，若是能把這些數據從MySQL省去，MySQL將變得很是的小。關係數據庫很強大，可是它並不能很好的應付全部的應用場景。MySQL的擴展性差（須要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

還有如視頻、大圖片等等，傳統的關係型數據庫並不適合做爲數據存儲的方案。

6 今天是什麼樣子？？

負載均衡——Nginx

App服務器——Tomcat

數據庫(集羣)——Mysql、Oracle

緩存、Hadoop集羣、實時通訊服務器、流媒體服務器，還有電子郵件、圖片服務器等等

7 爲何用NoSQL

爲何使用NoSQL ?
今天咱們能夠經過第三方平臺（如：Google,Facebook等）能夠很容易的訪問和抓取數據。用戶的我的信息，社交網絡，地理位置，用戶生成的數據和用戶操做日誌已經成倍的增長。咱們若是要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。

社交這種描述人與人關係的數據，對於這種數據 傳統的關係型數據庫不適合存儲和處理。
 

 

2. NoSQL概述——四個點

1 是什麼

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

（例如谷歌或Facebook天天爲他們的用戶收集萬億比特的數據）。這些類型的數據存儲不須要固定的模式，無需多餘操做就能夠橫向擴展。

2 能幹嗎

1. 易擴展

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

2. 大數據量高性能

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

redis每秒鐘寫8萬，讀11萬次

3. 多樣靈活的數據模型

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

4. 傳統RDBMS VS NOSQL

RDBMS vs NoSQL

RDBMS
- 高度組織化結構化數據
- 結構化查詢語言（SQL）
- 數據和關係都存儲在單獨的表中。
- 數據操縱語言，數據定義語言
- 嚴格的一致性
- 基礎事務

NoSQL
- 表明着不只僅是SQL
- 沒有聲明性查詢語言
- 沒有預約義的模式
-鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫
- 最終一致性，而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能，高可用性和可伸縮性

 

3 去哪下

memcached：但就高速緩存一件事而言，最快的仍是memcached

redis：但論數據類型豐富，redis和tair（阿里、美團）更出色

Mongodb

4 怎麼玩

KV——鍵值對

Cache——緩存

Persistence——持久化

 

 

3. 互聯網數據的3V和3高及當下的NoSQL經典應用

（1）3V和3高

3V

海量Volume
多樣Variety
實時Velocity

3高

高併發
高可擴——橫向追加CPU或機器，構建陣列或者集羣。
高性能

 

（2）當下的NoSQL經典應用

一個NoSql的應用中各方面問題的解決方案要點：這裏是從別的地方看到一個講稿中的例子，以爲不錯，因此把提綱列在這裏，本身就不寫了。

1趨冷的數據、不變的數據，如商品的基本信息，存放在關係型數據庫中。

2商品描述、詳情、評價信息(多文字類)，存放在MongoDB裏。

多文字信息描述類，IO讀寫性能變差

文檔數據庫MongDB中

3 商品的圖片

商品圖片展示類

分佈式的文件系統中

        淘寶本身的TFS

        Google的GFS

        Hadoop的HDFS

 

4 商品的關鍵字

搜索引擎，淘寶內用

ISearch

 

5 商品的波段性的熱點高頻信息

內存數據庫
tair、Redis、Memcache

例如，情人節期間，電商網站的巧克力、玫瑰等會成爲熱搜詞彙，這時候就將其放在redis等緩存中

 

6 商品的交易、價格計算、積分累計

外部系統，外部第3方支付接口
支付寶

 

（3）總結大型互聯網應用(大數據、高併發、多樣數據類型)的難點和解決方案

難點
    數據類型多樣性
    數據源多樣性和變化重構
    數據源改造而數據服務平臺不須要大面積重構

解決辦法
    EAI和統一數據平臺服務層
    阿里、淘寶幹了什麼？UDSL（統一數據平臺服務層）

 

 

4. NoSQL數據模型簡介

（1）以一個電商客戶、訂單、訂購、地址模型來對比下關係型

 

（2）數據庫和非關係型數據庫

1 傳統的關係型數據庫你如何設計？
        ER圖(1:1/1:N/N:N,主外鍵等常見)
2 nosql你如何設計
        什麼是BSON：BSON（）是一種類json的一種二進制形式的存儲格式，簡稱Binary JSON，
它和JSON同樣，支持內嵌的文檔對象和數組對象
        給學生用BSon畫出構建的數據模型
3 二者對比，問題和難點
        爲何上述的狀況能夠用聚合模型來處理
            高併發的操做是不太建議有關聯查詢的，

（3）互聯網公司用冗餘數據來避免關聯查詢

分佈式事務是支持不了太多的併發的

按照BSon查詢

（4）聚合模型

KV鍵值
bson
列族

顧名思義，是按列存儲數據的。最大的特色是方便存儲結構化和半結構化數據，方便作數據壓縮，
對針對某一列或者某幾列的查詢有很是大的IO優點。

圖形

 

5. NoSQL數據庫的四大分類

    （1）KV鍵值：典型介紹

        新浪：BerkeleyDB+redis
        美團：redis+tair
        阿里、百度：memcache+redis

    （2）文檔型數據庫(bson格式比較多)：典型介紹

        CouchDB
        MongoDB

            MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++ 語言編寫。旨在爲 WEB 應用提供可擴展的高性能數據存儲解決方案。
            MongoDB 是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。

    （3）列存儲數據庫

        Cassandra, HBase
        分佈式文件系統

    （4）圖關係數據庫

        它不是放圖形的，放的是關係好比:朋友圈社交網絡、廣告推薦系統
        社交網絡，推薦系統等。專一於構建關係圖譜
        Neo4J, InfoGrid

   （5） 四者對比

 

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

    1. 傳統的ACID分別是什麼

        A (Atomicity) 原子性
        C (Consistency) 一致性
        I (Isolation) 獨立性
        D (Durability) 持久性

關係型數據庫遵循ACID規則 事務在英文中是transaction，和現實世界中的交易很相似，它有以下四個特性： 一、A (Atomicity) 原子性 原子性很容易理解，也就是說事務裏的全部操做要麼所有作完，要麼都不作，事務成功的條件是事務裏的全部操做都成功，只要有一個操做失敗，整個事務就失敗，須要回滾。好比銀行轉帳，從A帳戶轉100元至B帳戶，分爲兩個步驟：1）從A帳戶取100元；2）存入100元至B帳戶。這兩步要麼一塊兒完成，要麼一塊兒不完成，若是隻完成第一步，第二步失敗，錢會莫名其妙少了100元。 二、C (Consistency) 一致性 一致性也比較容易理解，也就是說數據庫要一直處於一致的狀態，事務的運行不會改變數據庫本來的一致性約束。 三、I (Isolation) 獨立性 所謂的獨立性是指併發的事務之間不會互相影響，若是一個事務要訪問的數據正在被另一個事務修改，只要另一個事務未提交，它所訪問的數據就不受未提交事務的影響。好比現有有個交易是從A帳戶轉100元至B帳戶，在這個交易還未完成的狀況下，若是此時B查詢本身的帳戶，是看不到新增長的100元的 四、D (Durability) 持久性 持久性是指一旦事務提交後，它所作的修改將會永久的保存在數據庫上，即便出現宕機也不會丟失。

    2. CAP是什麼

        C:Consistency（強一致性）
        A:Availability（可用性）
        P:Partition tolerance（分區容錯性）

   3. CAP三個只能知足兩個！！！（CAP的3進2） 

CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。
而因爲當前的網絡硬件確定會出現延遲丟包等問題，因此

分區容忍性是咱們必須須要實現的。

因此咱們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
===============================================================
C:強一致性 A：高可用性 P：分佈式容忍性

 CA 傳統Oracle數據庫

 AP 大多數網站架構的選擇

 CP Redis、Mongodb

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

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

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

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

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

    4. 經典CAP圖

 CAP理論的核心是：一個分佈式系統不可能同時很好的知足一致性，可用性和分區容錯性這三個需求，
最多隻能同時較好的知足兩個。
所以，根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三 大類：
CA - 單點集羣，知足一致性，可用性的系統，一般在可擴展性上不太強大。
CP - 知足一致性，分區容忍必的系統，一般性能不是特別高。
AP - 知足可用性，分區容忍性的系統，一般可能對一致性要求低一些。
注：Nosql用的實際是AP

    5. BASE 是什麼

BASE就是爲了解決關係數據庫強一致性引發的問題而引發的可用性下降而提出的解決方案。

BASE實際上是下面三個術語的縮寫：
    基本可用（Basically Available）
    軟狀態（Soft state）
    最終一致（Eventually consistent）

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

 

   6. 分佈式+集羣簡介

（1）分佈式系統

分佈式系統（distributed system）
 由多臺計算機和通訊的軟件組件經過計算機網絡鏈接（本地網絡或廣域網）組成。分佈式系統是創建在網絡之上的軟件系統。正是由於軟件的特性，因此分佈式系統具備高度的內聚性和透明性。所以，網絡和分佈式系統之間的區別更多的在於高層軟件（特別是操做系統），而不是硬件。分佈式系統能夠應用在在不一樣的平臺上如：Pc、工做站、局域網和廣域網上等。

簡單來說：
1分佈式：不一樣的多臺服務器上面部署不一樣的服務模塊（工程），他們之間經過Rpc/Rmi之間通訊和調用，對外提供服務和組內協做。

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