資料庫橫向擴充套件主從複製集群和分片

傳統的關係型資料庫很難擴充套件，通常是縱向擴充套件，但到達一定程度時只能橫向擴充套件。

資料庫的橫向擴充套件支援三種方法，即主從複製，集群和分片(sharding)。

圖是偷的，內容是整理過的 ~ t.t

主從複製——最易配置，對應用改動最小，並可以減輕主庫的負擔。主資料庫可以讀寫，從資料庫唯讀。

應用場景場景——實現讀寫分離，或業務分離，即執行報表，備份，資料倉儲等應用

存在問題——

1，主與從之間資料非完全同步，可能會讀到兩個不同的版本

2，如果只有主庫接受讀寫，那麼主庫遲早會過載，因此不算是真正的scale out

不過主從庫資料的延遲，有的業務是可以接受的。另外，利用一些實時複製的工具如goldengate，從庫也是可以寫的，這時可以利用從庫做其它的業務，從而達到橫向擴充套件的目的。這也算是主從複製的乙個新趨勢。

集群——也稱為shared everything或shared disk架構。最知名的就是oracle rac，1個資料庫可以有多個例項，來訪問共享儲存上的資料庫。每乙個節點都可以讀寫，從應用角度來看，**無需改變。負載均衡也是自動的。

存在問題——

1，寫資料時需要記憶體中資料的同步，資料加速帶來競爭，影響擴充套件性

2，難以設定和管理

3，由於儲存是共享的，讀操作也不能無限擴充套件

集群適合於——讀密集的應用，如資料倉儲和bi

分割槽——是庫內的

分片——是庫外的，也叫分表分庫, 是shared nothing的架構。

sharding——將乙個大的庫拆分成很多小庫。

如何拆和業務規則有關，可以按使用者id拆，按業務拆。

如果需要join，相關的表需要放到乙個庫里，避免資料庫間的通訊。

sharding也可以有兩種方法，

1，垂直分割槽——按業務分，簡稱為分庫，即不同的業務使用不同的庫，互不相干。垂直分割槽到一定程度，也無法擴充套件，這時需要水平分割槽。

2，水平分割槽——將乙個大表拆分為小表，每個小表位於不同的庫。每乙個建立相同的schema。如根據主鍵的hash值來分割槽。

存在問題——

1，加大了應用**的複雜性，需要路由到正確的shard。

2，後期增加shard需要修改應用邏輯，並需要遷移資料

3，查詢和聚集(aggregation)不再簡單，需要跨庫聯合操作

4，主資料和參照資料需要複製到所有shard，以避免跨庫操作。主資料和參照資料雖然偏靜態，但一旦修改，可能會有資料一致性問題。

5，跨庫修改需要分布式交易處理，會限制可擴充套件性。因此應盡量避免。

6，單個shard的失效可能會使整個系統不可用（其實也不一定）。因此通常需要為每個shard再配置ha方案，如主從複製。

儘管有以上不足，分片對於一些大型**還是廣泛使用，如google, ebay, facebook, flickr。

when the pain is great, any medicine that reduces it is good, regardless of the side effects.

這句話有點意思。

資料庫橫向擴充套件 主從複製 集群和分片