對于數(shù)據(jù)切分，我們可能還不是很熟悉，但是它對于MySQL數(shù)據(jù)庫來說也是相當重要的一門技術(shù)，本文我們就詳細介紹一下MySQL數(shù)據(jù)庫的數(shù)據(jù)切分的相關(guān)知識，接下來就讓我們一起來了解一下這部分內(nèi)容。

什么是數(shù)據(jù)切分

"Shard" 這個詞英文的意思是"碎片"，而作為數(shù)據(jù)庫相關(guān)的技術(shù)用語，似乎最早見于大型多人在線角色扮演游戲中。"Sharding" 姑且稱之為"分片"。Sharding 不是一門新技術(shù)，而是一個相對簡樸的軟件理念。眾所周知，MySQL 5 之后才有了數(shù)據(jù)表分區(qū)功能，那么在此之前，很多MySQL的潛在用戶都對MySQL的擴展性有所顧慮，而是否具備分區(qū)功能就成了衡量一個數(shù)據(jù)庫可擴展性與否的一個關(guān)鍵指標(當然不是唯一指標)。

數(shù)據(jù)庫擴展性是一個永恒的話題，MySQL 的推廣者經(jīng)常會被問到：如在單一數(shù)據(jù)庫上處理應(yīng)用數(shù)據(jù)捉襟見肘而需要進行分區(qū)化之類的處理，是如何辦到的呢? 答案是：Sharding。  Sharding 不是一個某個特定數(shù)據(jù)庫軟件附屬的功能，而是在具體技術(shù)細節(jié)之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是為突破單節(jié)點數(shù)據(jù)庫服務(wù)器的 I/O 能力限制，解決數(shù)據(jù)庫擴展性問題。

通過一系列的切分規(guī)則將數(shù)據(jù)水平分布到不同的DB或table中，在通過相應(yīng)的DB路由 或者 table路由規(guī)則找到需要查詢的具體的DB或者table，以進行Query操作。這里所說的“sharding”通常是指“水平切分”， 這也是本文討 論的重點。具體將有什么樣的切分方式呢和路由方式呢？行文至此，讀者難免有所疑問，接下來舉個簡單的例子：我們針對一個Blog應(yīng)用中的日志來說明， 比如日志文章（article）表有如下字段：article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int).

面對這樣的一個表，我們怎樣切分呢？怎樣將這樣的數(shù)據(jù)分布到不同的數(shù)據(jù)庫中的表中去呢？其實 分析blog的應(yīng)用，我們不難得出這樣的結(jié)論：blog的應(yīng)用中，用戶分為兩種：瀏覽者和blog的主人。瀏覽者瀏覽某個blog，實際上是在一個特定的 用戶的blog下進行瀏覽的，而blog的主人管理自己的blog，也同樣是在特定的用戶blog下進行操作的（在自己的空間下）。所謂的特定的用戶，用數(shù)據(jù)庫的字段表示就是“user_id”。就是這個“user_id”，它就是我們需要的分庫的依據(jù)和規(guī)則的基礎(chǔ)。我們可以這樣做，將user_id為 1～10000的所有的文章信息放入DB1中的article表中，將user_id為10001～20000的所有文章信息放入DB2中的 article表中，以此類推，一直到DBn。 

這樣一來，文章數(shù)據(jù)就很自然的被分到了各個數(shù)據(jù)庫中，達到了數(shù)據(jù)切分的目的。接下來要解決的問題就是怎樣找 到具體的數(shù)據(jù)庫呢？其實問題也是簡單明顯的，既然分庫的時候我們用到了區(qū)分字段user_id，那么很自然，數(shù)據(jù)庫路由的過程當然還是少不了 user_id的?？紤]一下我們剛才呈現(xiàn)的blog應(yīng)用，不管是訪問別人的blog還是管理自己的blog，總之我都要知道這個blog的用戶是誰吧，也 就是我們知道了這個blog的user_id，就利用這個user_id，利用分庫時候的規(guī)則，反過來定位具體的數(shù)據(jù)庫，比如user_id是234，利 用該才的規(guī)則，就應(yīng)該定位到DB1，假如user_id是12343，利用該才的規(guī)則，就應(yīng)該定位到DB2。以此類推，利用分庫的規(guī)則，反向的路由到具體 的DB，這個過程我們稱之為“DB路由”。

