資料庫最佳化-水平切分-以及在實際項目中的應用，切分項目

資料庫最佳化-水平切分-以及在實際項目中的應用，切分項目

    資料庫水平資料分割，相對垂直資料分割，需要做的工作和事情要多一些，但是對一些行資料特別多的表，非常有必要。

    在我在BDC項目中的不斷最佳化中，總結了下面幾種常用的資料庫水平切分方法：

1.  表分區；

2.  表拆分；

3.  表分庫；

 

表分區

表分區是ORACLE和新版本的MYSQL資料庫中，一個非常強大的功能。非常值得學習。

但是表分區如果用不好，效能反倒會下降。我記得我們的另外一個項目組，他們就嘗試使用表分區，於是安排了一個沒有相關經驗的開發人員去研究，研究了幾天，然後發現速度更加慢了，於是，表分區的計劃就此終止。這是題外話。

    在選定表分區這個方案之後，首先要做的第一件事情，那就是要樹立信心，表分區在處理大表資料的情況下，是一定有效果的，如果效果不明顯或者沒效果甚至效果變差了，那麼首先要考慮是不是用的地方不太對。

    先說我們項目的實際情況，核心電話表當初的大小是1.2億，我們選擇的方案是表分區，那麼接下來就是要根據資料情況，對這些資料進行不同維度區分，讓它更好的為商務服務。

我們的表中有一個很關鍵的內容，那就是地區；每一個電話資訊，對應一個地區，這個是我們全國性電信資料的一個基本特徵。

    那麼是區分到省一級呢，還是到地市一級呢？我們有資料的省級行政區是32個，地市是300多個。分區不能太零碎，除非有確切的需要，否則以後營運是一個非常頭疼的事情。那麼我們在省一級區划上作為分區的條件。

    分區設計了，如果在SQL中就要體現出來，如果不體現分區，有可能會讓效率降低。

    使用分區比較簡單，一種是直接明確分區，比如

select * from tel PARTITION (310000) ；其中PARTITION (310000)是指上海的資料分區，其中310000是上海市對應的國家標準編碼；

這是一種寫法，我個人更加傾向於另外一種寫法：

Select* from tel t where t.prov_code = 310000

其中，分區的標註就是建立在prov_code 這個欄位上，ORACLE會自動調用分區的特性。

 

    就結果而言，通過類似的分區改造之後，峰值輸送量從以前一天400萬資料，資料庫就要掛掉，最高達到了一天處理1200萬資料，資料庫貌似還有餘力，效果還是不錯的。

   

    表分區涉及的概念和功能蠻多的，有空整理下這方面的內容。

 

表拆分

    表拆分是一門古老的技術，也很實用。我們很久以前做電信黃頁，那個時候表分區還沒有成熟，我們處理大表最常用的技術就是表拆分了。

    表拆分從邏輯上非常簡單，我們有一張9000萬資料的號簿表，包含了31個省公司的號簿資料，這些資料同時由31個省公司進行維護。

    9000萬的資料，無論是檢索，修改，刪除，對效能的影響都是很高。那就按照省份直接進行拆分吧。建立出31張表替代這一張，然後建立一個全國性視圖，供集團使用。

 

表分庫

    我們在表分區裡提到了隔壁一個項目組，嘗試使用表分區沒有成功，但是活人不能被尿憋死，他們也找到了他們適合的方法，這個辦法就是表分庫。

    表分庫是什麼呢？其實我們的資料庫主備機制，就是一個表分庫的雛形。他們是怎麼做的呢，首先準備硬體，購買了一組資料庫硬體；然後把現有的資料庫複寫一份到新硬體上去，把業務資料清理乾淨，把常量資料保留；然後對系統做簡單的調整，長江南邊的進入老系統，訪問老資料庫；長江北面的進入新系統，訪問新資料庫。

    除了花錢有一點之外，改造風險確實蠻小的。當然，不是所有的系統都能這樣分庫。

 

    綜上所述，當資料庫到達一定規模，垂直切分和水平切分都是項目負責人必須要考慮的問題，無論使用哪種方式，都需要在瞭解業務的基礎上，根據本系統的實際情況，選擇一個最合適的方法。