1、為什么使用Nosql
1、單機Mysql時代
90年代,一個網(wǎng)站的訪問量一般不會太大，單個數(shù)據(jù)庫完全夠用。隨著用戶增多，網(wǎng)站出現(xiàn)以下問題
- 數(shù)據(jù)量增加到一定程度，單機數(shù)據(jù)庫就放不下了
- 數(shù)據(jù)的索引（B+ Tree）,一個機器內(nèi)存也存放不下
- 訪問量變大后（讀寫混合），一臺服務器承受不住。
2、Memcached(緩存) + Mysql + 垂直拆分（讀寫分離）
網(wǎng)站80%的情況都是在讀，每次都要去查詢數(shù)據(jù)庫的話就十分的麻煩！所以說我們希望減輕數(shù)據(jù)庫的壓力，我們可以使用緩存來保證效率！
優(yōu)化過程經(jīng)歷了以下幾個過程：
- 優(yōu)化數(shù)據(jù)庫的數(shù)據(jù)結構和索引(難度大)
- 文件緩存，通過IO流獲取比每次都訪問數(shù)據(jù)庫效率略高，但是流量爆炸式增長時候，IO流也承受不了
- MemCache,當時最熱門的技術，通過在數(shù)據(jù)庫和數(shù)據(jù)庫訪問層之間加上一層緩存，第一次訪問時查詢數(shù)據(jù)庫，將結果保存到緩存，后續(xù)的查詢先檢查緩存，若有直接拿去使用，效率顯著提升。
3、分庫分表 + 水平拆分 + Mysql集群
4、如今最近的年代
如今信息量井噴式增長，各種各樣的數(shù)據(jù)出現(xiàn)（用戶定位數(shù)據(jù)，圖片數(shù)據(jù)等），大數(shù)據(jù)的背景下關系型數(shù)據(jù)庫（RDBMS）無法滿足大量數(shù)據(jù)要求。Nosql數(shù)據(jù)庫就能輕松解決這些問題。
目前一個基本的互聯(lián)網(wǎng)項目
為什么要用NoSQL ？
用戶的個人信息，社交網(wǎng)絡，地理位置。用戶自己產(chǎn)生的數(shù)據(jù)，用戶日志等等爆發(fā)式增長！
這時候我們就需要使用NoSQL數(shù)據(jù)庫的，Nosql可以很好的處理以上的情況！
2、什么是Nosql
NoSQL = Not Only SQL（不僅僅是SQL）
Not Only Structured Query Language
關系型數(shù)據(jù)庫：列+行，同一個表下數(shù)據(jù)的結構是一樣的。
非關系型數(shù)據(jù)庫：數(shù)據(jù)存儲沒有固定的格式，并且可以進行橫向擴展。
NoSQL泛指非關系型數(shù)據(jù)庫，隨著web2.0互聯(lián)網(wǎng)的誕生，傳統(tǒng)的關系型數(shù)據(jù)庫很難對付web2.0時代！尤其是超大規(guī)模的高并發(fā)的社區(qū)，暴露出來很多難以克服的問題，NoSQL在當今大數(shù)據(jù)環(huán)境下發(fā)展的十分迅速，Redis是發(fā)展最快的。
3、Nosql特點
方便擴展（數(shù)據(jù)之間沒有關系，很好擴展?。?/p>
大數(shù)據(jù)量高性能（Redis一秒可以寫8萬次，讀11萬次，NoSQL的緩存記錄級，是一種細粒度的緩存，性能會比較高?。?/p>
數(shù)據(jù)類型是多樣型的?。ú恍枰孪仍O計數(shù)據(jù)庫，隨取隨用）
-
傳統(tǒng)的 RDBMS 和 NoSQL
傳統(tǒng)的 RDBMS(關系型數(shù)據(jù)庫) - 結構化組織 - SQL - 數(shù)據(jù)和關系都存在單獨的表中 row col - 操作，數(shù)據(jù)定義語言 - 嚴格的一致性 - 基礎的事務 - ...Nosql - 不僅僅是數(shù)據(jù) - 沒有固定的查詢語言 - 鍵值對存儲，列存儲，文檔存儲，圖形數(shù)據(jù)庫（社交關系） - 最終一致性 - CAP定理和BASE - 高性能，高可用，高擴展 - ...
了解：3V + 3高
大數(shù)據(jù)時代的3V ：主要是描述問題的
- 海量Velume
- 多樣Variety
- 實時Velocity
大數(shù)據(jù)時代的3高 ： 主要是對程序的要求
- 高并發(fā)
- 高可擴
- 高性能
真正在公司中的實踐：NoSQL + RDBMS 一起使用才是最強的。
4、阿里巴巴演進分析
推薦閱讀：阿里云的這群瘋子https://yq.aliyun.com/articles/653511
商品信息
- 一般存放在關系型數(shù)據(jù)庫：Mysql,阿里巴巴使用的Mysql都是經(jīng)過內(nèi)部改動的。
商品描述、評論(文字居多)
- 文檔型數(shù)據(jù)庫：MongoDB
圖片
- 分布式文件系統(tǒng) FastDFS
- 淘寶：TFS
- Google: GFS
- Hadoop: HDFS
- 阿里云: oss
商品關鍵字 用于搜索
- 搜索引擎：solr,elasticsearch
- 阿里：Isearch 多隆
商品熱門的波段信息
- 內(nèi)存數(shù)據(jù)庫：Redis，Memcache
商品交易，外部支付接口
- 第三方應用
5、Nosql的四大分類
KV鍵值對
- 新浪：Redis
- 美團：Redis + Tair
- 阿里、百度：Redis + Memcache
文檔型數(shù)據(jù)庫（bson數(shù)據(jù)格式）：
-
MongoDB(掌握)
- 基于分布式文件存儲的數(shù)據(jù)庫。C++編寫，用于處理大量文檔。
- MongoDB是RDBMS和NoSQL的中間產(chǎn)品。MongoDB是非關系型數(shù)據(jù)庫中功能最豐富的，NoSQL中最像關系型數(shù)據(jù)庫的數(shù)據(jù)庫。
- ConthDB
列存儲數(shù)據(jù)庫
- HBase(大數(shù)據(jù)必學)
- 分布式文件系統(tǒng)
圖關系數(shù)據(jù)庫
用于廣告推薦，社交網(wǎng)絡
- Neo4j、InfoGrid
| 分類 | Examples舉例 | 典型應用場景 | 數(shù)據(jù)模型 | 優(yōu)點 | 缺點 |
|---|---|---|---|---|---|
| 鍵值對（key-value） | Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB | 內(nèi)容緩存，主要用于處理大量數(shù)據(jù)的高訪問負載，也用于一些日志系統(tǒng)等等。 | Key 指向 Value 的鍵值對，通常用hash table來實現(xiàn) | 查找速度快 | 數(shù)據(jù)無結構化，通常只被當作字符串或者二進制數(shù)據(jù) |
| 列存儲數(shù)據(jù)庫 | Cassandra, HBase, Riak | 分布式的文件系統(tǒng) | 以列簇式存儲，將同一列數(shù)據(jù)存在一起 | 查找速度快，可擴展性強，更容易進行分布式擴展 | 功能相對局限 |
| 文檔型數(shù)據(jù)庫 | CouchDB, MongoDb | Web應用（與Key-Value類似，Value是結構化的，不同的是數(shù)據(jù)庫能夠了解Value的內(nèi)容） | Key-Value對應的鍵值對，Value為結構化數(shù)據(jù) | 數(shù)據(jù)結構要求不嚴格，表結構可變，不需要像關系型數(shù)據(jù)庫一樣需要預先定義表結構 | 查詢性能不高，而且缺乏統(tǒng)一的查詢語法。 |
| 圖形(Graph)數(shù)據(jù)庫 | Neo4J, InfoGrid, Infinite Graph | 社交網(wǎng)絡，推薦系統(tǒng)等。專注于構建關系圖譜 | 圖結構 | 利用圖結構相關算法。比如最短路徑尋址，N度關系查找等 | 很多時候需要對整個圖做計算才能得出需要的信息，而且這種結構不太好做分布式的集群 |
