可動态擴充的分庫分表政策淺談

一般的系統總是由小到大發展的。一開始使用一個資料庫，而後逐漸擴充。在分庫過程中經常使用對特定的鍵值進行hash的辦法進行分庫分表。但是使用hash來進行分庫分表，在具體的應用中可能不能滿足需求。比如，在SAAS平台下，不同租戶的資料量是千差萬别的，根據二八現象，20%的租戶可能占用了80%的存儲資源。如果使用hash算法，很可能導緻資料分布不均勻。

這裡提出一個分庫分表算法，解決SAAS平台下，資料存儲的二八現象。

中繼資料準備

1. 業務資料按照租戶ID進行分庫。

2. 用一張表存儲，租戶ID->虛拟庫ID的映射關系，（可在啟動後，導入記憶體）。

3. 用另一張表存儲，虛拟庫ID->實際庫連接配接資訊（也可以在啟動後，導入記憶體）。

業務資料存取

1. 需要存儲資料前，先根據租戶ID（資料中總是帶有租戶ID），切換資料源

2. 資料源查找的過程，基本上是對上述兩張中繼資料表進行查找，先找到虛拟庫ID，進而找到實際的庫連接配接資訊。

3. 需要提取資料時，也按照上述方法找到實際的庫連接配接資訊，進行資料源切換。

分析

1. 之是以使用兩張表而不是一張表（直接租戶ID->實際庫連接配接資訊），是為了便于管理。及減少記憶體消耗。

2. 可以在虛拟庫ID上進行某種業務劃分，如，分為散戶，小客戶，普通客戶，大客戶，超大客戶。被劃分在同一個虛拟庫ID上的租戶必将共享一個實際的實體庫。是以在開始規劃的時候，應當盡量均勻地将租戶配置設定到不同的虛拟庫ID上。

3. 在虛拟庫ID上的資料是基本均勻的假設下，就可以将虛拟庫ID映射到實際的實體庫上。

4. 在實體庫擴充的情況下，可以将部分虛拟庫ID的資料，遷移到新的實體庫上。

實際案例模拟

1. 租戶A被配置設定了虛拟庫#12；虛拟庫#12實際處于實體庫#1上。

2. 由于實體庫#1已經負載過重，決定擴充一個實體庫#5，并把虛拟庫#12遷移到實體庫#5.

3. 停機（不知道有沒有更好的辦法），将虛拟庫#12的資料導出，導入到實體庫#5中。注意，此時虛拟庫#12的資料同時在#1和#5上。

4. 切換中繼資料表，進行驗證。如果驗證通過，則，擇機回收實體庫#1上的資料空間；如果驗證失敗，恢複中繼資料資訊，找到失敗原因，下次再做資料遷移。

利弊分析

1. 引入虛拟庫的原因是：一次可以将有邏輯關聯的一組租戶一并遷移，減少維護成本。

2. 該算法仍舊不支援“不停機”資料遷移，可能都不支援“部分停機，大部分不停機”資料遷移。