目錄
為什麼用NoSQL
1、單機MySQL的美好年代
2、Memcached（緩存）+ MySQL + 垂直拆分
3、MySQL主從讀寫分離
4、分表分庫 + 水準拆分 + Mysql 叢集
5、MySQL 的擴充性瓶頸
6、今天是什麼樣子？？
7、為什麼用NoSQL？
什麼是NoSQL
NoSQL
NoSQL的特點
1、易擴充
2、大資料量高性能
3、多樣靈活的資料模型
4、傳統的RDBMS VS NoSQL
拓展：3V+3高
經典應用分析
NoSQL資料模型簡介
NoSQL四大分類
CAP + BASE
為什麼用NoSQL
1、單機MySQL的美好年代
在 90 年代，一個網站的通路量一般不大，用單個資料庫完全可以輕松應付！ 在那個時候，更多的都是靜态網頁，動态互動類型的網站不多。 上述架構下，我們來看看資料存儲的瓶頸是什麼？ 1. 資料量的總大小，一個機器放不下時 2. 資料的索引（ B+ Tree ）一個機器的記憶體放不下時 3. 通路量（讀寫混合）一個執行個體不能承受 如果滿足了上述 1 or 3 個，進化 .... DAL ：資料庫通路層
2、Memcached（緩存）+ MySQL + 垂直拆分
後來，随着通路量的上升，幾乎大部分使用 MySQL 架構的網站在資料庫上都開始出現了性能問題， web 程式不再僅僅專注在功能上，同時也在追求性能。程式猿們開始大量使用緩存技術來緩解資料庫的壓 力，優化資料庫的結構和索引，開始比較流行的是通過檔案緩存來緩解資料庫壓力，但是當通路量繼續 增大的時候，多台 web 機器通過檔案緩存不能共享，大量的小檔案緩存也帶了比較高的 IO 壓力，在這個 時候， Memcached 就自然的成為一個非常時尚的技術産品。
3、MySQL主從讀寫分離
由于資料庫的寫入壓力增加， Memcached 隻能緩解資料庫的讀取壓力，讀寫集中在一個資料庫上讓數 據庫不堪重負，大部分網站開始使用主從複制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴充 性， MySQL 的 master-slave 模式成為這個時候的網站标配了。
4、分表分庫 + 水準拆分 + Mysql 叢集
在 Memcached 的高速緩存， MySQL 的主從複制，讀寫分離的基礎之上，這時 MySQL 主庫的寫壓力開始 出現瓶頸，而資料量的持續猛增，由于 MyISAM 使用表鎖，在高并發下會出現嚴重的鎖問題，大量的高 并發 MySQL 應用開始使用 InnoDB 引擎代替 MyISAM 。 同時，開始流行使用分表分庫來緩解寫壓力和資料增長的擴充問題，這個時候，分表分庫成了一個熱門 技術，是面試的熱門問題，也是業界讨論的熱門技術問題。也就是在這個時候， MySQL 推出了還不太穩 定的表分區，這也給技術實力一般的公司帶來了希望。雖然 MySQL 推出了 MySQL Cluster 叢集，但性能 也不能很好滿足網際網路的需求，隻是在高可靠性上提供了非常大的保證。
5、MySQL 的擴充性瓶頸
MySQL 資料庫也經常存儲一些大文本的字段，導緻資料庫表非常的大，在做資料庫恢複的時候就導緻非 常的慢，不容易快速恢複資料庫，比如 1000 萬 4KB 大小的文本就接近 40GB 的大小，如果能把這些資料 從 MySQL 省去， MySQL 将變的非常的小，關系資料庫很強大，但是它并不能很好的應付所有的應用場 景， MySQL 的擴充性差（需要複雜的技術來實作），大資料下 IO 壓力大，表結構更改困難，正是目前使 用 MySQL 的開發人員面臨的問題。
6、今天是什麼樣子？？
7、為什麼用NoSQL？
今天我們可以通過第三方平台（如： Google ， FaceBook 等）可以很容易的通路和抓取資料。使用者的個 人資訊，社交網絡，地理位置，使用者生成的資料和使用者記錄檔已經成倍的增加、我們如果要對這些用 戶資料進行挖掘，那 SQL 資料庫已經不适合這些應用了，而 NoSQL 資料庫的發展卻能很好的處理這些大 的資料！
什麼是NoSQL
NoSQL
NoSQL = Not Only SQL ，意思：不僅僅是 SQL ； 泛指非關系型的資料庫，随着網際網路 Web2.0 網站的興起，傳統的關系資料庫在應付 web2.0 網站，特别 是超大規模和高并發的社交網絡服務類型的 Web2.0 純動态網站已經顯得力不從心，暴露了很多難以克服 的問題，而非關系型的資料庫則由于其本身的特點得到了非常迅速的發展， NoSQL 資料庫的産生就是為 了解決大規模資料集合多種資料種類帶來的挑戰，尤其是大資料應用難題，包括超大規模資料的存儲。 （例如谷歌或 Facebook 每天為他們的使用者收集萬億比特的資料）。這些類型的資料存儲不需要固定的模 式，無需多餘操作就可以橫向擴充。
NoSQL的特點
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 - 高度組織化結構化資料 - 結構化查詢語言（ SQL ） - 資料和關系都存儲在單獨的表中 - 資料操縱語言，資料定義語言 - 嚴格的一緻性 - 基礎事務 NoSQL - 代表着不僅僅是 SQL - 沒有聲明性查詢語言 - 沒有預定義的模式 - 鍵值對存儲，列存儲，文檔存儲，圖形資料庫 - 最終一緻性，而非 ACID 屬性 - 非結構化和不可預知的資料 - CAP 定理 - 高性能，高可用性 和 可伸縮性
拓展：3V+3高
大資料時代的 3V ： 主要是對問題的描述網際網路需求的 3 高 ： 主要是對程式的要求
- 海量 Volume
- 多樣 Variety
- 實時 Velocity
當下的應用是 SQL 和 NoSQL 一起使用 ，技術沒有高低之分，就看怎麼用！
- 高并發
- 高可用
- 高性能
經典應用分析
聊聊阿裡巴巴中文網站的商品資訊如何存放，以女裝、包包為例：
聊聊架構發展曆程：推薦書籍《淘寶技術這十年》
1 、演變過程：以下圖檔資料來源：阿裡巴巴中文站架構設計實踐
2 、第五代
3 、第 5 代架構使命
和我們相關的，多資料源多資料類型的存儲問題
1、商品的基本資訊
名稱、價格、出廠日期、生産廠商等 關系型資料庫： mysql 、 oracle 目前淘寶在去 O 化（也即，拿掉 Oracle ） 注意，淘寶内部用的 MySQL 是裡面的大牛自己改造過的。 為什麼去 IOE ： 2008 年 , 王堅博士加入阿裡巴巴，成為首席架構師。把雲計算植入阿裡 IT 基因。 2013 年 5 月 17 日，阿裡集團最後一台 IBM 小機在支付寶下線。這是自 2009 年 “ 去 IOE” 戰略透露以來， “ 去 IOE” 非常重要的一個節點。 “ 去 IOE” 指的是擺脫掉 IT 部署中原有的 IBM 小型機、 Oracle 資料庫以及 EMC 存儲的過度依賴。告别最後一台小機，意味着整個阿裡集團盡管還有一些 Oracle 資料庫和 EMC 存儲，但是 IBM 小型機已全部被替換。 2013 年 7 月 10 日，淘寶重中之重的廣告系統使用的 Oracle 資料庫下線，也是整 個淘寶最後一個 Oracle 資料庫。這兩件事合在一起是阿裡巴巴技術發展過程中的一個重要裡程碑。
2、商品描述、詳情、評價資訊（多文字類）
多文字資訊描述類， IO 讀寫性能變差 存在文檔資料庫 MongDB 中
3、商品的圖檔
商品圖檔展現類 分布式檔案系統中
- - 淘寶自己的 TFS
- - Google的 GFS
- - Hadoop的 HDFS
4、商品的關鍵字
搜尋引擎，淘寶内用 ISearch ：多隆一高興一個人開發的 所有牛逼的人在牛逼之前 , 肯定有一段苦逼的歲月 , 但隻要像傻逼一樣的堅持 , 一定終将牛逼
1
1 2 3 4 5 5、商品的波段性的熱點高頻資訊
記憶體資料庫 Tair 、 Redis 、 Memcache 等
6、商品的交易，價格計算，積分累計！
外部系統，外部第三方支付接口 支付寶
大型網際網路應用（大資料，高并發，多樣資料類型）的難點和解決方案
難點：
- 資料類型的多樣性
- 資料源多樣性和變化重構
- 資料源改造而資料服務平台不需要大面積重構
解決辦法：
NoSQL資料模型簡介
案例設計
以一個電商客戶，訂單，訂購，位址模型來對比下關系型資料庫和非關系型資料庫 傳統的關系型資料庫你如何設計？ ER 圖（ 1:1/1:N/N:N, 主外鍵等常見）
- 使用者對應多個訂單多個位址
- 每個訂單對應每個商品、價格、位址
- 每個商品對應産品
閑聊：使用者畫像分析，女人心是琢磨不透的，看了男裝，刮胡刀，根據她的資訊找到她男朋友的生日就 在最近，背景畫像已經分析完畢，準備推送廣告了，結果她買了一個零食就走了 ~ 90 後的程式員真的在一點點的改變生活中的點點滴滴，假設你有幸進入了大廠，你會發現周圍的小夥伴都在努力，真的就是那種可以在海底撈吃着吃着飯，突然就掏出筆記本寫代碼的那種，别人都以為他們 是瘋子，隻有他們自己内心才懂。這才是對技術的癡迷。
NoSQL 你如何設計
可以嘗試使用 BSON 。 BSON 是一種類 json 的一種二進制形式的存儲格式，簡稱 Binary JSON ，它和 JSON 一樣，支援内嵌的文檔對象和數組對象 用 BSon 畫出建構的資料模型
{
"customer":{
"id":1000,
"name":"Z3",
"billingAddress":[{"city":"beijing"}],
"orders":[
{
"id":17,
"customerId":1000,
"orderItems":[{"productId":27,"price":77.5,"productName":"thinking in
java"}],
"shippingAddress":[{"city":"beijing"}]
"orderPayment":[{"ccinfo":"111-222-
333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
}
]
}
}
想想關系模型資料庫你如何查？ 如果按照我們新設計的 BSon ，是不是查詢起來很簡單。
- 高并發的操作是不太建議有關聯查詢的，網際網路公司用備援資料來避免關聯查詢
- 分布式事務是支援不了太多的并發的
NoSQL四大分類
KV 鍵值 ：
- 新浪：BerkeleyDB+redis
- 美團：redis+tair
- 阿裡、百度：memcache+redis
文檔型資料庫 (bson 格式比較多 ) ：
- CouchDB
- MongoDB
- MongoDB 是一個基于分布式檔案存儲的資料庫。由 C++ 語言編寫。旨在為 WEB 應用提供可 擴充的高性能資料存儲解決方案。
- MongoDB 是一個介于關系資料庫和非關系資料庫之間的産品，是非關系資料庫當中功能最豐 富，最像關系資料庫的。
列存儲資料庫：
- Cassandra, HBase
- 分布式檔案系統
圖關系資料庫
- 它不是放圖形的，放的是關系比如:朋友圈社交網絡、廣告推薦系統
- 社交網絡，推薦系統等。專注于建構關系圖譜
- Neo4J, InfoGrid
四者對比
CAP + BASE
傳統的 ACID 分别是什麼？
關系型資料庫遵循 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) 持久性
- 持久性是指一旦事務送出後，它所做的修改将會永久的儲存在資料庫上，即使出現當機也不會丢失。
CAP （三進二）
- C : Consistency（強一緻性）
- A : Availability（可用性）
- P : Partition tolerance（分區容錯性）
CAP 理論就是說在分布式存儲系統中，最多隻能實作上面的兩點 。 而由于目前的網絡硬體肯定會出現延遲丢包等問題，是以 分區容錯性是我們必須需要實作 的。 是以我們隻能在一緻性和可用性之間進行權衡，沒有 NoSQL 系統能同時保證這三點。 注意：分布式架構的時候必須做出取舍。 一緻性和可用性之間取一個平衡。多餘大多數 web 應用，其實并不需要強一緻性。 是以犧牲 C 換取 P ，這是目前分布式資料庫産品的方向. 一緻性與可用性的決擇 對于 web2.0 網站來說，關系資料庫的很多主要特性卻往往無用武之地 資料庫事務一緻性需求 很多 web 實時系統并不要求嚴格的資料庫事務，對讀一緻性的要求很低， 有些場合對寫一緻性要求并不高。允許實作最終一緻性。 資料庫的寫實時性和讀實時性需求 對關系資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對于很多 web 應用來說，并不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動态是完全可以接受的。 對複雜的 SQL 查詢，特别是多表關聯查詢的需求 任何大資料量的 web 系統，都非常忌諱多個大表的關聯查詢，以及複雜的資料分析類型的報表查詢，特别是 SNS 類型的網站，從需求以及産品設計角度，就避免了這種情況的産生。往往更多的隻是單表的主鍵查詢，以及單表的簡單條件分頁查詢， SQL 的功能被極大的弱化了。 CAP 理論的核心 是：一個分布式系統不可能同時很好的滿足一緻性，可用性和分區容錯性這三個需求，最多隻能同時較好的滿足兩個。是以，根據 CAP 原理将 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類： CA - 單點叢集，滿足一緻性，可用性的系統，通常在可擴充性上不太強大。 CP - 滿足一緻性，分區容忍必的系統，通常性能不是特别高。 AP - 滿足可用性，分區容忍性的系統，通常可能對一緻性要求低一些。
BASE 理論
BASE 理論是由 eBay 架構師提出的。 BASE 是對 CAP 中一緻性和可用性權衡的結果，其來源于對大規模互 聯網分布式系統實踐的總結，是基于 CAP 定律逐漸演化而來。其核心思想是即使無法做到強一緻性，但 每個應用都可以根據自身業務特點，采用适當的方式來使系統達到最終一緻性。 BASE 就是為了解決關系資料庫強一緻性引起的問題而引起的可用性降低而提出的解決方案。
BASE其實是下面三個術語的縮寫：
- 基本可用(Basically Available)： 基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。電商大促時，為了應對通路量激增，部分使用者可能會被引導到降級頁面，服務層也可能隻提供降級服務。這就是損失部分可用性的展現。
- 軟狀态(Soft State)： 軟狀态是指允許系統存在中間狀态，而該中間狀态不會影響系統整體可用性。分布式存儲中一般一份資料至少會有三個副本，允許不同節點間副本同步的延時就是軟狀态的展現。MySQL Replication 的異步複制也是一種展現。
- 最終一緻性(Eventual Consistency)： 最終一緻性是指系統中的所有資料副本經過一定時間後，最終能夠達到一緻的狀态。弱一緻性和強一緻性相反，最終一緻性是弱一緻性的一種特殊情況。
它的思想是通過讓系統放松對某一時刻資料一緻性的要求來換取系統整體伸縮性和性能上改觀。為什麼這麼說呢，緣由就在于大型系統往往由于地域分布和極高性能的要求，不可能采用分布式事務來完成這 些名額，要想獲得這些名額，我們必須采用另外一種方式來完成，這裡 BASE 就是解決這個問題的辦法！ 解釋：
- 分布式：不同的多台伺服器上面部署不同的服務子產品（工程），他們之間通過Rpc通信和調用，對外提供服務群組内協作。
- 叢集：不同的多台伺服器上面部署相同的服務子產品，通過分布式排程軟體進行統一的排程，對外提供服務和通路。