當然考慮到數(shù)據(jù)切分的DB設(shè)計必然是非常規(guī)，不正統(tǒng)的DB設(shè)計。那么什么樣的DB設(shè)計是正統(tǒng)的DB設(shè)計呢？

我們平常規(guī)規(guī)矩矩用的基本都是。平常我們會自覺的按照范式來設(shè)計我們的數(shù)據(jù)庫，負載高點可能 考慮使用相關(guān)的Replication機制來提高讀寫的吞吐和性能，這可能已經(jīng)可以滿足很多需求，但這套機制自身的缺陷還是比較顯而易見的（下文會提 及）。上面提到的“自覺的按照范式設(shè)計”?？紤]到數(shù)據(jù)切分的DB設(shè)計，將違背這個通常的規(guī)矩和約束，為了切分，我們不得不在數(shù)據(jù)庫的表中出現(xiàn)冗余字段，用 作區(qū)分字段或者叫做分庫的標記字段，比如上面的article的例子中的user_id這樣的字段（當然，剛才的例子并沒有很好的體現(xiàn)出user_id的 冗余性，因為user_id這個字段即使就是不分庫，也是要出現(xiàn)的，算是我們撿了便宜吧）。當然冗余字段的出現(xiàn)并不只是在分庫的場景下才出現(xiàn)的，在很多大型應(yīng)用中，冗余也是必須的，這個涉及到高效DB的設(shè)計，本文不再贅述。

為什么要數(shù)據(jù)切分

上面對什么是數(shù)據(jù)切分做了個概要的描述和解釋，讀者可能會疑問，為什么需要數(shù)據(jù)切分呢？像 Oracle這樣成熟穩(wěn)定的數(shù)據(jù)庫，足以支撐海量數(shù)據(jù)的存儲與查詢了？為什么還需要數(shù)據(jù)切片呢？的確，Oracle的DB確實很成熟很穩(wěn)定，但是高昂的使 用費用和高端的硬件支撐不是每一個公司能支付的起的。試想一下一年幾千萬的使用費用和動輒上千萬元的小型機作為硬件支撐，這是一般公司能支付的起的嗎？即 使就是能支付的起，假如有更好的方案，有更廉價且水平擴展性能更好的方案，我們?yōu)槭裁床贿x擇呢？

但是，事情總是不盡人意。平常我們會自覺的按照范式來設(shè)計我們的數(shù)據(jù)庫，負載高點可能考慮使 用相關(guān)的Replication機制來提高讀寫的吞吐和性能，這可能已經(jīng)可以滿足很多需求，但這套機制自身的缺陷還是比較顯而易見的。首先它的有效很依賴 于讀操作的比例，Master往往會成為瓶頸所在，寫操作需要順序排隊來執(zhí)行，過載的話Master首先扛不住，Slaves的數(shù)據(jù)同步的延遲也可能比較大，而且會大大耗費CPU的計算能力，因為write操作在Master上執(zhí)行以后還是需要在每臺slave機器上都跑一次。這時候 Sharding可能會成為雞肋了。

Replication搞不定，那么為什么Sharding可以工作呢？道理很簡單，因為它可以很好的擴展。我們知道每臺機器無論配置多么好它都有自身的 物理上限，所以當我們應(yīng)用已經(jīng)能觸及或遠遠超出單臺機器的某個上限的時候，我們惟有尋找別的機器的幫助或者繼續(xù)升級的我們的硬件，但常見的方案還是橫向擴 展, 通過添加更多的機器來共同承擔壓力。我們還得考慮當我們的業(yè)務(wù)邏輯不斷增長，我們的機器能不能通過線性增長就能滿足需求？Sharding可以輕松的將計 算，存儲，I/O并行分發(fā)到多臺機器上，這樣可以充分利用多臺機器各種處理能力，同時可以避免單點失敗，提供系統(tǒng)的可用性，進行很好的錯誤隔離。

