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

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

    我當年負責一個項目（中國電信BDC項目），購買的資料庫硬體是P590小機組。通過壓力測試後系統上線後，業務迅猛發展。小機的記憶體、CPU長期在98%上下徘徊。硬體雖然好，但是也扛不住業務的狂飆，應用伺服器橫向擴充相對比較容易，而資料庫的升級相當的昂貴。

    怎麼辦？當然首先是一堆的參數的調優和系統的調優。但是指標下降的不是特別理想；

    怎麼辦？對系統進行合理拆分吧。

    資料庫拆分又分為垂直分割和水平分割，垂直分割相對動靜小一點。教育要從娃娃抓起，最佳化要從簡單的抓起。

    垂直切分，也可以稱為縱向切分。我個人對垂直切分的理解是分兩種，一種是把不同模組需要的表且分開，不同的模組放到不同的資料庫中；另外一種是把一些特別大的表，把實際常用的欄位，不常用的欄位切分成兩張表或者多張表。

 

也可以將資料庫想象成由很多個一大塊一大塊的"資料區塊"（表）組成，垂直地將這些"資料區塊"切開，然後把它們分散到多台資料庫主機上面。這樣的切分方法就是垂直資料切分。

 

切分資料庫模組

我們的應用系統，內部由很多個功能模組所組成的，而每一個功能模組所需要的資料對應到資料庫中就是一個或多個表。而各個功能模組相互之間的互動點越統一、越少，系統的耦合度就越低，系統各個模組的維護性及擴充性也就越好。這樣的系統，實現資料的垂直切分也就越容易。

 

在垂直切分之前，我們要把功能模組梳理清楚，耦合度越低，資料垂直切分的規則定義也就越容易。完全可以根據功能模組來進行資料的切分，不同功能模組的資料存放於不同的資料庫主機中，可以很容易就避免跨資料庫的事情存在，同時系統架構也非常清晰。

 

但是在實際中，如果這個系統當時是設計為一個系統，那麼這些資料之間就必定有一些關聯，否則怎麼形成一個系統。但是在電信中，資料庫之間的DBlink是不允許使用的，那麼在特定的情況下，使用專門的介面或者讓應用程式讀取多個資料庫然後處理資料，是一個必然的選擇。

   

    但是，資料本身規模的提升，比如主電話使用者數達到了1.2億，單張表的查詢所需要的資源開銷就已經非常大了，這個時候垂直切分起不了那麼多作用，但是飯要一口一口吃，還是先把垂直切分的問題解決吧。

 

我們先分析一下，然後設計一個切分規則，進行一次垂直分割。

 

初略一看，沒有哪個模組可以脫離其他模組獨立存在，模組與模組之間都存在著關係，莫非無法切分？

我們先把系統的主要功能模組進行分類，這樣問題就清楚多了。

 

系統功能基本可以分為4個功能模組：電話使用者表、地址庫、對外服務庫以及資料擷取加工庫（采編維），分別對應為如下這些表：

 

1.電話使用者表：area,user,tel,…

 

2.地址庫：address , …

 

3.對外服務庫：out_search,out_user,out_tel,…

 

4.資料擷取加工庫（采編維）:orders …

 

 

再稍微深入分析一下，可以發現，雖然各個模組所使用的表之間都有關聯，但是關聯關係還算清晰。

 

其中，資料擷取加工庫（采編維）和其他的模組沒有必然的直接關係，那麼可以考慮直接用一個新的資料庫承接這塊的服務。並且這一塊的使用者數相當大，和其他三個模組的使用方式比較接近，選定了一個目標，那就拆分吧。

 

我們的業務有一個特性，那就是和地區關係緊密，所有模組都需要使用area地區資訊。

要共用地區資訊有好幾種辦法：

DBLink最簡單，而且能夠共用一份資料，但是不符合公司的管理要求；

統一做介面，介面開發容易，調用也不難，但是對改造的系統，都有一定的改動，而且這個介面的效能要求不低，不是一個最優的選擇；

最終選定的方法，就是在各個拆分的庫之間，都放一張area表，因為中國的行政區劃變化不頻繁。與此同時，在這些area表之間做介面，如果資料有變動，會同步更新資料。

 

拆分之後，P590小機組是：電話使用者表、地址庫、對外服務庫三大組；

有購買了P570小機部署：資料擷取加工庫（采編維）

切出來之後，資料擷取加工庫（采編維） 就成為了一個單獨的項目，在以後的時間裡，它發展壯大，成為一個大的平台，並且有了一個響亮的名字：統一采編維。

 

而我們，在垂直切分的路上，邁出了第一步。

 

垂直切分的優點：

資料庫的拆分簡單明了，拆分規則明確；

應用程式模組清晰明確，整合容易；

 

垂直切分的缺點：

配套的實際投入（軟硬體）會增加；

部分表關聯無法在資料庫層級完成，要在程式中完成；

無法處理訪問大且資料量超大的表的效能瓶頸；

交易處理相對複雜；

切分達到一定程度之後，擴充性會受到限制；

過度切分可能會帶來系統過於複雜而難以維護。

 

切分資料庫特大表

在早期的資料庫設計中，因為各種各樣的原因，會讓系統中存在一些特大表。這些表，不僅資料的行數特別多；而且欄位還特別多。

比如我們的老GPS資料加工表，這張表有220多個欄位。資料量有6000多萬。這種表，如果一不小心有人寫的SQL是全表掃描，那麼整個資料庫執行個體都要被拖累。

就是一個普通的資料寫入，建立索引也是一個很大的開銷。

怎麼辦，其實垂直切分不是解決問題的根本途徑，但是這個總歸比較簡單，在做一個重大的決定前，總要從簡單的部分做起；就和跑步一樣先做做熱身活動，然後才能開始跑起來，這樣才能跑的更好，更遠。

    這張表非常古老，一直忽視了他的存在，一直到有一天，有一位同事對這張表做了點操作，小機組差點掛掉。這個問題，必須要解決。

    一步一步來，首先對這張表的220個欄位進行分析，從屬性上說，主要是使用者資訊，地址資訊，GPS資訊，輔助擴充資訊（QQ號碼、MSN號碼等），動作記錄等。

    簡單切分下，使用者資訊放使用者表，用使用者ID關聯；地址資訊和GPS保留，輔助擴充屬性基本是空的，放到一對一的擴充表中，動作記錄放日誌表。

    這樣下來，GPS資料加工表的主表就只有30個欄位，雖然有點多，但是比以前好太多了，剩下的問題，就是6000多萬的資料了，那需要其他的處理方式。