***部分：實施策略

圖1.數(shù)據(jù)庫分庫分表(sharding)實施策略圖解

1.準備階段

對數(shù)據(jù)庫進行分庫分表(Sharding化)前，需要開發(fā)人員充分了解系統(tǒng)業(yè)務邏輯和數(shù)據(jù)庫schema.一個好的建議是繪制一張數(shù)據(jù)庫ER圖或領域模型圖，以這類圖為基礎劃分shard,直觀易行，可以確保開發(fā)人員始終保持清醒思路。對于是選擇數(shù)據(jù)庫ER圖還是領域模型圖要根據(jù)項目自身情況進行選擇。如果項目使用數(shù)據(jù)驅動的開發(fā)方式，團隊以數(shù)據(jù)庫ER圖作為業(yè)務交流的基礎，則自然會選擇數(shù)據(jù)庫ER圖，如果項目使用的是領域驅動的開發(fā)方式，并通過OR-Mapping構建了一個良好的領域模型，那么領域模型圖無疑是***的選擇。就我個人來說，更加傾向使用領域模型圖，因為進行切分時更多的是以業(yè)務為依據(jù)進行分析判斷，領域模型無疑更加清晰和直觀。

2.分析階段

1).垂直切分

垂直切分的依據(jù)原則是：將業(yè)務緊密，表間關聯(lián)密切的表劃分在一起，例如同一模塊的表。結合已經(jīng)準備好的數(shù)據(jù)庫ER圖或領域模型圖，仿照活動圖中的泳道概念，一個泳道代表一個shard，把所有表格劃分到不同的泳道中。下面的分析示例會展示這種做法。當然，你也可以在打印出的ER圖或模型圖上直接用鉛筆圈，一切取決于你自己的喜好。

2). 水平切分

垂直切分后，需要對shard內(nèi)表格的數(shù)據(jù)量和增速進一步分析，以確定是否需要進行水平切分。

2.1若劃分到一起的表格數(shù)據(jù)增長緩慢，在產(chǎn)品上線后可遇見的足夠長的時期內(nèi)均可以由單一數(shù)據(jù)庫承載，則不需要進行水平切分，所有表格駐留同一shard,所有表間關聯(lián)關系會得到***限度的保留，同時保證了書寫SQL的自由度，不易受join、group by、order by等子句限制。

2.2 若劃分到一起的表格數(shù)據(jù)量巨大，增速迅猛，需要進一步進行水平分割。進一步的水平分割就這樣進行：

2.2.1.結合業(yè)務邏輯和表間關系，將當前shard劃分成多個更小的shard,通常情況下，這些更小的shard每一個都只包含一個主表(將以該表ID進行散列的表)和多個與其關聯(lián)或間接關聯(lián)的次表。這種一個shard一張主表多張次表的狀況是水平切分的必然結果。這樣切分下來，shard數(shù)量就會迅速增多。如果每一個shard代表一個獨立的數(shù)據(jù)庫，那么管理和維護數(shù)據(jù)庫將會非常麻煩，而且這些小shard往往只有兩三張表，為此而建立一個新庫，利用率并不高，因此，在水平切分完成后可再進行一次“反向的Merge”,即：將業(yè)務上相近，并且具有相近數(shù)據(jù)增長速率(主表數(shù)據(jù)量在同一數(shù)量級上)的兩個或多個shard放到同一個數(shù)據(jù)庫上，在邏輯上它們依然是獨立的shard，有各自的主表，并依據(jù)各自主表的ID進行散列，不同的只是它們的散列取模(即節(jié)點數(shù)量)必需是一致的。這樣，每個數(shù)據(jù)庫結點上的表格數(shù)量就相對平均了。

2.2.2. 所有表格均劃分到合適的shard之后，所有跨越shard的表間關聯(lián)都必須打斷，在書寫sql時，跨shard的join、group by、order by都將被禁止，需要在應用程序層面協(xié)調(diào)解決這些問題。

特別想提一點：經(jīng)水平切分后，shard的粒度往往要比只做垂直切割的粒度要小，原單一垂直shard會被細分為一到多個以一個主表為中心關聯(lián)或間接關聯(lián)多個次表的shard，此時的shard粒度與領域驅動設計中的“聚合”概念不謀而合，甚至可以說是完全一致，每個shard的主表正是一個聚合中的聚合根!

3.實施階段

如果項目在開發(fā)伊始就決定進行分庫分表，則嚴格按照分析設計方案推進即可。如果是在中期架構演進中實施，除搭建實現(xiàn)sharding邏輯的基礎設施外(關于該話題會在下篇文章中進行闡述)，還需要對原有SQL逐一過濾分析，修改那些因為sharding而受到影響的sql.

第二部分：示例演示

本文選擇一個人盡皆知的應用：jpetstore來演示如何進行分庫分表(sharding)在分析階段的工作。由于一些個人原因，演示使用的jpetstore來自原ibatis官方的一個Demo版本，SVN地址為：http://mybatis.googlecode.com/svn/tags/java_release_2.3.4-726/jpetstore-5。關于jpetstore的業(yè)務邏輯這里不再介紹，這是一個非常簡單的電商系統(tǒng)原型，其領域模型如下圖：

圖2. jpetstore領域模型

由于系統(tǒng)較簡單，我們很容易從模型上看出，其主要由三個模塊組成：用戶，產(chǎn)品和訂單。那么垂直切分的方案也就出來了。接下來看水平切分，如果我們從一個實際的寵物店出發(fā)考慮，可能出現(xiàn)數(shù)據(jù)激增的單表應該是Account和Order,因此這兩張表需要進行水平切分。對于Product模塊來說，如果是一個實際的系統(tǒng)，Product和Item的數(shù)量都不會很大，因此只做垂直切分就足夠了，也就是(Product，Category，Item，Iventory，Supplier)五張表在一個數(shù)據(jù)庫結點上(沒有水平切分，不會存在兩個以上的數(shù)據(jù)庫結點)。但是作為一個演示，我們假設產(chǎn)品模塊也有大量的數(shù)據(jù)需要我們做水平切分，那么分析來看，這個模塊要拆分出兩個shard:一個是(Product(主)，Category)，另一個是(Item(主)，Iventory，Supplier)，同時，我們認為：這兩個shard在數(shù)據(jù)增速上應該是相近的，且在業(yè)務上也很緊密，那么我們可以把這兩個shard放在同一個數(shù)據(jù)庫節(jié)點上，Item和Product數(shù)據(jù)在散列時取一樣的模。根據(jù)前文介紹的圖紙繪制方法，我們得到下面這張sharding示意圖：

圖3. jpetstore sharding示意圖

對于這張圖再說明幾點：

1.使用泳道表示物理shard(一個數(shù)據(jù)庫結點)

2.若垂直切分出的shard進行了進一步的水平切分，但公用一個物理shard的話，則用虛線框住，表示其在邏輯上是一個獨立的shard。

3.深色實體表示主表

4.X表示需要打斷的表間關聯(lián)