在WEB網站的規模從小到大不斷擴充套件的過程中，資料庫的訪問壓力也不斷的增加，資料庫的架構也需要動態擴充套件，在資料庫的擴充套件過程基本上包含如下幾步，每一個擴充套件都可以比上一步驟的部署方式的效能得到數量級的提升。 

1、WEB應用和資料庫部署在同一臺伺服器上

一般的小規模的網站採用這種方式，使用者量、資料量、併發訪問量都比較小，否則單臺伺服器無法承受，並且在遇到效能瓶頸的時候升級硬體所需要的費用非常高昂，在訪問量增加的時候，應用程式和資料庫都來搶佔有限的系統資源，很快就又會遇到效能問題。

2、WEB應用和資料庫部署在各自獨立的伺服器上

web應用和資料庫分開部署，WEB應用伺服器和資料庫伺服器各司其職，在系統訪問量增加的時候可以分別升級應用伺服器和資料庫伺服器，這種部署方式是一般小規模網站的典型部署方式。在將應用程式進行效能優化並且使用資料庫物件快取策略的情況下，可以承載較大的訪問量，比如2000使用者，200個併發，百萬級別的資料量。

3、資料庫伺服器採用叢集方式部署（比如Oracle的一個數據庫多個例項的情況）

資料庫叢集方式能承擔的負載是比較大的，資料庫物理介質為一個磁碟陣列，多個數據庫例項以虛擬IP方式向外部應用伺服器提供資料庫連線服務。這種部署方式基本上可以滿足絕大多數的常見WEB應用，但是還是不能滿足大使用者量、高負載、資料庫讀寫訪問非常頻繁的應用。

4、資料庫採用主從部署方式

在面向大眾使用者的部落格、論談、交友、CMS等系統中，有上百萬的使用者，有上千萬的資料量，存在眾多的資料庫查詢操作，也有較多的資料庫寫操作，並且在多數情況下都是讀操作遠大於寫操作的。在這個時候，假如能將資料庫的讀寫操作分離的話，對於系統來講是一個很大的提高啦。資料庫的主從部署方式就走到我們面前啦。

 主從複製： 

 幾乎所有的主流資料庫都支援複製，這是進行資料庫簡單擴充套件的基本手段。下面以Mysql為例來說明，它支援主從複製，配置也並不複雜，只需要開啟主伺服器上的二進位制日誌以及在主伺服器和從伺服器上分別進行簡單的配置和授權。Mysql的主從複製是一句主伺服器的二進位制日誌檔案進行的，主伺服器日誌中記錄的操作會在從伺服器上重放，從而實現複製，所以主伺服器必須開啟二進位制日誌，自動記錄所有對於主資料庫的更新操作，從伺服器再定時到主伺服器取得二進位制日誌檔案進行重放則完成了資料的複製。主從複製也用於自動備份。 

  讀寫分離： 

  為保證資料庫資料的一致性，我們要求所有對於資料庫的更新操作都是針對主資料庫的，但是讀操作是可以針對從資料庫來進行。大多數站點的資料庫讀操作比寫操作更加密集，而且查詢條件相對複雜，資料庫的大部分效能消耗在查詢操作上了。 
  主從複製資料是非同步完成的，這就導致主從資料庫中的資料有一定的延遲，在讀寫分離的設計中必須要考慮這一點。以部落格為例，使用者登入後發表了一篇文章，他需要馬上看到自己的文章，但是對於其它使用者來講可以允許延遲一段時間（1分鐘/5分鐘/30分鐘），不會造成什麼問題。這時對於當前使用者就需要讀主資料庫，對於其他訪問量更大的外部使用者就可以讀從資料庫。 

  資料庫反向代理： 

  在讀寫分離的方式使用主從部署方式的資料庫的時候，會遇到一個問題，一個主資料庫對應多臺從伺服器，對於寫操作是針對主資料庫的，資料庫個數是唯一的，但是對於從伺服器的讀操作就需要使用適當的演算法來分配請求啦，尤其對於多個從伺服器的配置不一樣的時候甚至需要讀操作按照權重來分配。 
  對於上述問題可以使用資料庫方向代理來實現。就像WEB方向代理伺服器一樣，MYsql Proxy同樣可以在SQL語句轉發到後端的Mysql伺服器之前對它進行修改。 
 

