【資料整理】分庫&分表

      此貼用于掃盲。

=============================== 

【分表】

（下面說到的内容都是基于“按照關系型資料庫的第三範式要求應該在同一個表的”的情況）

       分表，最直白的意思，就是将一個表結構分為多個表，分表後，可以存在于同一個庫裡，也可以放到不同的庫。

【為什麼要分表？】

        保證單表的容量不會太大，進而來保證單表的查詢等處理能力。例如單表記錄條數達到百萬到千萬級别時就要使用分表。

【分表方式？】

1.縱向分表

根據資料的活躍度進行拆分。

2.橫向分表

把大的表結構，橫向切割為同樣結構的不同表。

冷資料：變化頻率慢，查詢次數多的資料。冷資料使用 myisam 可以有更好的查詢性能。對冷資料，可以配置更多的從庫，因為大部分操作是查詢，可以加快查詢速度。

活躍資料：統計資訊，或者變化頻率比較高的資料。活躍資料可以使用 innodb ，可以有更好的更新速度。對熱資料，可以相對有更多的橫向分表處理。

===============================

【分庫】

【為什麼要分庫？】

       随着資料量增加也許單台db的存儲空間不夠，随着查詢量的增加單台資料庫伺服器已經沒辦法支撐。

【單庫單表 -> 單庫多表 -> 多庫多表】

       例如，有一張使用者(user)表放在資料庫db中，所有的使用者都可以在db庫中的user表中查到。随着使用者數量的增加，user表的資料量會越來越大，當資料量達到一定程度的時候對user表的查詢會漸漸的變慢，進而影響整個db的性能。可以通過某種方式将user進行水準的切分，産生表結構完全一樣的user_0000,user_0001等表。随着資料量增加也許單台db的存儲空間不夠，随着查詢量的增加單台資料庫伺服器已經沒辦法支撐。這個時候可以再對庫進行水準切分。

【分庫分表産生的問題及注意事項】

1.分庫分表次元的問題

       假如使用者購買了商品,需要将交易記錄儲存取來，如果按照使用者的緯度分表，則每個使用者的交易記錄都儲存在同一表中，是以很快很友善的查找到某使用者的購買情況，但是某商品被購買的情況則很有可能分布在多張表中，查找起來比較麻煩。反之，按照商品次元分表，可以很友善的查找到此商品的購買情況，但要查找到買人的交易記錄比較麻煩。

是以常見的解決方式有：

     a.通過掃表的方式解決，此方法基本不可能，效率太低了。

     b.記錄兩份資料，一份按照使用者緯度分表，一份按照商品次元分表。

     c.通過搜尋引擎解決，但如果實時性要求很高，又得關系到實時搜尋。

2.聯合查詢的問題

       聯合查詢基本不可能，因為關聯的表有可能不在同一資料庫中。

3.避免跨庫事務

       避免在一個事務中修改db0中的表的時候同時修改db1中的表，一個是操作起來更複雜，效率也會有一定影響。

4.盡量把同一組資料放到同一db伺服器上

       例如将賣家a的商品和交易資訊都放到db0中，當db1挂了的時候，賣家a相關的東西可以正常使用。也就是說避免資料庫中的資料依賴另一資料庫中的資料。

----------------------------------------------

下面這片短文中談到mysql的問題，貼出來看看。

【mysql使用為什麼要分庫分表】

http://www.thinksaas.cn/group/topic/26653/

可以用說用到mysql的地方，隻要資料量一大,，馬上就會遇到一個問題：要分庫分表。

這裡引出一個問題：為什麼要分庫分表呢？mysql處理不了大表嗎？

       其實是可以處理的大表的。在我所經曆的項目中，單表在實體上的檔案大小為80g左右，單表記錄數在5億以上，而且這個表屬于一個非常核心的表：朋友關系表。

       但這種方式可以說不是一個最佳方式。因為面臨某些檔案系統時 - 如ext3檔案系統 - 在對大檔案的處理上會有許多問題。

       這個層面可以用xfs檔案系統進行替換。但mysql單表太大後有一個問題是不好解決: 表結構調整相關的操作基本不在可能。是以大項目在實際使用中都會面臨着分庫分表的應用。

       從innodb本身來講資料檔案的btree上隻有兩個鎖，葉子節點鎖和子節點鎖。可想而知，當發生頁拆分或是添加新葉時都會造成表裡不能寫入資料。

是以分庫分表就是一個比較好的選擇了。 那麼分庫分表多少合适呢?

       經測試，在單表1000萬條記錄以下，寫入讀取性能是比較好的。如果再留點buffer，那麼單表全是資料字型資料的可以保持在800萬條記錄以下，有字元型的單表可以保持在500萬以下。

如果按100庫100表來規劃，如使用者業務:

500萬*100*100 = 50000000萬 = 5000億記錄

心裡有一個數了，按業務做規劃還是比較容易的。

----------------------------------------------------------------