Redis（一）：NoSQL入門和概述_ZenDei技術網路在線

NoSQL入門和概述目錄導航： NoSQL入門概述 3V+3高當下的NoSQL經典應用 NoSQL數據模型簡介 NoSQL資料庫的四大分類在分散式資料庫中CAP原理CAP+BASE NoSQL 入門概述互聯網時代背景下的大機遇，為什麼用NoSQL 單機MySQL的美好年代單機MySQL的美好 ...

NoSQL入門和概述目錄導航：

NoSQL入門概述
3V+3高
當下的NoSQL經典應用
NoSQL數據模型簡介
NoSQL資料庫的四大分類
在分散式資料庫中CAP原理CAP+BASE

NoSQL 入門概述

互聯網時代背景下的大機遇，為什麼用NoSQL

單機MySQL的美好年代

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

上述架構下，我們來看看數據存儲的瓶頸是什麼？

數據量的總大小，一個機器放不下時
數據的索引（B+ Tree）一個機器的記憶體放不下時
訪問量（讀寫混合）一個實例不能承受

如過滿足了上述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。

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

- MySQL的擴展性瓶頸

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

- 今天是什麼樣子？？

- 為什麼用NoSQL

今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數據。用戶的個人信息，社交網路，地理位置，用戶生成的數據和用戶操作日誌已經成倍的增加。我們如果要對這些用戶數據進行挖掘，那SQL資料庫已經不適合這些應用了, NoSQL資料庫的發展也卻能很好的處理這些大的數據。

是什麼？

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，

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

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

能幹嗎？
- 易擴展

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

- 大數據量高性能

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

- 多樣靈活的數據模型

NoSQL無需事先為要存儲的數據建立欄位，隨時可以存儲自定義的數據格式。而在關係資料庫里，增刪欄位是一件非常麻煩的事情。如果是非常大數據量的表，增加欄位簡直就是一個噩夢。

- 傳統RDBMS VS NOSQL

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

去哪下？
- Redis
- Memcache
- Mongdb
怎麼玩？
- KV
- Cache
- Persisit
- ...

3V+3高

大數據時代的3V
- 海量Volume
- 多樣Variety
- 實時Velocity
互聯網需求的3高
- 高併發
- 搞擴展
- 高性能

當下的NoSQL經典應用

當下的應用是SQL和NoSQL一起使用
阿裡巴巴中文網站商品信息如何存放
- 看看阿裡巴巴中文網站首頁以女裝/女包包為例

- - 架構發展歷程
    - 演變歷史

- - - 第五代

- - - 第五代架構使命

- - - ......
  - 和我們相關的，多數據源多數據類型的存儲問題

- 商品基本信息
  - 名稱、價格、出廠日期、生產廠商等。
  - 關係型資料庫：MySQL/Oracle目前淘寶在去O化（也即拿掉Oracle）註意：淘寶內部用的MySQL是裡面的大牛自己改造過的
    - 為什麼去IOE

2008年，王堅加盟阿裡巴巴成為集團首席架構師，即現在的首席技術官。這位前微軟亞洲研究院常務副院長被馬雲定位為：將幫助阿裡巴巴集團建立世界級的技術團隊，並負責集團技術架構以及基礎技術平臺搭建。

在加入阿裡後，帶著技術基因和學者風範的王堅就在阿裡巴巴集團提出了被稱為“去IOE”（在IT建設過程中，去除IBM小型機、Oracle資料庫及EMC存儲設備）的想法，並開始把雲計算的本質，植入阿裡IT基因。

王堅這樣概括“去IOE”運動和阿裡雲之間的關係：“去IOE”徹底改變了阿裡集團IT架構的基礎，是阿裡擁抱雲計算，產出計算服務的基礎。“去IOE”的本質是分佈化，讓隨處可以買到的Commodity PC架構成為可能，使雲計算能夠落地的首要條件。

- 商品描述、詳情、評價信息（多文字類）
  - 多文字信息描述類，IO讀寫性能變差
  - 文檔資料庫MongDB中
