1、NoSQL概述

最近抽時間把Redis學了一下，所以就在網上找了一些資料。然後找到尚矽谷-周陽老師的視頻教程，覺得裡面的講的挺好。所以就把他視頻當中的資料教程整理出來。

單機MySQL的美好時代

• 在90年代，一個網站的訪問量一般都不大，用單個資料庫完全可以輕鬆應付。
  在那個時候，更多的都是靜態網頁，動態交互類型的網站不多。

• 上述架構下，我們來看看數據存儲的瓶頸是什麼？
  • 1、數據量的總大小 一個機器放不下時
  • 2、數據的索引（B+ Tree）一個機器的記憶體放不下時
  • 3、訪問量(讀寫混合)一個實例不能承受
• 如果滿足了上述1 or 3個，則需要進化......

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

• 後來，隨著訪問量的上升，幾乎大部分使用MySQL架構的網站在資料庫上都開始出現了性能問題，web程式不再僅僅專註在功能上，同時也在追求性能。程式員們開始大量的使用緩存技術來緩解資料庫的壓力，優化資料庫的結構和索引。開始比較流行的是通過文件緩存來緩解資料庫壓力，但是當訪問量繼續增大的時候，多台web機器通過文件緩存不能共用，大量的小文件緩存也帶了了比較高的IO壓力。
• 在這個時候，Memcached就自然的成為一個非常時尚的技術產品。

• Memcached作為一個獨立的分散式的緩存伺服器，為多個web伺服器提供了一個共用的高性能緩存服務，在Memcached伺服器上，又發展了根據hash演算法來進行多台Memcached緩存服務的擴展，然後又出現了一致性hash來解決增加或減少緩存伺服器導致重新hash帶來的大量緩存失效的弊端

Mysql主從讀寫分離

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

分表分庫+水平拆分+mysql集群

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

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

MySQL的擴展性瓶頸

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

今天是什麼樣子

NoSQL是什麼

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

NoSQL能幹什麼

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

NoSQL的3V+3高

• 大數據時代的3V：
  • 海量Volume
  • 多樣Variety
  • 實時Velocity
• Volume、Variety、Velocity。這3V表明大數據的三方面特質：量大、多樣、實時。對，不光是數據量大了。對TB、PB數據級的處理，已經成為基本配置。還能處理多樣性的數據類型，結構化數據和非結構化數據，能處理Web數據，能處理語音數據甚至是圖像、視頻數據。實時。以前的決策支持時代，可以用批量處理的方式，隔夜處理數據，等決策者第二天上班，可以看到昨天的經營數據。但現在的互聯網時代，業務在24小時不間斷運營，決策已經不是第二天上班才做出，而是在客戶每次瀏覽頁面，每次下訂單的過程中都存在，都會需要對用戶進行實時的推薦，決策已經變得實時。

• 互聯網需求的3高
  • 高併發
  • 高可擴
  • 高性能

NoSQL數據模型簡介

• NoSQL聚合模型 和 NoSQL資料庫的四大分類：
  • NoSQL聚合模型
    • KV鍵值
    • Bson
    • 列族
    • 圖形
• NoSQL資料庫的四大分類：
  • KV鍵值：這一類資料庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來說的優勢在於簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。 舉例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
  • 文檔型資料庫(bson格式比較多)：文檔型資料庫的靈感是來自於Lotus Notes辦公軟體的，而且它同第一種鍵值存儲相類似。該類型的數據模型是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型資料庫可 以看作是鍵值資料庫的升級版，允許之間嵌套鍵值。而且文檔型資料庫比鍵值資料庫的查詢效率更高。如：CouchDB, MongoDb. 國內也有文檔型資料庫SequoiaDB，已經開源。
  • 列存儲資料庫：這部分資料庫通常是用來應對分散式存儲的海量數據。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.
  • 圖關係資料庫：圖形結構的資料庫同其他行列以及剛性結構的SQL資料庫不同，它是使用靈活的圖形模型，並且能夠擴展到多個伺服器上。NoSQL資料庫沒有標準的查詢語言(SQL)，因此進行資料庫查詢需要制定數據模型。許多NoSQL資料庫都有REST式的數據介面或者查詢API。如：Neo4J, InfoGrid, Infinite Graph.