綜合以上因素，數(shù)據(jù)切分是很有必要的，且我們在此討論的數(shù)據(jù)切分也是將MySql作為背景的?；诔杀镜目紤]，很多公司也選擇了Free且Open的MySql。對MySql有所了解的開發(fā)人員可能會知道，MySQL 5之后才有了數(shù)據(jù)表分區(qū)功能，那么在此之前，很多MySQL的潛在用戶都對MySQL的擴展性有所顧慮，而是否具備分區(qū)功能就成了衡量一個數(shù)據(jù)庫可擴展性與否的一個關(guān)鍵指標(當然不是唯一指標)。數(shù)據(jù)庫擴展性是一個永恒的話題，MySQL的推廣者經(jīng)常會被問到：如在單一數(shù)據(jù)庫上處理應(yīng)用數(shù)據(jù)捉襟見肘而需要進行分區(qū)化之類的處理，是如何辦到的呢? 答案也是Sharding，也就是我們所說的數(shù)據(jù)切分方案。

怎么做到數(shù)據(jù)切分

說到數(shù)據(jù)切分，再次我們講對數(shù)據(jù)切分的方法和形式進行比較詳細的闡述和說明。

數(shù)據(jù)切分可以是物理上的，對數(shù)據(jù)通過一系列的切分規(guī)則將數(shù)據(jù)分布到不同的DB服務(wù)器上，通過路由規(guī)則路由訪問特定的數(shù)據(jù)庫，這樣一來每次訪問面對的就不是單臺服務(wù)器了，而是N臺服務(wù)器，這樣就可以降低單臺機器的負載壓力。

數(shù)據(jù)切分也可以是數(shù)據(jù)庫內(nèi)的 ，對數(shù)據(jù)通過一系列的切分規(guī)則，將數(shù)據(jù)分布到一個數(shù)據(jù)庫的不同表 中，比如將article分為article_001,article_002等子表，若干個子表水平拼合有組成了邏輯上一個完整的article表，這 樣做的目的其實也是很簡單的。 舉個例子說明，比如article表中現(xiàn)在有5000w條數(shù)據(jù)，此時我們需要在這個表中增加（insert）一條新的數(shù) 據(jù)，insert完畢后，數(shù)據(jù)庫會針對這張表重新建立索引，5000w行數(shù)據(jù)建立索引的系統(tǒng)開銷還是不容忽視的。

但是反過來，假如我們將這個表分成100 個table呢，從article_001一直到article_100，5000w行數(shù)據(jù)平均下來，每個子表里邊就只有50萬行數(shù)據(jù)，這時候我們向一張 只有50w行數(shù)據(jù)的table中insert數(shù)據(jù)后建立索引的時間就會呈數(shù)量級的下降，極大了提高了DB的運行時效率，提高了DB的并發(fā)量。當然分表的好 處還不知這些，還有諸如寫操作的鎖操作等，都會帶來很多顯然的好處。

綜上，分庫降低了單點機器的負載；分表，提高了數(shù)據(jù)操作的效率，尤其是Write操作的效率。 行文至此我們依然沒有涉及到如何切分的問題。接下來，我們將對切分規(guī)則進行詳盡的闡述和說明。

關(guān)于MySQL數(shù)據(jù)切分的相關(guān)概念和原理的知識就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@！

【編輯推薦】

1. Star Schema的設(shè)計思路與總結(jié)
2. MySQL性能分析及explain的使用
3. Oracle數(shù)據(jù)庫悲觀鎖與樂觀鎖詳解
4. SQL Server多表查詢優(yōu)化方案總結(jié)
5. Oracle執(zhí)行計劃不走索引的原因總結(jié)