Redis 講解系列之 NoSql入門和概述(一)

1 入門概述

1.1 網際網路時代背景下大機遇，為什麼用nosql

1.1.1 單機MySQL的美好年代

在90年代，一個網站的通路量一般都不大，用單個資料庫完全可以輕松應付。

在那個時候，更多的都是靜态網頁，動态互動類型的網站不多。

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

1.資料量的總大小 一個機器放不下時

2.資料的索引（B+ Tree）一個機器的記憶體放不下時

3.通路量(讀寫混合)一個執行個體不能承受

如果滿足了上述1 or 3個，進化……

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

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

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

1.1.3 Mysql主從讀寫分離

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

1.1.4 分表分庫+水準拆分+mysql叢集

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

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

1.1.5 MySQL的擴充性瓶頸

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

1.1.6 現況

1.1.7 Nosql是什麼

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

泛指非關系型的資料庫。随着網際網路web2.0網站的興起，傳統的關系資料庫在應付web2.0網站，特别是超大規模和高并發的SNS類型的web2.0純動态網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的資料庫則由于其本身的特點得到了非常迅速的發展。NoSQL資料庫的産生就是為了解決大規模資料集合多重資料種類帶來的挑戰，尤其是大資料應用難題，包括超大規模資料的存儲。

(例如谷歌或Facebook每天為他們的使用者收集萬億比特的資料)。這些類型的資料存儲不需要固定的模式，無需多餘操作就可以橫向擴充。

1.1.8 為什麼用NoSQL

今天我們可以通過第三方平台（如：Google,Facebook等）可以很容易的通路和抓取資料。使用者的個人資訊，社交網絡，地理位置，使用者生成的資料和使用者記錄檔已經成倍的增加。我們如果要對這些使用者資料進行挖掘，那SQL資料庫已經不适合這些應用了, NoSQL資料庫的發展也卻能很好的處理這些大的資料。

1.2 Nosql 能幹嘛

1.2.1 易擴充

NoSQL資料庫種類繁多，但是一個共同的特點都是去掉關系資料庫的關系型特性。

資料之間無關系，這樣就非常容易擴充。也無形之間，在架構的層面上帶來了可擴充的能力。

1.2.2 大資料量高性能

NoSQL資料庫都具有非常高的讀寫性能，尤其在大資料量下，同樣表現優秀。

這得益于它的無關系性，資料庫的結構簡單。

一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，

在針對web2.0的互動頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，

是一種細粒度的Cache，是以NoSQL在這個層面上來說就要性能高很多了。

1.2.3 多樣靈活的資料模型

NoSQL無需事先為要存儲的資料建立字段，随時可以存儲自定義的資料格式。而在關系資料庫裡，

增删字段是一件非常麻煩的事情。如果是非常大資料量的表，增加字段簡直就是一個噩夢

1.2.4 傳統RDBMS VS NOSQL

RDBMS

- 高度組織化結構化資料

- 結構化查詢語言（SQL）

- 資料和關系都存儲在單獨的表中。

- 資料操縱語言，資料定義語言

- 嚴格的一緻性

- 基礎事務

NoSQL

- 代表着不僅僅是SQL

- 沒有聲明性查詢語言

- 沒有預定義的模式

-鍵 - 值對存儲，列存儲，文檔存儲，圖形資料庫

- 最終一緻性，而非ACID屬性

- 非結構化和不可預知的資料

- CAP定理

- 高性能，高可用性和可伸縮性

1.3 常用的Nosql

1. Redis
2. memcache
3. Mongdb

以上幾種Nosql 請到各自的官網上下載下傳并參考使用

1.4 Nosql 的核心功能點

1. KV(存儲)
2. Cache(緩存)
3. Persistence(持久化)
4. ……

2 3V+3高

2.1 大資料時代的3V

1. 海量Volume
2. 多樣Variety
3. 實時Velocity

2.2 網際網路需求的3高

1. 高并發
2. 高可擴
3. 高性能

3 當下的NoSQL經典應用

(以阿裡巴巴中文網站首頁以女裝/女包包為例)

3.1 關于Ali架構發展曆史

3.1.1 演變過程

3.1.2 Ali第5代架構

Ali第5代架構的使命

3.1.3 多資料源多資料類型的存儲問題

3.2 阿裡巴巴中文站商品資訊如何存放

3.2.1 商品基本資訊

名稱、價格，出廠日期，生産廠商等。

關系型資料庫：mysql/oracle目前淘寶在去O化(也即拿掉Oracle)，

注意，淘寶内部用的Mysql是裡面的大牛自己改造過的—去IOE化

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

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

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

3.2.2 商品描述、詳情、評價資訊(多文字類)

文檔資料庫MongDB中。

多文字資訊描述類，IO讀寫性能變差。

3.2.3 3 商品的圖檔

• 商品圖檔展現類。

• 分布式的檔案系統中。

  淘寶自己的TFS。

  Google的GFS。

  Hadoop的HDFS。

3.2.4 商品的關鍵字

• 搜尋引擎，淘寶内用。
• ISearch。

3.2.5 商品的波段性的熱點高頻資訊

• 記憶體資料庫。
• tair、Redis、Memcache。

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

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

3.2.7 總結

總結大型網際網路應用(大資料、高并發、多樣資料類型)的難點和解決方案。

• 難點
  • 資料類型多樣性
  • 資料源多樣性和變化重構
  • 資料源改造而資料服務平台不需要大面積重構
• 解決辦法
  • 阿裡、淘寶幹了什麼？UDSL
  • UDSL(統一資料服務層)

  • 

  • UDSL 模型圖

  • 

  • 映射
  • API
  • 熱點緩存
  • ………