四大分類的典型介紹：
    KV鍵值：典型介紹
        新浪：BerkeleyDB+redis
        美團：redis+tair
        阿裡、百度：memcache+redis
    文檔型資料庫：典型介紹
        CouchDB
        MongoDB
    列存儲資料庫
        Cassandra, HBase
        分散式文件系統
    圖關係資料庫
        它不是放圖形的，放的是關係比如:朋友圈社交網路、廣告推薦系統
        社交網路，推薦系統等。專註於構建關係圖譜
        Neo4J, InfoGrid

• 什麼情況下可以用聚合模型來處理：
  • 高併發的操作是不太建議有關聯查詢的，互聯網公司用冗餘數據來避免關聯查詢。
  • 分散式事務是支持不了太多的併發的

在分散式資料庫中CAP原理CAP+BASE

• SQL 和 NoSQL

• SQL特性介紹

  • A：（Atomicity）原子性:
    • 整個事務中的所有操作，要麼全部完成，要麼全部不完成，不可能停滯在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
  • C：（Consistency）一致性
    • 一個事務可以封裝狀態改變（除非它是一個只讀的）。事務必須始終保持系統處於一致的狀態，不管在任何給定的時間併發事務有多少。
    • 也就是說：如果事務是併發多個，系統也必須如同串列事務一樣操作。其主要特征是保護性和不變性(Preserving an Invariant)，
      • 以轉賬案例為例，假設有五個賬戶，每個賬戶餘額是100元，那麼五個賬戶總額是500元，如果在這個5個賬戶之間同時發生多個轉賬，無論併發多少個，比如在A與B賬戶之間轉賬5元，在C與D賬戶之間轉賬10元，在B與E之間轉賬15元，五個賬戶總額也應該還是500元，這就是保護性和不變性
  • I：（Isolation）隔離性
    • 隔離狀態執行事務，使它們好像是系統在給定時間內執行的唯一操作。如果有兩個事務，運行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為串列化，為了防止事務操作間的混淆，必須串列化或序列化請求，使得在同一時間僅有一個請求用於同一數據。
  • D：（Durability）持久性
    • 在事務完成以後，該事務對資料庫所作的更改便持久的保存在資料庫之中，並不會被回滾。

• NoSQL特性介紹

  • C：（Consistency）強一致性
    • 任何一個讀操作總是能讀取到之前完成的寫操作結果，也就是在分散式環境中，多點的數據是一致的;
  • A：（Availability）高可用性
    • 每一個操作總是能夠在確定的時間內返回，也就是系統隨時都是可用的。
  • P：（Partition tolerance）分散式容忍性
    • 在出現網路分區(比如斷網)的情況下，分離的系統也能正常運行。
• 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的功能被極大的弱化了。
• 經典CAP圖
  • CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，
  • 最多只能同時較好的滿足兩個。
  • 因此，根據 CAP 原理將 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三大類：
    • CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
    • CP - 滿足一致性，分區容忍必的系統，通常性能不是特別高。
    • AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。

• BASE理論
  • BASE就是為瞭解決關係資料庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
  • BASE其實是下麵三個術語的縮寫：
    • 基本可用（Basically Available）
    • 軟狀態（Soft state）
    • 最終一致（Eventually consistent）
  • 它的思想是通過讓系統放鬆對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。為什麼這麼說呢，緣由就在於大型系統往往由於地域分佈和極高性能的要求，不可能採用分散式事務來完成這些指標，要想獲得這些指標，我們必須採用另外一種方式來完成，這裡BASE就是解決這個問題的辦法
• 分散式+集群簡介
  • 分散式：不同的多台伺服器上面部署不同的服務模塊（工程），他們之間通過Rpc/Rmi之間通信和調用，對外提供服務和組內協作。
  • 集群：不同的多台伺服器上面部署相同的服務模塊，通過分散式調度軟體進行統一的調度，對外體統服務和訪問。