【數據庫】——分庫分表

一、前言

Sharding的基本思想就要把一個數據庫切分成多個部分放到不同的數據庫(server)上，從而緩解單一數據庫的性能問題。不太嚴格的講，對於海量數據的數據庫，如果是因爲表多而數據多，這時候適合使用垂直切分，即把關係緊密（比如同一模塊）的表切分出來放在一個server上。如果表並不多，但每張表的數據非常多，這時候適合水平切分，即把表的數據按某種規則（比如按ID散列）切分到多個數據庫(server)上。當然，現實中更多是這兩種情況混雜在一起，這時候需要根據實際情況做出選擇，也可能會綜合使用垂直與水平切分，從而將原有數據庫切分成類似矩陣一樣可以無限擴充的數據庫(server)陣列。需要特別說明的是：當同時進行垂直和水平切分時，切分策略會發生一些微妙的變化。比如：在只考慮垂直切分的時候，被劃分到一起的表之間可以保持任意的關聯關係，因此你可以按“功能模塊”劃分表格，但是一旦引入水平切分之後，表間關聯關係就會受到很大的制約，通常只能允許一個主表（以該表ID進行散列的表）和其多個次表之間保留關聯關係，也就是說：當同時進行垂直和水平切分時，在垂直方向上的切分將不再以“功能模塊”進行劃分，而是需要更加細粒度的垂直切分，而這個粒度與領域驅動設計中的“聚合”概念不謀而合，甚至可以說是完全一致，每個shard的主表正是一個聚合中的聚合根！這樣切分下來你會發現數據庫分被切分地過於分散了（shard的數量會比較多，但是shard裏的表卻不多），爲了避免管理過多的數據源，充分利用每一個數據庫服務器的資源，可以考慮將業務上相近，並且具有相近數據增長速率（主表數據量在同一數量級上）的兩個或多個shard放到同一個數據源裏，每個shard依然是獨立的，它們有各自的主表，並使用各自主表ID進行散列，不同的只是它們的散列取模（即節點數量）必需是一致的.

二、常用的分庫分表中間件

1、簡單易用的組件：

2、強悍重量級的中間件：

三、數據庫架構

1、簡單的MySQL主從複製:

MySQL的主從複製解決了數據庫的讀寫分離，並很好的提升了讀的性能，其圖如下：

其主從複製的過程如下圖所示：

但是，主從複製也帶來其他一系列性能瓶頸問題：

1）寫入無法擴展

2）寫入無法緩存

3）複製延時

4）鎖表率上升

5）表變大，緩存率下降

2、MySQL垂直分區

如果把業務切割得足夠獨立，那把不同業務的數據放到不同的數據庫服務器將是一個不錯的方案，而且萬一其中一個業務崩潰了也不會影響其他業務的正常進行，並且也起到了負載分流的作用，大大提升了數據庫的吞吐能力。經過垂直分區後的數據庫架構圖如下：

然而，儘管業務之間已經足夠獨立了，但是有些業務之間或多或少總會有點聯繫，如用戶，基本上都會和每個業務相關聯，況且這種分區方式，也不能解決單張表數據量暴漲的問題，因此爲何不試試水平分割呢？

3、MySQL水平分片（Sharding）

這是一個非常好的思路，將用戶按一定規則（按id哈希）分組，並把該組用戶的數據存儲到一個數據庫分片中，即一個sharding，這樣隨着用戶數量的增加，只要簡單地配置一臺服務器即可，原理圖如下：

如何來確定某個用戶所在的shard呢，可以建一張用戶和shard對應的數據表，每次請求先從這張表找用戶的shard id，再從對應shard中查詢相關數據，如下圖所示：

①單庫單表

單庫單表是最常見的數據庫設計，例如，有一張用戶(user)表放在數據庫db中，所有的用戶都可以在db庫中的user表中查到。
②單庫多表

隨着用戶數量的增加，user表的數據量會越來越大，當數據量達到一定程度的時候對user表的查詢會漸漸的變慢，從而影響整個DB的性能。如果使用mysql, 還有一個更嚴重的問題是，當需要添加一列的時候，mysql會鎖表，期間所有的讀寫操作只能等待。
可以通過某種方式將user進行水平的切分，產生兩個表結構完全一樣的user_0000,user_0001等表，user_0000 + user_0001 + …的數據剛好是一份完整的數據。

③多庫多表

隨着數據量增加也許單臺DB的存儲空間不夠，隨着查詢量的增加單臺數據庫服務器已經沒辦法支撐。這個時候可以再對數據庫進行水平區分。