Mysql核心技術：用NOSql給高併發系統加速

推薦閱讀： 吊打面試官！MySQL靈魂100問，你能答出多少？

隨著網際網路大潮的到來，越來越多網站，應用系統需要海量資料的支撐，高併發、低延遲、高可用、高擴充套件等要求在傳統的關係型資料庫中已經得不到滿足，或者說關係型資料庫應對這些需求已經顯得力不從心了。關係型資料庫經過幾十年的發展已經很成熟，強大的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資料庫都不是銀彈，每一種事物都有它最善長的領域。設計一個好的系統，需要綜合考慮各種因素，根據具體的業務場景來選擇最合適的解決方案。