1.NoSQL入門和概述
入門概述：
1.為什麽要用到NoSQL
a) 單機MySQL的美好年代，在90年代，一個網站的訪問量一般都不大，用單個數據庫完全可以輕松應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站不多。
上述架構下，我們來看看數據存儲的瓶頸是什麽？
1.數據量的總大小 一個機器放不下時
2.數據的索引（B+ Tree）一個機器的內存放不下時
3.訪問量(讀寫混合)一個實例不能承受
如果滿足了上述1 or 3個，進化......
b) Memcached(緩存)+MySQL+垂直拆分，後來，隨著訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序不再僅僅專註在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力，但是當訪問量繼續增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術產品。
Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，然後又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端
c) Mysql主從讀寫分離，由於數據庫的寫入壓力增加，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從復制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網站標配了。
d) 分表分庫 + 水平拆分 + mysql集群， 在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，由於MyISAM使用表鎖，在高並發下會出現嚴重的鎖問題，大量的高並發MySQL應用開始使用InnoDB引擎代替MyISAM。
同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但性能也不能很好滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。
e) MySQL性能擴展瓶頸，MySQL數據庫也經常存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。關系數據庫很強大，但是它並不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。
f) 為什麽使用NoSQL，今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數據。用戶的個人信息，社交網絡，地理位置，用戶生成的數據和用戶操作日誌已經成倍的增加。我們如果要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。
2.NoSQL是什麽：
NoSQL(NoSQL = Not Only SQL) ，不僅僅是SQL，泛指非關系型數據庫，非關系型數據庫是關系型數據庫的一種補充，
隨著互聯網web2.0 網站的興起，傳統的關系型數據庫在應付web2.0網站，特別是超大規模和高並發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由於其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多余操作就可以橫向擴展。
3.NoSQL能幹嗎：
1.易擴展
NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。
2.大數據量高性能
NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益於它的無關系性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了
3.多樣靈活的數據類型
NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系數據庫裏，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢
4.傳統RDBMS VS NOSQL
RDBMS
- 高度組織化結構化數據
- 結構化查詢語言（SQL）
- 數據和關系都存儲在單獨的表中。
- 數據操縱語言，數據定義語言
- 嚴格的一致性
- 基礎事務
NoSQL
- 代表著不僅僅是SQL
- 沒有聲明性查詢語言
- 沒有預定義的模式
-鍵 - 值對存儲（Redis），列存儲，文檔存儲，圖形數據庫
- 最終一致性，而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能，高可用性和可伸縮性
4.NoSQL去哪下：Redis Memcache Mongdb
5.NoSQL怎麽玩：KV Cache Persistence
3V+3高
大數據時代的3V ： 海量Volume； 多樣Variety； 實時Velocity
互聯網需求的3高
高並發 高可擴 高性能
當下NoSQL經典應用
當下的應用是sql 和 nosql 一起使用
阿裏巴巴中文站商品信息如何存放
1.商品基本信息（名稱、價格、出廠日期、生產廠商）
關系型數據庫：mysql/oracle 目前淘寶也在去O化（也即拿掉Oracle）
註意，淘寶內部用的MySQL是裏面的大牛自己改造過的
2.商品描述、詳情、評價信息（多文字類）
多文字信息描述類，IO讀寫性能變差
文檔數據庫MongDB中
3.商品的圖片
商品圖片展現類
分布式的文件系統中：淘寶自己的TFS，Google的GFS，Hadoop的HDFS
4.商品的關鍵字
搜索引擎，淘寶內用
ISearch
5.商品的波段性的熱點高頻信息（這裏可以使用Redis）
內存數據庫
tair、Redis、Memcache
6.商品的交易、價格計算、積分累計
外部系統，外部第三方支付接口
支付寶
總結大型互聯網應用（大數據、高並發、多樣數據類型）的難點和解決方案
難點：數據類型多樣性
數據源多樣性和變化重構
數據源改造而數據服務平臺不需要大面積重構
解決辦法：統一數據服務平臺 UDSL
NoSQL數據模型簡介
以一個電商客戶、訂單、訂購、地址模型來對比下關系型數據庫和非關系型數據庫
傳統關系型數據庫如何設計：ER圖（1:1/1：N/N：N主外鍵等）
NoSQL如何設計：使用BSON，BSON是一種類json的一種二進制形式的存儲格式，簡稱Binary JSON，
它和JSON一樣，支付內嵌的文檔對象和數組對象
{
"customer":{
"id":1136,
"name":"Z3",
"billingAddress":[{"city":"beijing"}],
"orders":[
{
"id":17,
"customerId":1136,
"orderItems":[{"productId":27,"price":77.5,"productName":"thinking in java"}],
"shippingAddress":[{"city":"beijing"}]
"orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
}
]
}
}
兩者對比，問題和難點：為什麽上述情況可以用聚合模型來處理
高並發的操作是不太建議有關聯查詢的，互聯網公司用冗余數據來避免關聯查詢
分布式事務是支持不了太多的並發的
NoSQL聚合模型：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）持久性
分布式數據庫中的CAP
C（Consistency）強一致性
A（Avaliability）可用性
P（Partition tolerance）分區容錯性
CAP的3進2：CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以 分區容忍性是我們必須需要實現的。
所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
C:強一致性 A：高可用性 P：分布式容忍性
CA 傳統Oracle數據庫
AP 大多數網站架構的選擇
CP Redis、Mongodb
註意：分布式架構的時候必須做出取舍。一致性和可用性之間取一個平衡。多余大多數web應用，其實並不需要強一致性。因此犧牲C換取P，這是目前分布式數據庫產品的方向
1.一致性與可用性的決擇
對於web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地
2.數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求並不高。允許實現最終一致性。
3.數據庫的寫實時性和讀實時性需求
對關系數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麽高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。
4.對復雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
CAP理論的核心是：
一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，
最多只能同時較好的滿足兩個。
因此，根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
CP - 滿足一致性，分區容忍性的系統，通常性能不是特別高。
AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。
BASE是什麽：
BASE其實是下面三個術語的縮寫：
基本可用（Basically Available）
軟狀態（Soft state）
最終一致（Eventually consistent）
BASE就是為了解決關系數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案。
它的思想是通過讓系統放松對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。為什麽這麽說呢，緣由就在於大型系統往往由於地域分布和極高性能的要求，不可能采用分布式事務來完成這些指標，要想獲得這些指標，我們必須采用另外一種方式來完成，這裏BASE就是解決這個問題的辦法
分布式 + 集群簡介：
分布式系統（distributed system）
由多臺計算機和通信的軟件組件通過計算機網絡連接（本地網絡或廣域網）組成。分布式系統是建立在網絡之上的軟件系統。正是因為軟件的特性，所以分布式系統具有高度的內聚性和透明性。因此，網絡和分布式系統之間的區別更多的在於高層軟件（特別是操作系統），而不是硬件。分布式系統可以應用在在不同的平臺上如：Pc、工作站、局域網和廣域網上等。
簡單來講：
1分布式：不同的多臺服務器上面部署不同的服務模塊（工程），他們之間通過Rpc/Rmi之間通信和調用，對外提供服務和組內協作。
2集群：不同的多臺服務器上面部署相同的服務模塊，通過分布式調度軟件進行統一的調度，對外提供服務和訪問。
1.NoSQL入門和概述