- 商品的圖片
  - 商品圖片展示類
  - 分散式的文件系統中
    - 淘寶自己的TFS
    - Google的GFS
    - Hadoop的HDFS
- 商品的關鍵字
  - 搜索引擎，淘寶內用
  - ISearch
- 商品的波段性的熱點高頻信息
  - 記憶體資料庫
  - Tair、Redis、Memcache
- 商品的交易、價格計算、積分累計
  - 外部系統，外部第三方支付介面
  - 支付寶
- 總結大型互聯網應用（大數據、高併發、多樣性數據類型）的難點和解決方案
  - 難點
    - 數據類型多樣性
    - 數據源多樣性和變化重構
    - 數據源改造而數據服務平臺不需要大面積重構
  - 解決辦法
    - 介紹EAI和統一數據平臺服務層
    - 阿裡、淘寶幹了什麼？UDSL
      - 是什麼？

- - - - 什麼樣？

- - - - 映射

- - - - API

- - - - 熱點緩存

- - - - ......

NoSQL數據模型簡介

以一個電商客戶、訂單、訂購、地址模型來對比下關係型資料庫和非關係型資料庫
- 傳統的關係型資料庫你如何設計？
  - ER圖（1:1/1:N/N:N，主外鍵等常見）

- NoSQL你如何設計
  - 什麼是BSON

BSON（）是一種類json的一種二進位形式的存儲格式，簡稱Binary JSON，它和JSON一樣，支持內嵌的文檔對象和數組對象

- - 用BSON畫出構建的數據模型

 1  
 2 {
 3  "customer":{
 4    "id":1136,
 5    "name":"Z3",
 6    "billingAddress":[{"city":"beijing"}],
 7    "orders":[
 8     {
 9       "id":17,
10       "customerId":1136,
11       "orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],
12       "shippingAddress":[{"city":"beijing"}]
13       "orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
14       }
15     ]
16   }
17 }

- 兩者對比，問題和難點
  - 為什麼上述的情況可以用聚合模型來處理
  - 想想關係模型資料庫你如何查詢？如果按照我們新設計的BSON，是不是查詢起來更可愛
聚合模型
- KV鍵值
- BSON
- 列族

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

- 圖形

NoSQL資料庫的四大分類

KV鍵值：典型介紹

新浪：BerkeleyDB + Redis
美團：Redis + Tair
阿裡、百度：Memcache + Redis

文檔型資料庫（BSON格式比較多）：典型介紹
- CouchDB
- MongoDB

MongoDB 是一個基於分散式文件存儲的資料庫。由 C++ 語言編寫。旨在為 WEB 應用提供可擴展的高性能數據存儲解決方案。

MongoDB 是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。

列存儲資料庫

Cassandra、HBase
分散式文件系統

圖關係資料庫

它不是放圖形的，放的是關係比如：朋友圈社交網路、廣告推薦系統
社交網路、推薦系統等。專註於構建關係圖譜
Neo4J，InfoGrid

四者對比

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

傳統的ACID分別是什麼
- A （Atomicity）原子性
- C（Consistency）一致性
- I（Isolation）獨特性
- D（Durability）持久性

關係型資料庫遵循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
- 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就是解決這個問題的辦法

分散式+集群簡介

分散式系統

分散式系統（distributed system）
由多台電腦和通信的軟體組件通過電腦網路連接（本地網路或廣域網）組成。分散式系統是建立在網路之上的軟體系統。正是因為軟體的特性，所以分散式系統具有高度的內聚性和透明性。因此，網路和分散式系統之間的區別更多的在於高層軟體（特別是操作系統），而不是硬體。分散式系統可以應用在在不同的平臺上如：Pc、工作站、區域網和廣域網上等。
簡單來講：
1分散式：不同的多台伺服器上面部署不同的服務模塊（工程），他們之間通過Rpc/Rmi之間通信和調用，對外提供服務和組內協作。
2集群：不同的多台伺服器上面部署相同的服務模塊，通過分散式調度軟體進行統一的調度，對外提供服務和訪問。