程序員修神之路--用NOSql給高併發系統加速（送書）

隨着互聯網大潮的到來，愈來愈多網站，應用系統須要海量數據的支撐，高併發、低延遲、高可用、高擴展等要求在傳統的關係型數據庫中已經得不到知足，或者說關係型數據庫應對這些需求已經顯得力不從心了。關係型數據庫通過幾十年的發展已經很成熟，強大的sql語句支持，完美的ACID屬性的支持，使得關係型數據庫普遍應用於各類各樣的應用系統中，可是應用的場景普遍並不是意味着完美。

- 因爲關係型數據庫是按行進行存儲的，在某些只統計一列的需求場景下，也須要把整行讀入內存，致使了一個小小的統計需求高IO的缺點

- 關係型數據庫沒法存儲數據結構，好比：一個商品能夠從屬於多個分類，業務上的從屬關係體現到存儲上是一個列表而已，可是關係型數據庫須要把這些關係存儲爲多行，沒法直接存儲爲一個列表。

- 關係型數據庫中的存儲單位表的架構是強約束，操做不存在的列會報出異常，並且添加、更新、刪除列必須執行DDL語句，若是表的現存數據量比較大，會出現長時間鎖表的現象。

- 關係型數據庫全文搜索功能普通比較弱，用like去匹配關鍵詞的時候，數據量比較大的狀況下會出現慢查詢的現象。

- 關係型數據庫基於表格的關係模型使得很難添加新的或不一樣種類的關聯信息。

因爲以上這些諸多問題，便誕生了以「NOSQL」爲口號的不少解決方案。在某些關係型數據庫不擅長的領域，Nosql表現的很出色。上天是公平的，給你打開了一扇窗戶，必會給你關上半扇門，NoSql是以犧牲ACID某個或者某些特性爲代價的。

NoSQL並非銀彈，更多的時候是關係型數據庫一個有力補充，或者是特定場景下優於關係型數據庫的一種解決方案

NoSQL

NoSQL，泛指非關係型的數據庫。如今你們更喜歡翻譯成：not only sql

根據NoSQL的存儲等特性，大致能夠分爲如下幾類

- 鍵值(Key-Value)存儲數據庫。相關的產品：Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached。主要解決關係數據庫沒法存儲數據結構的問題。

- 列存儲數據庫。相關產品：BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS。解決關係數據庫大數據場景下的 I/O 問題

- 文檔數據庫。相關產品：MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit。解決關係數據庫強 schema 約束的問題。

- 圖形數據庫。相關產品：Neo4J、OrientDB、InfoGrid、GraphDB。主要解決大量複雜、互鏈接、低結構化的圖結構場合，如社交網絡、推薦系統等

- 全文搜索引擎。相關產品：Elasticsearch。主要解決關係數據庫的全文搜索性能問題。

因而可知，沒有哪種NoSql是完美的，每一種Nosql都有本身擅長的領域，這也是咱們作系統架構中要考慮的重要因素。

場景1

電商的商品設計過程當中，每種商品的屬性都不一樣，屬性數目不一樣，屬性名不一樣，同一個商品有可能會屬於多個分類，並且隨着業務的發展，不少商品會增長新的屬性，並且最令程序員頭疼莫過於每種屬性都有可能有搜索的可能性（固然搜索能夠利用搜索引擎來實現）。遇到這樣的需求場景，若是利用關係型數據庫來存儲的話，表的字段會很是多，並且字段的定義很是使人頭疼。

這樣的場景很是適合NOsql中的文檔型數據庫，好比MongoDB。文檔型數據庫新增字段很是簡單，不像關係型數據庫須要先執行DDL來增長字段，直接能夠利用程序來進行讀寫，歷史數據就算是沒有相應的字段也不會有異常的狀況發生。最重要的一點，文檔型數據庫很擅長存儲複雜結構的數據，通常狀況下業務上能夠利用表現能力很強的json數據結構。

{
    "Id":1,
    "ProductName":"杜蕾斯增強版",
    "Price":100,
    "Type":[
        1,
        2,
        4
    ],
    "Length":20,
    "Height":2

}

若是全部商品信息都用mongodb來存儲的話，有的場景並非十分完美。好比商品被成功購買以後扣庫存的問題，聯合查詢的問題，因爲Nosql天生對ACID支持不足的緣由，一個事務性的操做很難在Nosql中實現，因此設計系統的時候在不少狀況下是關係數據庫+Nosql 來共同實現業務。

場景2

不少具體的業務中都有記錄數據而後進行統計的需求場景，好比那些統計uv，pv的系統。日誌型的數據量很是大，並且還有可能有峯值的出現，若是用關係型數據庫來存儲，頗有可能在IO上會出現瓶頸，並且有可能會影響其餘正常的業務，更不幸的是當執行統計語句的時候，性能更是差強人意。這樣的日誌型統計業務很適合HBase這樣的列式Nosql，業務上要統計一天的uv，pv數據，HBase很適合統計某一列數據的場景，由於只須要把對應的列進行統計便可，不像關係型數據庫那樣須要把全部行都加載進內存，並且列式存儲通常比行式存儲擁有更大的壓縮比例，佔用的磁盤空間會更少。

列式存儲的應用場景有必定的限制，通常用於統計和大數據的分析中。

場景3

在多數高併發系統中都存在緩存的設計，而緩存的通常數據結構都是K-V結構。緩存是一種提升系統性能的有效手段，因其須要提供快速訪問的特性，通常緩存都放置於內存當中。好比如今咱們要設計一個用戶管理系統，每一個用戶信息能夠作緩存以便提供高速的訪問，因爲不少系統都採用分佈式的部署方式，因此採用進程內的緩存方式並不可取，這個時候就須要有一種高速的外部存儲來提供這種業務，這正是kv型Nosql的典型應用場景之一。其中以redis爲表明，具體的業務中能夠以用戶id爲key，用戶的信息爲value存儲在redis中，並且redis在3.0以後能夠作集羣了，在高可用和擴展上更能助力業務方。redis支持的數據類型不少，在不一樣的場景下選擇不一樣的數據類型。

場景4

當一個系統有搜索的業務時候，若是搜索的條件是一些簡單的類型搜索，關係型數據庫還能夠知足，可是若是有全文搜索，就是咱們平時sql寫的like ‘%xx%’這樣的搜索，關係型數據庫可能並非最好的選擇，全文搜索引擎類型的Nosql也許是一個更好的解決方案，其中以Elasticsearch 爲表明。全文搜索引擎的搜索的條件能夠隨意排列組合，而且能夠實現關係型數據庫like方式的模糊匹配。

全文搜索引擎的技術原理稱爲「倒排索引」（inverted index），是一種索引方法，其基本原理是創建單詞到文檔的索引。與之相對是，是「正排索引」，其基本原理是創建文檔到單詞的索引。

場景5

在社交系統中最多見例子就是社會網絡中人與人之間的關係。關係型數據庫用於存儲「關係型」數據的效果並很差，其查詢複雜、緩慢、超出預期，而圖形數據庫的獨特設計偏偏彌補了這個缺陷，解決關係型數據庫存儲和處理複雜關係型數據功能較弱的問題。其中以Neo4j爲表明。想深刻研究的同窗請移步百度。

不管是關係型數據庫仍是nosql數據庫都不是銀彈，每一種事物都有它最善長的領域。設計一個好的系統，須要綜合考慮各類因素，根據具體的業務場景來選擇最合適的解決方案。

領取福利

記得微信掃碼識別，領取技術書籍哦