標籤:

大數據量的存儲分表常見演算法

當一個應用的數據量大的時候,我們用單表和單庫來存儲會嚴重影響操作速度,如mysql的myisam存儲,我們經過測試,200w以下的時候,mysql的訪問速度都很快,但是如果超過200w以上的數據,他的訪問速度會急劇下降,影響到我們webapp的訪問速度,而且數據量太大的話,如果用單表存儲,就會使得系統相當的不穩定,mysql服務很容易掛掉。所以當數據量超過200w的時候,建議系統工程師還是考慮分表.

以下是幾種常見的分表演算法。

1.按自然時間來分表/分庫;

如一個應用的數據在一年後數據量會達到200w左右,那麼我們就可以考慮用一年的數據來做為一個表或者庫來存儲,例如,表名為app,那麼2010年的數據就是app_2010,app_2011;如果數據量在一個月就達到了200w左右,那麼我們就可以用月份來分,app_2010_01,app_2010_02.

2.按數字類型hash分表/分庫;

如果我們要存儲用戶的信息,我們應用的註冊量很大,我們用單表是不能滿足存儲需求的,那麼我們就可以用用戶的編號來進行hash,常見的是用取余操作,如果我們要分30張表來存儲用戶的信息,那麼用戶編號為1的用戶1%30=1,那麼我們就存在user_01表裡,如用戶的編號為500,那麼500%30=20,那麼我們就將此用戶的信息存儲在user_20的表裡.

3.按md5值來分表/分庫;

我們假設要存儲用戶上傳的文件,如果上傳量大的話,也會帶來系統的瓶頸問題,我們做過試驗,在一個文件夾下如果超過200個文件的話,文件的瀏覽效率會降低,當然,這個不屬於我們本文討論的範圍,這塊也要做散列操作.我們可以用文件的用戶名來md5或者用文件的md5校驗值來做,我們就可以用md5的前5位來做hash,這樣最多我們就可以得到5^5=3125個表,每次在存儲文件的時候,就可以用文件名的md5值的前5位來確定這個文件該存那張表.

4.實例:某微博的url加密演算法和存儲策略的猜想.

現在好多微博都用這樣的url來訪問,如果他們的域名為http://www.example.com,那麼如果你發微博的時候,你會發現你所發的url都變成了t.cn/Mx4ja1,這樣的形式,他們是怎麼進行這樣的轉換呢?我猜想就是用到了我們上面講的md5的存儲和查找規則,用你發的url來進行md5,得到md5值之後,如我們例子來說,就會用前6位來進行分表.

5.分表所帶來的問題.

分表也會帶來一系列的問題,如分頁的實現,統計的實現,如果我們要做一個所有數據的分頁,那麼我們得每張表都得遍歷一遍,這樣訪問效率會很低下.之前我嘗試過用mysql的代理來實現,最終用tcsql來實現了.

6.分表演算法的選擇.

首先,分表適合於沒有大的列表的應用來使用,要不然,會為這部分做好多額外的工作,如果你的應用數據量不是特別大的話,最好別用分表。呵呵,以前在做項目的時候,一項目經理要我們設計了一個千萬級別的分表演算法,而應用的pv不會超過100,總有點大炮打蚊子的感覺,而且因為分表,把整個項目的工期拖延了不少,得不償失。當一個應用的數據量大的時候,我們用單表和單庫來存儲會嚴重影響操作速度,如mysql的myisam存儲,我們經過測試,200w以下的時候,mysql的訪問速度都很快,但是如果超過200w以上的數據,他的訪問速度會急劇下降,影響到我們webapp的訪問速度,而且數據量太大的話,如果用單表存儲,就會使得系統相當的不穩定,mysql服務很容易掛掉。所以當數據量超過200w的時候,建議系統工程師還是考慮分表.

以下是幾種常見的分表演算法。

1.按自然時間來分表/分庫;

如一個應用的數據在一年後數據量會達到200w左右,那麼我們就可以考慮用一年的數據來做為一個表或者庫來存儲,例如,表名為app,那麼2010年的數據就是app_2010,app_2011;如果數據量在一個月就達到了200w左右,那麼我們就可以用月份來分,app_2010_01,app_2010_02.

2.按數字類型hash分表/分庫;

如果我們要存儲用戶的信息,我們應用的註冊量很大,我們用單表是不能滿足存儲需求的,那麼我們就可以用用戶的編號來進行hash,常見的是用取余操作,如果我們要分30張表來存儲用戶的信息,那麼用戶編號為1的用戶1%30=1,那麼我們就存在user_01表裡,如用戶的編號為500,那麼500%30=20,那麼我們就將此用戶的信息存儲在user_20的表裡.

3.按md5值來分表/分庫;

我們假設要存儲用戶上傳的文件,如果上傳量大的話,也會帶來系統的瓶頸問題,我們做過試驗,在一個文件夾下如果超過200個文件的話,文件的瀏覽效率會降低,當然,這個不屬於我們本文討論的範圍,這塊也要做散列操作.我們可以用文件的用戶名來md5或者用文件的md5校驗值來做,我們就可以用md5的前5位來做hash,這樣最多我們就可以得到5^5=3125個表,每次在存儲文件的時候,就可以用文件名的md5值的前5位來確定這個文件該存那張表.

4.實例:某微博的url加密演算法和存儲策略的猜想.

現在好多微博都用這樣的url來訪問,如果他們的域名為http://www.example.com,那麼如果你發微博的時候,你會發現你所發的url都變成了t.cn/Mx4ja1,這樣的形式,他們是怎麼進行這樣的轉換呢?我猜想就是用到了我們上面講的md5的存儲和查找規則,用你發的url來進行md5,得到md5值之後,如我們例子來說,就會用前6位來進行分表.

5.分表所帶來的問題.

分表也會帶來一系列的問題,如分頁的實現,統計的實現,如果我們要做一個所有數據的分頁,那麼我們得每張表都得遍歷一遍,這樣訪問效率會很低下.之前我嘗試過用mysql的代理來實現,最終用tcsql來實現了.

6.分表演算法的選擇.

首先,分表適合於沒有大的列表的應用來使用,要不然,會為這部分做好多額外的工作,如果你的應用數據量不是特別大的話,最好別用分表。呵呵,以前在做項目的時候,一項目經理要我們設計了一個千萬級別的分表演算法,而應用的pv不會超過100,總有點大炮打蚊子的感覺,而且因為分表,把整個項目的工期拖延了不少,得不償失。


推薦閱讀:

TAG:資料庫設計 |