5、資料庫垂直分割

主從部署資料庫中，當寫操作佔了主資料庫的CPU消耗的50%以上的時候，我們再增加從伺服器的意義就不是很大了，因為所有的從伺服器的寫操作也將佔到CPU消耗的50%以上，一臺從伺服器提供出來查詢的資源非常有限。資料庫就需要重新架構了，我們需要採用資料庫垂直分割槽技術啦。
最簡單的垂直分割槽方式是將原來的資料庫中獨立的業務進行分拆（被分拆出來的部分與其它部分不需要進行Join連線查詢操作），比如WEB站點的BLOG和論壇，是相對獨立的，與其它的資料的關聯性不是很強，這時可以將原來的的資料庫拆分為一個BLog庫，一個論壇庫，以及剩餘的表所組成的庫。這三個庫再各自進行主從資料庫方式部署，這樣整個資料庫的壓力就分擔啦。
另外查詢擴充套件性也是採用資料庫分割槽最主要的原因之一。將一個大的資料庫分成多個小的資料庫可以提高查詢的效能，因為每個資料庫分割槽擁有自己的一小部分資料。假設您想掃描1億條記錄，對一個單一分割槽的資料庫來講，該掃描操作需要資料庫管理器獨立掃描一億條記錄，如果您將資料庫系統做成50個分割槽，並將這1億條記錄平均分配到這50個分割槽上，那麼每個資料庫分割槽的資料庫管理器將只掃描200萬記錄。

6、資料庫水平分割

在資料庫的垂直分割槽之後，假如我們的BLOG庫又再次無法承擔寫操作的時候，我們又該怎麼辦呢？資料庫垂直分割槽這種擴充套件方式又無能為力了，我們需要的是水平分割槽。
水平分割槽意味著我們可以將同一個資料庫表中的記錄通過特定的演算法進行分離，分別儲存在不同的資料庫表中，從而可以部署在不同的資料庫伺服器上。很多的大規模的站點基本上都是主從複製+垂直分割槽+水平分割槽這樣的架構。水平分割槽並不依賴什麼特定的技術，完全是邏輯村面的規劃，需要的是經驗和業務的細分。
如何分割槽呢？對於大型的WEB站點來說，必須分割槽，並且對於分割槽我們沒有選擇的餘地，對於那些頻繁訪問導致站點接近崩潰的熱點資料，我們必須分割槽。
在對資料分割槽的時候，我們必須要存在一個分割槽索引欄位，比如USER_ID，它必須和所有的記錄都存在關係，是分割槽資料庫中的核心表的主鍵，在其它表中作為外來鍵，並且在使用主鍵的時候，該主鍵不能是自增長的，必須是業務主鍵才可以。

 餘數分割槽： 

 我們可以將User_ID%10後的值為依據存入到不同的分割槽資料庫中，該演算法簡單高效，但是在分割槽資料庫個數有變動的時候，整個系統的資料需要重新分佈。 

 範圍分割槽： 

 我們可以將User_ID的範圍進行分割槽，比如1-100000範圍為一個分割槽資料庫，100001-200000範圍為一個分割槽資料庫，該演算法在分割槽資料庫個數有變動的時候，系統非常有利於擴充套件，但是容易導致不同分割槽之間的壓力不同，比如老使用者所在的分割槽資料庫的壓力很大，但是新使用者的分割槽資料庫的壓力偏小。    

  對映關係分割槽：  

  將對分割槽索引欄位的每個可能的結果建立一個分割槽對映關係，這個對映關係非常龐大，需要將它們寫入資料庫中。比如當應用程式需要知道User_id為10的使用者的BLOG內容在那個分割槽時，它必須查詢資料庫獲取答案，當然，我們可以使用快取來提高效能。 
  這種方式詳細儲存了每一個記錄的分割槽對應關係，所以各個分割槽有非常強的可伸縮性，可以靈活的控制，並且將資料庫從一個分割槽遷移到另一個分割槽也很簡單，也可以使各個分割槽通過靈活的動態調節來保持壓力的分佈平衡。