超大數(shù)據(jù)量存儲(chǔ)常用數(shù)據(jù)庫(kù)分表分庫(kù)算法總結(jié)

當(dāng)一個(gè)應(yīng)用的數(shù)據(jù)量大的時(shí)候，我們用單表和單庫(kù)來(lái)存儲(chǔ)會(huì)嚴(yán)重影響操作速度，如mysql的myisam存儲(chǔ)，我們經(jīng)過(guò)測(cè)試，200w以下的時(shí)候，mysql的訪問(wèn)速度都很快，但是如果超過(guò)200w以上的數(shù)據(jù)，他的訪問(wèn)速度會(huì)急劇下降，影響到我們webapp的訪問(wèn)速度，而且數(shù)據(jù)量太大的話，如果用單表存儲(chǔ)，就會(huì)使得系統(tǒng)相當(dāng)?shù)牟环€(wěn)定，mysql服務(wù)很容易掛掉。所以當(dāng)數(shù)據(jù)量超過(guò)200w的時(shí)候，建議系統(tǒng)工程師還是考慮分表.

以下是幾種常見(jiàn)的分表算法。

1.按自然時(shí)間來(lái)分表/分庫(kù);

如一個(gè)應(yīng)用的數(shù)據(jù)在一年后數(shù)據(jù)量會(huì)達(dá)到200w左右，那么我們就可以考慮用一年的數(shù)據(jù)來(lái)做為一個(gè)表或者庫(kù)來(lái)存儲(chǔ)，例如，表名為app，那么2010年的數(shù)據(jù)就是app_2010，app_2011;如果數(shù)據(jù)量在一個(gè)月就達(dá)到了200w左右，那么我們就可以用月份來(lái)分，app_2010_01，app_2010_02.

2.按數(shù)字類型hash分表/分庫(kù);

如果我們要存儲(chǔ)用戶的信息，我們應(yīng)用的注冊(cè)量很大，我們用單表是不能滿足存儲(chǔ)需求的，那么我們就可以用用戶的編號(hào)來(lái)進(jìn)行hash，常見(jiàn)的是用取余操作，如果我們要分30張表來(lái)存儲(chǔ)用戶的信息，那么用戶編號(hào)為1的用戶1%30=1，那么我們就存在user_01表里，如用戶的編號(hào)為500，那么500%30=20，那么我們就將此用戶的信息存儲(chǔ)在user_20的表里.

3.按md5值來(lái)分表/分庫(kù);

我們假設(shè)要存儲(chǔ)用戶上傳的文件，如果上傳量大的話，也會(huì)帶來(lái)系統(tǒng)的瓶頸問(wèn)題，我們做過(guò)試驗(yàn)，在一個(gè)文件夾下如果超過(guò)200個(gè)文件的話，文件的瀏覽效率會(huì)降低，當(dāng)然，這個(gè)不屬于我們本文討論的范圍，這塊也要做散列操作.我們可以用文件的用戶名來(lái)md5或者用文件的md5校驗(yàn)值來(lái)做，我們就可以用md5的前5位來(lái)做hash，這樣最多我們就可以得到5^5=3125個(gè)表，每次在存儲(chǔ)文件的時(shí)候，就可以用文件名的md5值的前5位來(lái)確定這個(gè)文件該存那張表.

4.實(shí)例:某微博的url加密算法和存儲(chǔ)策略的猜想.

現(xiàn)在好多微博都用這樣的url來(lái)訪問(wèn)，如果他們的域名為www.example.com，那么如果你發(fā)微博的時(shí)候，你會(huì)發(fā)現(xiàn)你所發(fā)的url都變成了http://t.cn/Mx4ja1，這樣的形式，他們是怎么進(jìn)行這樣的轉(zhuǎn)換呢?我猜想就是用到了我們上面講的md5的存儲(chǔ)和查找規(guī)則，用你發(fā)的url來(lái)進(jìn)行md5，得到md5值之后，如我們例子來(lái)說(shuō)，就會(huì)用前6位來(lái)進(jìn)行分表.

5.分表所帶來(lái)的問(wèn)題.

分表也會(huì)帶來(lái)一系列的問(wèn)題，如分頁(yè)的實(shí)現(xiàn)，統(tǒng)計(jì)的實(shí)現(xiàn)，如果我們要做一個(gè)所有數(shù)據(jù)的分頁(yè)，那么我們得每張表都得遍歷一遍，這樣訪問(wèn)效率會(huì)很低下.之前我嘗試過(guò)用mysql的代理來(lái)實(shí)現(xiàn)，最終用tcsql來(lái)實(shí)現(xiàn)了.

6.分表算法的選擇.

如果你的應(yīng)用數(shù)據(jù)量不是特別大的話，最好別用分表。