P：今天我們聊一下關於資料切片的方法
S: 可以。

P: 有時候我們會碰到資料量太大,單點容量無法支撐的情況;
這時候我們會需要進行分庫.

S：嗯，是的；基於硬體成本的考慮,我們不可能一性次分庫到位:一般是隨著資料量的增長逐次擴容分庫,

P: 是的，所以在定分庫方案的時候還需要考慮以後的擴容方案

S：比如我們是通過USERID來進行分庫:
一般有兩種方法:
1)用DB來實現
2)用HASH演算法

P： 逐個簡單描述一下：

S:  用RDB(關係資料庫)來實現 :
將每個USERID對應的DBID記錄下來,應用程式在啟動時將所有對應關係資料放在MEM CACHE中,
當用戶資料來訪問時,先去取得這個USERID對應的DBID,再進行相應的訪問.

P： 有沒有抽象表可以參考：

S： 嗯。
create table dbinfo ( dbid int , ip varchar(20) , port varchar(20) ) comment “DB 資訊表”
create table user_db ( userid int , dbid   int ) comment “USER與DB對應表” ;
create table user_data (userid int , userdata varchar(3000)) comment “使用者資料表“;

P： 使用者登陸時，怎麼找相應的庫？

S： 所以在MEMCACHE裡找，如果沒有，就到庫裡找：select db_id from user_db where userid=?  ;
找到了DBID也就找到了資料來源了；

P： 那新使用者進來，有多個DB時，按什麼規則進行分配

S： 比較簡單的是進行平均分配；

P:  那我擴容了怎麼辦？
原來有2個庫，我新加了一個庫，如果再按平均分配，不是前面的2個庫到一定的時候會爆掉？

S： 我們可以在dbinfo表裡加一個權重欄位，如果是新庫，權重設定大一點； 這樣大多數新使用者會往新庫裡去；
如果老的庫不想增加新使用者，可以把權重設定成0；

P：如果老的資料庫，雖然新使用者增加了； 但使用者的資料一直在增加，導致單點支撐不了，怎麼辦？

S：這時有兩種方法：
1） 把使用者的資料遷到其他的庫，並同時在user_db表中更改對應關係；
這樣的遷移只能由應用來逐個完成； 並且遷移速度比較慢；
2） 在資料庫級別作複製拆分；
把一個DB，複製一份出來，這時你擁有兩份相同的資料；
這裡應用只需要一邊重新整理MEMCACHE的對應，一邊把DB裡的對應改掉；速度快了很多；

P： 你還有一種切片思路呢？

S： 對於第2種切片思路，用HASH演算法，在DB這一級別完成；遷移擴容也很快；

P： 嗯。

S： 假如有應用，每個USER的資料量是基本一樣的； 不會出現某個使用者的資料量特別的情況；
那麼我們從使用者數來考慮就可以；
另外通過我們的評估，假設1024個伺服器絕對能滿足這個應用（當前我還沒有碰到過這麼大的MYSQL應用）

P： 嗯。

S： 我們先將每一個MACHINE（物理機）上只啟一個MYSQL例項；

S： 我們可以直接建1024個數據庫；
db0001 — db1024 ;

開始，使用者量很少； 我們可以將這1024個DB都放在同一個MACHINE1裡；

P： 資料大了咋辦？

S： 拆

當用戶量開始增長； 那麼我們可以將MACHINE1中的部分庫遷出來；放在MACHINE2裡；

這裡我們還需要有一個HASH值與連線池的對應關係表；

DB_HASH值 — MACHINE NUM
————————
100       1
400       2
600       3
1024      4

使用者進來,根據USER_ID進行HASH後, 比如VALUE=300,在2號庫裡去找庫：DB0300；

P:  哦，我們還可以將100–400 拆成 100–200，201–400 是吧。

S： 對的。

P： 直到拆到1024個MACHINE；

S： 這樣HASH，在DB0001 – DB1024 中的使用者數是應用是相對均勻的；
擴容也只要把部分的庫導到新的MACHINE中，比較方便；

P： 那如果我們已經拆到1024個庫了，在單個庫中，使用者資料量特別的大，出現單點支援不了的情況；

S： 嗯，這種情況還是存在的，如果真有這麼大的資料量，只能用二級HASH了。

P： HASH 到表級？

S： 對。
DBHASH值  TABHASH值  MACHINE_NUM
————————————
1          600         1
1          1024        10
400                  2
600                  3
1024                 4

不過這種切片方法還有一個缺點就是不支援單使用者級別的遷移；

P： 哦；明白了； 有沒有其他的思路了？

S： 我相信肯定還有更好的方法和思路。 路過的千萬別忘了把好方法寫上；

轉自：http://www.mysqlops.com/2011/06/18/data-distribution-architecture.html