2.1.1什麼是數據切分
"Shard" 這個詞英文的意思是"碎片"，而作爲數據庫相關的技術用語，似乎最早見於大型多人在線角色扮演遊戲中。"Sharding" 姑且稱之爲"分片"。Sharding 不是一門新技術，而是一個相對簡樸的軟件理念。衆所周知，MySQL 5 之後纔有了數據表分區功能，那麼在此之前，很多 MySQL 的潛在用戶都對 MySQL 的擴展性有所顧慮，而是否具備分區功能就成了衡量一個數據庫可擴展性與否的一個關鍵指標(當然不是唯一指標)。數據庫擴展性是一個永恆的話題，MySQL 的推廣者經常會被問到：如在單一數據庫上處理應用數據捉襟見肘而需要進行分區化之類的處理，是如何辦到的呢? 答案是：Sharding。 Sharding 不是一個某個特定數據庫軟件附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是爲突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。
通過一系列的切分規則將數據水平分佈到不同的DB或table中，在通過相應的DB路由 或者 table路由規則找到需要查詢的具體的DB或者table，以進行Query操作。這裏所說的“sharding”通常是指“水平切分”， 這也是本文討論的重點。具體將有什麼樣的切分方式呢和路由方式呢？行文至此，讀者難免有所疑問，接下來舉個簡單的例子：我們針對一個Blog應用中的日誌來說明，比如日誌文章（article）表有如下字段：
article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int)
面對這樣的一個表，我們怎樣切分呢？怎樣將這樣的數據分佈到不同的數據庫中的表中去呢？其實分析blog的應用，我們不難得出這樣的結論：blog的應用中，用戶分爲兩種：瀏覽者和blog的主人。瀏覽者瀏覽某個blog，實際上是在一個特定的用戶的blog下進行瀏覽的，而blog的主人管理自己的blog，也同樣是在特定的用戶blog下進行操作的（在自己的空間下）。所謂的特定的用戶，用數據庫的字段表示就是“user_id”。就是這個“user_id”，它就是我們需要的分庫的依據和規則的基礎。我們可以這樣做，將user_id爲 1～10000的所有的文章信息放入DB1中的article表中，將user_id爲10001～20000的所有文章信息放入DB2中的 article表中，以此類推，一直到DBn。 這樣一來，文章數據就很自然的被分到了各個數據庫中，達到了數據切分的目的。接下來要解決的問題就是怎樣找到具體的數據庫呢？其實問題也是簡單明顯的，既然分庫的時候我們用到了區分字段user_id，那麼很自然，數據庫路由的過程當然還是少不了 user_id的。考慮一下我們剛纔呈現的blog應用，不管是訪問別人的blog還是管理自己的blog，總之我都要知道這個blog的用戶是誰吧，也就是我們知道了這個blog的user_id，就利用這個user_id，利用分庫時候的規則，反過來定位具體的數據庫，比如user_id是234，利用該才的規則，就應該定位到DB1，假如user_id是12343，利用該才的規則，就應該定位到DB2。以此類推，利用分庫的規則，反向的路由到具體的DB，這個過程我們稱之爲“DB路由”。
當然考慮到數據切分的DB設計必然是非常規，不正統的DB設計。那麼什麼樣的DB設計是正統的DB設計呢？
我們平常規規矩矩用的基本都是。平常我們會自覺的按照範式來設計我們的數據庫，負載高點可能考慮使用相關的Replication機制來提高讀寫的吞吐和性能，這可能已經可以滿足很多需求，但這套機制自身的缺陷還是比較顯而易見的（下文會提及）。上面提到的“自覺的按照範式設計”。考慮到數據切分的DB設計，將違背這個通常的規矩和約束，爲了切分，我們不得不在數據庫的表中出現冗餘字段，用作區分字段或者叫做分庫的標記字段，比如上面的article的例子中的user_id這樣的字段（當然，剛纔的例子並沒有很好的體現出user_id的冗餘性，因爲user_id這個字段即使就是不分庫，也是要出現的，算是我們撿了便宜吧）。當然冗餘字段的出現並不只是在分庫的場景下才出現的，在很多大型應用中，冗餘也是必須的，這個涉及到高效DB的設計，本文不再贅述。
2.1.2爲什麼要數據切分
上面對什麼是數據切分做了個概要的描述和解釋，讀者可能會疑問，爲什麼需要數據切分呢？像 Oracle這樣成熟穩定的數據庫，足以支撐海量數據的存儲與查詢了？爲什麼還需要數據切片呢？的確，Oracle的DB確實很成熟很穩定，但是高昂的使用費用和高端的硬件支撐不是每一個公司能支付的起的。試想一下一年幾千萬的使用費用和動輒上千萬元的小型機作爲硬件支撐，這是一般公司能支付的起的嗎？即使就是能支付的起，假如有更好的方案，有更廉價且水平擴展性能更好的方案，我們爲什麼不選擇呢？
但是，事情總是不盡人意。平常我們會自覺的按照範式來設計我們的數據庫，負載高點可能考慮使用相關的Replication機制來提高讀寫的吞吐和性能，這可能已經可以滿足很多需求，但這套機制自身的缺陷還是比較顯而易見的。首先它的有效很依賴於讀操作的比例，Master往往會成爲瓶頸所在，寫操作需要順序排隊來執行，過載的話Master首先扛不住，Slaves的數據同步的延遲也可能比較大，而且會大大耗費CPU的計算能力，因爲write操作在Master上執行以後還是需要在每臺slave機器上都跑一次。這時候 Sharding可能會成爲雞肋了。 Replication搞不定，那麼爲什麼Sharding可以工作呢？道理很簡單，因爲它可以很好的擴展。我們知道每臺機器無論配置多麼好它都有自身的物理上限，所以當我們應用已經能觸及或遠遠超出單臺機器的某個上限的時候，我們惟有尋找別的機器的幫助或者繼續升級的我們的硬件，但常見的方案還是橫向擴展, 通過添加更多的機器來共同承擔壓力。我們還得考慮當我們的業務邏輯不斷增長，我們的機器能不能通過線性增長就能滿足需求？Sharding可以輕鬆的將計算，存儲，I/O並行分發到多臺機器上，這樣可以充分利用多臺機器各種處理能力，同時可以避免單點失敗，提供系統的可用性，進行很好的錯誤隔離。
綜合以上因素，數據切分是很有必要的，且我們在此討論的數據切分也是將MySql作爲背景的。基於成本的考慮，很多公司也選擇了Free且Open的MySql。對MySql有所瞭解的開發人員可能會知道，MySQL 5 之後纔有了數據表分區功能，那麼在此之前，很多 MySQL 的潛在用戶都對 MySQL 的擴展性有所顧慮，而是否具備分區功能就成了衡量一個數據庫可擴展性與否的一個關鍵指標(當然不是唯一指標)。數據庫擴展性是一個永恆的話題，MySQL 的推廣者經常會被問到：如在單一數據庫上處理應用數據捉襟見肘而需要進行分區化之類的處理，是如何辦到的呢? 答案也是Sharding，也就是我們所說的數據切分方案。
我們用免費的MySQL和廉價的Server甚至是PC做集羣，達到小型機+大型商業DB的效果，減少大量的資金投入，降低運營成本，何樂而不爲呢？所以，我們選擇Sharding，擁抱Sharding。
2.1.3怎麼做到數據切分
說到數據切分，再次我們講對數據切分的方法和形式進行比較詳細的闡述和說明。
數據切分可以是物理 上的，對數據通過一系列的切分規則將數據分佈到不同的DB服務器上，通過路由規則路由訪問特定的數據庫，這樣一來每次訪問面對的就不是單臺服務器了，而是N臺服務器，這樣就可以降低單臺機器的負載壓力。
數 據切分也可以是數據庫內的 ，對數據通過一系列的切分規則，將數據分佈到一個數據庫的不同表中，比如將article分爲article_001,article_002等子表，若干個子表水平拼合有組成了邏輯上一個完整的article表，這樣做的目的其實也是很簡單的。 舉個例子說明，比如article表中現在有5000w條數據，此時我們需要在這個表中增加（insert）一條新的數據，insert完畢後，數據庫會針對這張表重新建立索引，5000w行數據建立索引的系統開銷還是不容忽視的。但是反過來，假如我們將這個表分成100 個table呢，從article_001一直到article_100，5000w行數據平均下來，每個子表裏邊就只有50萬行數據，這時候我們向一張只有50w行數據的table中insert數據後建立索引的時間就會呈數量級的下降，極大了提高了DB的運行時效率，提高了DB的併發量。當然分表的好處還不知這些，還有諸如寫操作的鎖操作等，都會帶來很多顯然的好處。
綜上，分庫降低了單點機器的負載；分表，提高了數據操作的效率，尤其是Write操作的效率。 行文至此我們依然沒有涉及到如何切分的問題。接下來，我們將對切分規則進行詳盡的闡述和說明。
上文中提到，要想做到數據的水平切分，在每一個表中都要有相冗餘字符 作爲切分依據和標記字段，通常的應用中我們選用user_id作爲區分字段，基於此就有如下三種分庫的方式和規則： （當然還可以有其他的方式）
按號段分：
(1) user_id爲區分，1～1000的對應DB1，1001～2000的對應DB2，以此類推；
優點：可部分遷移
缺點：數據分佈不均
(2)hash取模分：
對user_id進行hash（或者如果user_id是數值型的話直接使用user_id 的值也可），然後用一個特定的數字，比如應用中需要將一個數據庫切分成4個數據庫的話，我們就用4這個數字對user_id的hash值進行取模運算，也就是user_id%4,這樣的話每次運算就有四種可能：結果爲1的時候對應DB1；結果爲2的時候對應DB2；結果爲3的時候對應DB3；結果爲0的時候對應DB4，這樣一來就非常均勻的將數據分配到4個DB中。
優點：數據分佈均勻
缺點：數據遷移的時候麻煩，不能按照機器性能分攤數據
(3)在認證庫中保存數據庫配置
就是建立一個DB，這個DB單獨保存user_id到DB的映射關係，每次訪問數據庫的時候都要先查詢一次這個數據庫，以得到具體的DB信息，然後才能進行我們需要的查詢操作。
優點：靈活性強，一對一關係
缺點：每次查詢之前都要多一次查詢，性能大打折扣
以上就是通常的開發中我們選擇的三種方式，有些複雜的項目中可能會混合使用這三種方式。 通過上面的描述，我們對分庫的規則也有了簡單的認識和了解。當然還會有更好更完善的分庫方式，還需要我們不斷的探索和發現