互聯(lián)網(wǎng)時代背景下大機遇，為什么用nosql

    1 單機MySQL的美好年代

    在90年代，一個網(wǎng)站的訪問量一般都不大，用單個數(shù)據(jù)庫完全可以輕松應(yīng)付。

    在那個時候，更多的都是靜態(tài)網(wǎng)頁，動態(tài)交互類型的網(wǎng)站不多。

    南安seo

    上述架構(gòu)下，我們來看看數(shù)據(jù)存儲的瓶頸是什么？

    1.數(shù)據(jù)量的總大小 一個機器放不下時

    2.數(shù)據(jù)的索引（B+ Tree）一個機器的內(nèi)存放不下時

    3.訪問量（讀寫混合）一個實例不能承受

    如果出現(xiàn)了上述1 or 3個上述瓶頸，架構(gòu)開始演化到下一個階段：

    2 Memcached（緩存）+MySQL+垂直拆分

    后來，隨著訪問量的上升，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫的壓力，優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力，但是當訪問量繼續(xù)增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術(shù)產(chǎn)品。

    南安seo

    Memcached作為一個獨立的分布式的緩存服務(wù)器，為多個web服務(wù)器提供了一個共享的高性能緩存服務(wù)，在Memcached服務(wù)器上，又發(fā)展了根據(jù)hash算法來進行多臺Memcached緩存服務(wù)的擴展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導致重新hash帶來的大量緩存失效的弊端

    局限性：Memcached只能緩解數(shù)據(jù)庫的讀取壓力。對于大量寫入的應(yīng)用場景無法緩解。

    3 Mysql主從讀寫分離

    由于數(shù)據(jù)庫的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫的讀取壓力。讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負，大部分網(wǎng)站開始使用主從復制技術(shù)來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網(wǎng)站標配了。

    南安seo

    4 分表分庫+水平拆分+mysql集群

    在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎(chǔ)之上，這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會出現(xiàn)嚴重的鎖問題，大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。

    PS： MyISAM引擎用的是表鎖，InnoDB引擎用的是行鎖

    南安seo

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

    分庫：將業(yè)務(wù)相關(guān)的數(shù)據(jù)表放在同一個庫中。同時，還可以按照數(shù)據(jù)的冷熱、相關(guān)性來分庫。

    當同一張表的數(shù)據(jù)量很大時，也需要分庫分表。如記錄ID1-100000的進1號庫，100001-200000進2號庫……

    5 MySQL的擴展性瓶頸

    MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段，導致數(shù)據(jù)庫表非常的大，在做數(shù)據(jù)庫恢復的時候就導致非常的慢，不容易快速恢復數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變得非常的小。關(guān)系數(shù)據(jù)庫很強大，但是它并不能很好的應(yīng)付所有的應(yīng)用場景。MySQL的擴展性差（需要復雜的技術(shù)來實現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當前使用MySQL的開發(fā)人員面臨的問題。

    還有如視頻、大圖片等等，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫并不適合作為數(shù)據(jù)存儲的方案。

    6 今天是什么樣子？？

    負載均衡——Nginx

    App服務(wù)器——Tomcat

    數(shù)據(jù)庫（集群）——Mysql、Oracle

    緩存、Hadoop集群、實時通信服務(wù)器、流媒體服務(wù)器，還有電子郵件、圖片服務(wù)器等等

    南安seo

    7 為什么用NoSQL

    為什么使用NoSQL ?

    今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數(shù)據(jù)。用戶的個人信息，社交網(wǎng)絡(luò)，地理位置，用戶生成的數(shù)據(jù)和用戶操作日志已經(jīng)成倍的增加。我們?nèi)绻獙@些用戶數(shù)據(jù)進行挖掘，那SQL數(shù)據(jù)庫已經(jīng)不適合這些應(yīng)用了， NoSQL數(shù)據(jù)庫的發(fā)展也卻能很好的處理這些大的數(shù)據(jù)。

    社交這種描述人與人關(guān)系的數(shù)據(jù)，對于這種數(shù)據(jù) 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫不適合存儲和處理。

    南安seo

    2. NoSQL概述——四個點

    1 是什么

    NoSQL（NoSQL = Not Only SQL ），意即“不僅僅是SQL”，

    泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲。

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

    2 能干嘛

    1. 易擴展

    NoSQL數(shù)據(jù)庫種類繁多，但是一個共同的特點都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。

    數(shù)據(jù)之間無關(guān)系，這樣就非常容易擴展。也無形之間，在架構(gòu)的層面上帶來了可擴展的能力。

    2. 大數(shù)據(jù)量高性能

    NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。

    這得益于它的無關(guān)系性，數(shù)據(jù)庫的結(jié)構(gòu)簡單。

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

    在針對web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的Cache是記錄級的，

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

    redis每秒鐘寫8萬，讀11萬次

    3. 多樣靈活的數(shù)據(jù)模型

    NoSQL無需事先為要存儲的數(shù)據(jù)建立字段，隨時可以存儲自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫里，

    增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡直就是一個噩夢

    4. 傳統(tǒng)RDBMS VS NOSQL

    RDBMS vs NoSQL

    RDBMS

    - 高度組織化結(jié)構(gòu)化數(shù)據(jù)

    - 結(jié)構(gòu)化查詢語言（SQL）

    - 數(shù)據(jù)和關(guān)系都存儲在單獨的表中。

    - 數(shù)據(jù)操縱語言，數(shù)據(jù)定義語言

    - 嚴格的一致性

    - 基礎(chǔ)事務(wù)

    NoSQL

    - 代表著不僅僅是SQL

    - 沒有聲明性查詢語言

    - 沒有預(yù)定義的模式

    -鍵 - 值對存儲，列存儲，文檔存儲，圖形數(shù)據(jù)庫

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

    - 非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)

    - CAP定理

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

    3 去哪下

    memcached：但就高速緩存一件事而言，最快的還是memcached

    redis：但論數(shù)據(jù)類型豐富，redis和tair（阿里、美團）更出色

    Mongodb

    4 怎么玩

    KV——鍵值對

    Cache——緩存

    Persistence——持久化

    3. 互聯(lián)網(wǎng)數(shù)據(jù)的3V和3高及當下的NoSQL經(jīng)典應(yīng)用

    （1）3V和3高

    3V

    海量Volume

    多樣Variety

    實時Velocity

    3高

    高并發(fā)

    高可擴——橫向追加CPU或機器，構(gòu)建陣列或者集群。

    高性能

    （2）當下的NoSQL經(jīng)典應(yīng)用

    一個NoSql的應(yīng)用中各方面問題的解決方案要點：這里是從別的地方看到一個講稿中的例子，覺得不錯，所以把提綱列在這里，自己就不寫了。

    1趨冷的數(shù)據(jù)、不變的數(shù)據(jù)，如商品的基本信息，存放在關(guān)系型數(shù)據(jù)庫中。

    2商品描述、詳情、評價信息（多文字類），存放在MongoDB里。

    多文字信息描述類，IO讀寫性能變差

    文檔數(shù)據(jù)庫MongDB中

    3 商品的圖片

    商品圖片展現(xiàn)類

    分布式的文件系統(tǒng)中

    淘寶自己的TFS

    Google的GFS

    Hadoop的HDFS

    4 商品的關(guān)鍵字

    搜索引擎，淘寶內(nèi)用

    ISearch

    5 商品的波段性的熱點高頻信息

    內(nèi)存數(shù)據(jù)庫

    tair、Redis、Memcache

    例如，情人節(jié)期間，電商網(wǎng)站的巧克力、玫瑰等會成為熱搜詞匯，這時候就將其放在redis等緩存中

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

    外部系統(tǒng)，外部第3方支付接口

    支付寶

    （3）總結(jié)大型互聯(lián)網(wǎng)應(yīng)用（大數(shù)據(jù)、高并發(fā)、多樣數(shù)據(jù)類型）的難點和解決方案

    難點

    數(shù)據(jù)類型多樣性

    數(shù)據(jù)源多樣性和變化重構(gòu)

    數(shù)據(jù)源改造而數(shù)據(jù)服務(wù)平臺不需要大面積重構(gòu)

    解決辦法

    EAI和統(tǒng)一數(shù)據(jù)平臺服務(wù)層