前言
你是否在為系統(tǒng)的數(shù)據(jù)庫來一波大流量就幾乎打滿CPU，日常CPU居高不下煩惱,？你是否在各種NoSql間糾結(jié)不定,，到底該選用那種最好？今天的你就是昨天的我,，這也是寫這篇文章的初衷。 這篇文章是我好幾個月來一直想寫的一篇文章,，也是一直想學習的一個內(nèi)容,，作為互聯(lián)網(wǎng)從業(yè)人員，我們要知道關(guān)系型數(shù)據(jù)庫（MySql,、Oracle）無法滿足我們對存儲的所有要求,，因此對底層存儲的選型，對每種存儲引擎的理解非常重要,。同時也由于過去一段時間的工作經(jīng)歷,，對這塊有了一些更多的思考，想通過自己的總結(jié)把這塊寫出來分享給大家,。 結(jié)構(gòu)化數(shù)據(jù),、非結(jié)構(gòu)化數(shù)據(jù)與半結(jié)構(gòu)化數(shù)據(jù)文章的開始，聊一下結(jié)構(gòu)化數(shù)據(jù),、非結(jié)構(gòu)化數(shù)據(jù)與半結(jié)構(gòu)化數(shù)據(jù),，因為數(shù)據(jù)特點的不同，將在技術(shù)上直接影響存儲引擎的選型,。 首先是結(jié)構(gòu)化數(shù)據(jù),，根據(jù)定義結(jié)構(gòu)化數(shù)據(jù)指的是由二維表結(jié)構(gòu)來邏輯表達和實現(xiàn)的數(shù)據(jù)，嚴格遵循數(shù)據(jù)格式與長度規(guī)范,，也稱作為行數(shù)據(jù),，特點為：數(shù)據(jù)以行為單位，一行數(shù)據(jù)表示一個實體的信息,，每一行數(shù)據(jù)的屬性是相同的,。例如： 因此關(guān)系型數(shù)據(jù)庫完美契合結(jié)構(gòu)化數(shù)據(jù)的特點，關(guān)系型數(shù)據(jù)庫也是關(guān)系型數(shù)據(jù)最主要的存儲與管理引擎,。 非結(jié)構(gòu)化數(shù)據(jù),，指的是數(shù)據(jù)結(jié)構(gòu)不規(guī)則或不完整，沒有任何預定義的數(shù)據(jù)模型,，不方便用二維邏輯表來表現(xiàn)的數(shù)據(jù),，例如辦公文檔（Word）、文本,、圖片,、HTML、各類報表,、視頻音頻等,。 介于結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)之間的數(shù)據(jù)就是半結(jié)構(gòu)化數(shù)據(jù)了，它是結(jié)構(gòu)化數(shù)據(jù)的一種形式,，雖然不符合二維邏輯這種數(shù)據(jù)模型結(jié)構(gòu),，但是包含相關(guān)標記，用來分割語義元素以及對記錄和字段進行分層,。常見的半結(jié)構(gòu)化數(shù)據(jù)有XML和JSON,，例如： <person> <name>張三</name> <age>18</age> <phone>12345</phone></person> 這種結(jié)構(gòu)也被成為自描述的結(jié)構(gòu)。 以關(guān)系型數(shù)據(jù)庫的方式做存儲的架構(gòu)演進首先,，我們看一下使用關(guān)系型數(shù)據(jù)庫的方式,，企業(yè)一個系統(tǒng)發(fā)展的幾個階段的架構(gòu)演進（由于本文寫的是Sql與NoSql，因此只以存儲方式作為切入點,，不會涉及類似MQ,、ZK這些中間件內(nèi)容）： 階段一：企業(yè)剛發(fā)展的階段,，最簡單,，一個應用服務器配一個關(guān)系型數(shù)據(jù)庫，每次讀寫數(shù)據(jù)庫,。 階段二：無論是使用MySQL還是Oracle還是別的關(guān)系型數(shù)據(jù)庫,，數(shù)據(jù)庫通常不會先成為性能瓶頸，通常隨著企業(yè)規(guī)模的擴大,，一臺應用服務器扛不住上游過來的流量且一臺應用服務器會產(chǎn)生單點故障的問題,，因此加應用服務器并且在流量入口使用Nginx做一層負載均衡，保證把流量均勻打到應用服務器上,。 階段三：隨著企業(yè)規(guī)模的繼續(xù)擴大,，此時由于讀寫都在同一個數(shù)據(jù)庫上，數(shù)據(jù)庫性能出現(xiàn)一定的瓶頸，此時簡單地做一層讀寫分離,，每次寫主庫,，讀備庫，主備庫之間通過binlog同步數(shù)據(jù),，就能很大程度上解決這個階段的數(shù)據(jù)庫性能問題 階段四：企業(yè)發(fā)展越來越好了,，業(yè)務越來越大了，做了讀寫分離數(shù)據(jù)庫壓力還是越來越大,，這時候怎么辦呢,，一臺數(shù)據(jù)庫扛不住，那我們就分幾臺吧,，做分庫分表,，對表做垂直拆分，對庫做水平拆分,。以擴數(shù)據(jù)庫為例,，擴出兩臺數(shù)據(jù)庫，以一定的單號（例如交易單號）,，以一定的規(guī)則（例如取模）,，交易單號對2取模為0的丟到數(shù)據(jù)庫1去，交易單號對2取模為1的丟到數(shù)據(jù)庫2去,，通過這樣的方式將寫數(shù)據(jù)庫的流量均分到兩臺數(shù)據(jù)庫上,。一般分庫分表會使用Shard的方式，通過一個中間件,，便于連接管理、數(shù)據(jù)監(jiān)控且客戶端無需感知數(shù)據(jù)庫ip 關(guān)系型數(shù)據(jù)庫的優(yōu)點上面的方式,，看似可以解決問題（實際上確實也能解決很多問題）,，正常對關(guān)系型數(shù)據(jù)庫做一下讀寫分離 + 分庫分表，支撐個1W+的讀寫QPS還是問題不大的,。但是受限于關(guān)系型數(shù)據(jù)庫本身,，這套架構(gòu)方案依然有著明顯的不足，下面對利用關(guān)系型數(shù)據(jù)庫方式做存儲的方案的優(yōu)點先進行一下分析,，后一部分再分析一下缺點,，對某個技術(shù)的優(yōu)缺點的充分理解是技術(shù)選型的前提。
因為行 + 列的二維表邏輯是非常貼近邏輯世界的一個概念,，關(guān)系模型相對網(wǎng)狀,、層次等其他模型更加容易被理解
通用的SQL語言使得操作關(guān)系型數(shù)據(jù)庫非常方便，支持join等復雜查詢
支持ACID特性,，可以維護數(shù)據(jù)之間的一致性,，這是使用數(shù)據(jù)庫非常重要的一個理由之一，例如同銀行轉(zhuǎn)賬，張三轉(zhuǎn)給李四100元錢,，張三扣100元,，李四加100元，而且必須同時成功或者同時失敗,，否則就會造成用戶的資損
數(shù)據(jù)持久化到磁盤,，沒有丟失數(shù)據(jù)風險，支持海量數(shù)據(jù)存儲
最常用的關(guān)系型數(shù)據(jù)庫產(chǎn)品MySql,、Oracle服務器性能卓越,，服務穩(wěn)定，通常很少出現(xiàn)宕機異常 關(guān)系型數(shù)據(jù)庫的缺點 緊接著的,，我們看一下關(guān)系型數(shù)據(jù)庫的缺點,，也是比較明顯的。
數(shù)據(jù)按行存儲,，即使只針對其中某一列進行運算,，也會將整行數(shù)據(jù)從存儲設備中讀入內(nèi)存，導致IO較高
為了提供豐富的查詢能力,，通常熱點表都會有多個二級索引,，一旦有了二級索引，數(shù)據(jù)的新增必然伴隨著所有二級索引的新增,，數(shù)據(jù)的更新也必然伴隨著所有二級索引的更新,，這不可避免地降低了關(guān)系型數(shù)據(jù)庫的讀寫能力，且索引越多讀寫能力越差,。有機會的話可以看一下自己公司的數(shù)據(jù)庫,，除了數(shù)據(jù)文件不可避免地占空間外，索引占的空間其實也并不少
數(shù)據(jù)一致性是關(guān)系型數(shù)據(jù)庫的核心,，但是同樣為了維護數(shù)據(jù)一致性的代價也是非常大的,。我們都知道SQL標準為事務定義了不同的隔離級別，從低到高依次是讀未提交,、讀已提交,、可重復度、串行化,，事務隔離級別月底,，可能出現(xiàn)的并發(fā)異常越多，但是通常而言能提供的并發(fā)能力越強,。那么為了保證事務一致性,，數(shù)據(jù)庫就需要提供并發(fā)控制與故障恢復兩種技術(shù)，前者用于減少并發(fā)異常,，后者可以在系統(tǒng)異常的時候保證事務與數(shù)據(jù)庫狀態(tài)不會被破壞,。對于并發(fā)控制,，其核心思想就是加鎖，無論是樂觀鎖還是悲觀鎖,，只要提供的隔離級別越高,，那么讀寫性能必然越差
前文提過，隨著企業(yè)規(guī)模擴大,，一種方式是對數(shù)據(jù)庫做分庫,，做了分庫之后，數(shù)據(jù)遷移（1個庫的數(shù)據(jù)按照一定規(guī)則打到2個庫中）,、跨庫join（訂單數(shù)據(jù)里有用戶數(shù)據(jù),，兩條數(shù)據(jù)不在同一個庫中）、分布式事務處理都是需要考慮的問題,，尤其是分布式事務處理,，業(yè)界當前都沒有特別好的解決方案
由于數(shù)據(jù)庫存儲的是結(jié)構(gòu)化數(shù)據(jù)，因此表結(jié)構(gòu)schema是固定的,，擴展不方便,，如果需要修改表結(jié)構(gòu)，需要執(zhí)行DDL（data definition language）語句修改,，修改期間會導致鎖表,，部分服務不可用
例如like '%中國真?zhèn)ゴ?'，只能搜索到'2019年中國真?zhèn)ゴ?，愛祖?,，無法搜索到'中國真是太偉大了'這樣的文本，即不具備分詞能力,，且like查詢在'%中國真?zhèn)ゴ?這樣的搜索條件下,，無法命中索引，將會導致查詢效率大大降低 寫了這么多,，我的理解核心還是前三點,，它反映出的一個問題是關(guān)系型數(shù)據(jù)庫在高并發(fā)下的能力是有瓶頸的，尤其是寫入/更新頻繁的情況下,，出現(xiàn)瓶頸的結(jié)果就是數(shù)據(jù)庫CPU高、Sql執(zhí)行慢,、客戶端報數(shù)據(jù)庫連接池不夠等錯誤,，因此例如萬人秒殺這種場景，我們絕對不可能通過數(shù)據(jù)庫直接去扣減庫存,。 可能有朋友說,，數(shù)據(jù)庫在高并發(fā)下的能力有瓶頸，我公司有錢,，加CPU,、換固態(tài)硬盤、繼續(xù)買服務器加數(shù)據(jù)庫做分庫不就好了，問題是這是一種性價比非常低的方式,，花1000萬達到的效果,，換其他方式可能100萬就達到了，不考慮人員,、服務器投入產(chǎn)出比的Leader就是個不合格的Leader,，且關(guān)系型數(shù)據(jù)庫的方式，受限于它本身的特點,，可能花了錢都未必能達到想要的效果,。至于什么是花100萬就能達到花1000萬效果的方式呢？可以繼續(xù)往下看,，這就是我們要說的NoSql,。 結(jié)合NoSql的方式做存儲的架構(gòu)演進像上文分析的，數(shù)據(jù)庫作為一種關(guān)系型數(shù)據(jù)的存儲引擎,，存儲的是關(guān)系型數(shù)據(jù),，它有優(yōu)點，同時也有明顯的缺點,，因此通常在企業(yè)規(guī)模不斷擴大的情況下,，不會一味指望通過增強數(shù)據(jù)庫的能力來解決數(shù)據(jù)存儲問題，而是會引入其他存儲,，也就是我們說的NoSql,。 NoSql的全稱為Not Only SQL，泛指非關(guān)系型數(shù)據(jù)庫,，是對關(guān)系型數(shù)據(jù)庫的一種補充,，特別注意補充這兩個字，這意味著NoSql與關(guān)系型數(shù)據(jù)庫并不是對立關(guān)系,，二者各有優(yōu)劣,，取長補短，在合適的場景下選擇合適的存儲引擎才是正確的做法,。 比較簡單的NoSql就是緩存： 針對那些讀遠多于寫的數(shù)據(jù)，引入一層緩存,，每次讀從緩存中讀取,，緩存中讀取不到，再去數(shù)據(jù)庫中取,，取完之后再寫入到緩存,，對數(shù)據(jù)做好失效機制通常就沒有大問題了。通常來說,，緩存是性能優(yōu)化的第一選擇也是見效最明顯的方案,。 但是,，緩存通常都是KV型存儲且容量有限（基于內(nèi)存），無法解決所有問題,，于是再進一步的優(yōu)化,，我們繼續(xù)引入其他NoSql： 數(shù)據(jù)庫,、緩存與其他NoSql并行工作,，充分發(fā)揮每種NoSql的特點。當然NoSql在性能方面大大優(yōu)于關(guān)系挺數(shù)據(jù)庫的同時,，往往也伴隨著一些特性的缺失,，比較常見的就是事務功能的缺失。 下面看一下常用的NoSql及他們的代表產(chǎn)品,，并對每種NoSql的優(yōu)缺點和適用場景做一下分析,，便于熟悉每種NoSql的特點，方便技術(shù)選型,。 KV型NoSql（代表----Redis） KV型NoSql顧名思義就是以鍵值對形式存儲的非關(guān)系型數(shù)據(jù)庫,，是最簡單、最容易理解也是大家最熟悉的一種NoSql,，因此比較快地帶過,。Redis、MemCache是其中的代表,，Redis又是KV型NoSql中應用最廣泛的NoSql,，KV型數(shù)據(jù)庫以Redis為例，最大的優(yōu)點我總結(jié)下來就兩點：
因此,，KV型NoSql最大的優(yōu)點就是高性能,，利用Redis自帶的BenchMark做基準測試，TPS可達到10萬的級別,，性能非常強勁,。同樣的Redis也有所有KV型NoSql都有的比較明顯的缺點：
綜上所述,，KV型NoSql最合適的場景就是緩存的場景：
例如根據(jù)用戶id查詢用戶信息,，每次根據(jù)用戶id去緩存中查詢一把，查到數(shù)據(jù)直接返回,，查不到去關(guān)系型數(shù)據(jù)庫里面根據(jù)id查詢一把數(shù)據(jù)寫到緩存中去,。 搜索型NoSql（代表----ElasticSearch）傳統(tǒng)關(guān)系型數(shù)據(jù)庫主要通過索引來達到快速查詢的目的，但是在全文搜索的場景下,，索引是無能為力的,，like查詢一來無法滿足所有模糊匹配需求，二來使用限制太大且使用不當容易造成慢查詢,，搜索型NoSql的誕生正是為了解決關(guān)系型數(shù)據(jù)庫全文搜索能力較弱的問題,，ElasticSearch是搜索型NoSql的代表產(chǎn)品。 全文搜索的原理是倒排索引,，我們看一下什么是倒排索引,。要說倒排索引我們先看下什么是正排索引，傳統(tǒng)的正排索引是文檔-->關(guān)鍵字的映射,，例如'Tom is my friend'這句話,，會將其切分為'Tom'、'is',、'my',、'friend'四個單詞，在搜索的時候?qū)ξ臋n進行掃描,，符合條件的查出來,。這種方式原理非常簡單，但是由于其檢索效率太低,，基本沒什么實用價值,。 倒排索引則完全相反，它是關(guān)鍵字-->文檔的映射,，我用張表格展示一下就比較清楚了： 意思是我現(xiàn)在這里有'Tom is Tom'、'Tom is my friend',、'Thank you, Betty',、'Tom is Betty's husband'四句話，搜索引擎會根據(jù)一定的切分規(guī)則將這句話切成N個關(guān)鍵字,，并以關(guān)鍵字的維度維護關(guān)鍵字在每個文本中的出現(xiàn)次數(shù),。這樣下次搜索'Tom'的時候，由于Tom這個詞語在'Tom is Tom',、'Tom is my friend',、'Tom is Betty's husband'三句話中都有出現(xiàn),，因此這三條記錄都會被檢索出來，且由于'Tom is Tom'這句話中'Tom'出現(xiàn)了2次,，因此這條記錄對'Tom'這個單詞的匹配度最高,，最先展示。這就是搜索引擎倒排索引的基本原理,，假設某個關(guān)鍵字在某個文檔中出現(xiàn),，那么倒排索引中有兩部分內(nèi)容：
可以舉一反三，我們搜索'Betty Tom'這兩個詞語也是一樣,，搜索引擎將'Betty Tom'切分為'Tom',、'Betty'兩個單詞，根據(jù)開發(fā)者指定的滿足率,，比如滿足率=50%,，那么只要記錄中出現(xiàn)了兩個單詞之一的記錄都會被檢索出來，再按照匹配度進行展示,。 搜索型NoSql以ElasticSearch為例,，它的優(yōu)點為：
同樣,，ElasticSearch也有比較明顯的缺點：
因此,，搜索型NoSql最適用的場景就是有條件搜索尤其是全文搜索的場景,，作為關(guān)系型數(shù)據(jù)庫的一種替代方案。 另外,，搜索型數(shù)據(jù)庫還有一種特別重要的應用場景,。我們可以想，一旦對數(shù)據(jù)庫做了分庫分表后,，原來可以在單表中做的聚合操作,、統(tǒng)計操作是否統(tǒng)統(tǒng)失效？例如我把訂單表分16個庫,，1024張表,，那么訂單數(shù)據(jù)就散落在1024張表中，我想要統(tǒng)計昨天浙江省單筆成交金額最高的訂單是哪筆如何做,？我想要把昨天的所有訂單按照時間排序分頁展示如何做,？這就是文檔型NoSql的另一大作用了，我們可以把分表之后的數(shù)據(jù)統(tǒng)一打在文檔型NoSql中,，利用文檔型NoSql的搜索與聚合能力完成對全量數(shù)據(jù)的查詢,。 至于為什么把它放在KV型NoSql后面作為第二個寫呢，因為通常搜索型NoSql也會作為一層前置緩存,，來對關(guān)系型數(shù)據(jù)庫進行保護,。 列式NoSql（代表----HBase）列式NoSql,，大數(shù)據(jù)時代最具代表性的技術(shù)之一了，以HBase為代表,。 列式NoSql是基于列式存儲的,，那么什么是列式存儲呢，列式NoSql和關(guān)系型數(shù)據(jù)庫一樣都有主鍵的概念,，區(qū)別在于關(guān)系型數(shù)據(jù)庫是按照行組織的數(shù)據(jù)： 看到每行有name、phone,、address三個字段,，這是行式存儲的方式，且可以觀察id = 2的這條數(shù)據(jù),，即使phone字段沒有,，它也是占空間的。 列式存儲完全是另一種方式,，它是按每一列進行組織的數(shù)據(jù)： 這么做有什么好處呢,？大致有以下幾點：
第二點說到了數(shù)據(jù)壓縮,，什么意思呢，以比較常見的字典表壓縮方式舉例： 自己看圖理解一下,，應該就懂了。 接著繼續(xù)講講優(yōu)缺點,，列式NoSql,，以HBase為代表的，優(yōu)點為：
說了這么多HBase的優(yōu)點,，又到了說HBase缺點的時候了：
因此HBase比較適用于那種KV型的且未來無法預估數(shù)據(jù)增長量的場景,，另外HBase使用還是需要一定的經(jīng)驗,，主要體現(xiàn)在RowKey的設計上。 文檔型NoSql（代表----MongoDB）坦白講,，根據(jù)我的工作經(jīng)歷,，文檔型NoSql我只有比較淺的使用經(jīng)驗，因此這部分只能結(jié)合之前的使用與網(wǎng)上的文章大致給大家介紹一下,。 什么是文檔型NoSql呢,，文檔型NoSql指的是將半結(jié)構(gòu)化數(shù)據(jù)存儲為文檔的一種NoSql，文檔型NoSql通常以JSON或者XML格式存儲數(shù)據(jù),，因此文檔型NoSql是沒有Schema的,，由于沒有Schema的特性，我們可以隨意地存儲與讀取數(shù)據(jù),，因此文檔型NoSql的出現(xiàn)是解決關(guān)系型數(shù)據(jù)庫表結(jié)構(gòu)擴展不方便的問題的,。 MongoDB是文檔型NoSql的代表產(chǎn)品，同時也是所有NoSql產(chǎn)品中的明星產(chǎn)品之一,，因此這里以MongoDB為例,。按我的理解，作為文檔型NoSql,，MongoDB是一款完全和關(guān)系型數(shù)據(jù)庫對標的產(chǎn)品,，就我們從存儲上來看： 看到，關(guān)系型數(shù)據(jù)庫是按部就班地每個字段一列存,，在MongDB里面就是一個JSON字符串存儲,。關(guān)系型數(shù)據(jù)可以為name、phone建立索引,，MongoDB使用createIndex命令一樣可以為列建立索引,，建立索引之后可以大大提升查詢效率。其他方面而言,，就大的基本概念,，二者之間基本也是類似的：
因此,，對于MongDB,，我們只要理解成一個Free-Schema的關(guān)系型數(shù)據(jù)庫就完事了，它的優(yōu)缺點比較一目了然,，優(yōu)點：
缺點在于：
總而言之，MongDB的使用場景很大程度上可以對標關(guān)系型數(shù)據(jù)庫,，但是比較適合處理那些沒有join,、沒有強一致性要求且表Schema會常變化的數(shù)據(jù)。 總結(jié)：數(shù)據(jù)庫與NoSql及各種NoSql間的對比最后一部分,，做一個總結(jié),，本文歸根到底是兩個話題：
首先是第一個話題,，關(guān)系型數(shù)據(jù)庫與非關(guān)系型數(shù)據(jù)庫的選擇，在我理解里面無非就是兩點考慮：
第一點,，不多解釋應該都理解，非關(guān)系型數(shù)據(jù)庫都是通過犧牲了ACID特性來獲取更高的性能的,，假設兩張表之間有比較強的一致性需求,，那么這類數(shù)據(jù)是不適合放在非關(guān)系型數(shù)據(jù)庫中的,。 第二點，核心數(shù)據(jù)不走非關(guān)系型數(shù)據(jù)庫,，例如用戶表,、訂單表，但是這有一個前提,，就是這一類核心數(shù)據(jù)會有多種查詢模式,，例如用戶表有ABCD四個字段，可能根據(jù)AB查,，可能根據(jù)AC查,，可能根據(jù)D查，假設核心數(shù)據(jù),，但是就是個KV形式,，比如用戶的聊天記錄，那么HBase一存就完事了,。 這幾年的工作經(jīng)驗來看,，非核心數(shù)據(jù)尤其是日志、流水一類中間數(shù)據(jù)千萬不要寫在關(guān)系型數(shù)據(jù)庫中,，這一類數(shù)據(jù)通常有兩個特點：
一旦使用關(guān)系型數(shù)據(jù)庫作為存儲引擎，將大大降低關(guān)系型數(shù)據(jù)庫的能力,，正常讀寫QPS不高的核心服務會受這一類數(shù)據(jù)讀寫的拖累,。 接著是第二個問題，如果我們使用非關(guān)系型數(shù)據(jù)庫作為存儲引擎,，那么如何選型,？其實上面的文章基本都寫了，這里只是做一個總結(jié)（所有的缺點都不會體現(xiàn)事務這個點,，因為這是所有NoSql相比關(guān)系型數(shù)據(jù)庫共有的一個問題）：
但是這里特別說明，選型一定要結(jié)合實際情況而不是照本宣科,，比如：
所以,，如果不考慮實際情況，雖然合適有些存儲引擎更加合適,，但是強行使用反而適得其反,，總而言之，適合自己的才是最好的,。 |
|
|
