隨著一個網站的業務不斷擴展，數據不斷增加，數據庫的壓力也會越來越大，對數據庫或者SQL的基本優化可能達不到最終的效果，我們可以采用讀寫分離的策略來改變現狀。讀寫分離現在被大量應用于很多大型網站，這個技術也不足為奇了。ebay就做得非常好。ebay用的是Oracle，聽說是用Quest Share Plex 來實現主從復制數據。

     讀寫分離簡單的說是把對數據庫讀和寫的操作分開對應不同的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕io壓力。主數據庫提供寫操作，從數據庫提供讀操作，其實在很多系統中，主要是讀的操作。當主數據庫進行寫操作時，數據要同步到從的數據庫，這樣才能有效保證數據庫完整性。Quest SharePlex就是比較牛的同步數據工具，聽說比oracle本身的流復制還好，MySQL也有自己的同步數據技術。mysql只要是通過二進制日志來復制數據。通過日志在從數據庫重復主數據庫的操作達到復制數據目的。這個復制比較好的就是通過異步方法，把數據同步到從數據庫。

      主數據庫同步到從數據庫后，從數據庫一般由多臺數據庫組成這樣才能達到減輕壓力的目的。讀的操作怎么樣分配到從數據庫上？應該根據服務器的壓力把讀的操作分配到服務器，而不是簡單的隨機分配。mysql提供了MySQL-PRoxy實現讀寫分離操作。不過MySQL-Proxy好像很久不更新了。oracle可以通過F5有效分配讀從數據庫的壓力。

ebay的讀寫分離（網上找到就拿來用了）

 mysql的讀寫分離       上面說的數據庫同步復制，都是在從同一種數據庫中，如果我要把oracle的數據同步到mysql中，其實要實現這種方案的理由很簡單，mysql免費，oracle太貴。好像Quest SharePlex也實現不了改功能吧。好像現在市面還沒有這個工具吧。那樣應該怎么實現數據同步？其實我們可以考慮自己開發一套同步數據組件，通過消息，實現異步復制數據。其實這個實現起來要考慮很多方面問題，高并發的問題，失敗記錄等。其實這種方法也可以同步數據到memcache中。聽說oracle的Stream也能實現，不過沒有試過。

———————華麗的分割線————————————————————–

           垂直分庫、水平分表

數據庫的水平劃分和垂直劃分很早以前就接觸了，只是沒有實踐，沒有什么體會，只有最近兩年才有接觸，今天也和大家聊聊。

垂直劃分 

按照功能劃分，把數據分別放到不同的數據庫和服務器。

當一個網站開始剛剛創建時，可能只是考慮一天只有幾十或者幾百個人訪問，數據庫可能就個db，所有表都放一起，一臺普通的服務器可能就夠了，而且開發人員也非常高興，而且信心十足，因為所有的表都在一個庫中，這樣查詢語句就可以隨便關聯了，多美的一件事情。但是隨著訪問壓力的增加，讀寫操作不斷增加，數據庫的壓力絕對越來越大，可能接近極限，這時可能人們想到增加從服務器，做什么集群之類的，可是問題又來了，數據量也快速增長。

這時可以考慮對讀寫操作進行分離，按照業務把不同的數據放到不同的庫中。其實在一個大型而且臃腫的數據庫中表和表之間的數據很多是沒有關系的，或者更加不需要（join）操作，理論上就應該把他們分別放到不同的服務器。例如用戶的收藏夾的數據和博客的數據庫就可以放到兩個獨立的服務器。這個就叫垂直劃分（其實叫什么不重要）。

當博客或者收藏夾的數據不斷增加后，應該怎么辦，這樣就引出了另外一個做法，叫水平劃分。

水平劃分

則把一個表的數據劃分到不同的數據庫，兩個數據庫的表結構一樣。怎么劃分，應該根據一定的規則，可以根據數據的產生者來做引導，上面的數據是由人產生的，可以根據人的id來劃分數據庫。然后再根據一定的規則，先獲知數據在哪個數據庫。

其實很多大型網站都經歷了數據庫垂直劃分和水平的劃分的階段。其實這個可以根據經驗來確定，不一定由某些硬性的規則。

以剛才的博客為例，數據可以根據userid的奇偶來確定數據的劃分。把id為基數的放到A庫，為偶數的放B庫。

這樣通過userId就可以知道用戶的博客的數據在哪個數據庫。其實可以根據userId%10來處理。還可以根據著名的HASH算法來處理。

當初看手機之家的架構是發現他們是：

水平切分：對數據進行水平分割。

a.最好分到同一個數據庫。

b.一種已經證明是切實可行的方案：主表＋輔表。

c.有3種類型：主表不打散、主表打散無輔表、主表打散有輔表。

d.但對程序員來說，TA看到的只是一張表，不妨稱之為虛表(邏輯表)? ，這張虛表實際上可能是由N張實表(物理表)組成的。

哈哈，我還是喜歡把數據分到不同的數據庫，這個可以按照業務來和環境來定吧。

在說句題外話，如果是大型數據庫，還可以做讀寫分離等。