數據庫的水平劃分和垂直劃分

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

垂直劃分 

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

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

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

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

 

水平劃分

 

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

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

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

 

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

 

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

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

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

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

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

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

 

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

 

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