關系型資料庫橫向擴充的三種方法

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

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

主從複制

主從複制(Master-slave replication)，最易配置，對應用改動最小，并可以減輕主庫的負擔。

主資料庫可以讀寫，從資料庫隻讀。最常用的場景就是實作讀寫分離，或業務分離，即運作報表，備份，資料倉庫等應用。

這種方法的問題是主與從之間資料非完全同步，可能會讀到兩個不同的版本。另一個問題是，如果隻有主庫接受讀寫，那麼主庫遲早會過載，是以不算是真正的scale out。

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

叢集(Clustering)

叢集也稱為shared everything或shared disk架構。最知名的就是Oracle RAC。

1個資料庫可以有多個執行個體，來通路共享存儲上的資料庫。

每一個節點都可以讀寫，從應用角度來看，代碼無需改變。負載均衡也是自動的。

叢集存在的問題包括：

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

* 難以設定和管理

* 由于存儲是共享的，讀操作也不能無限擴充

叢集适合于讀密集的應用，如資料倉庫和BI。

分片(Sharding)

分區(Partition)是庫内的，分片(Sharding)是庫外的，也叫分表分庫, 是shared nothing的架構。

Sharding即将一個大的庫拆分成很多小庫。如何拆和業務規則有關，可以按使用者ID拆，按業務拆。如果需要Join，相關的表需要放到一個庫裡，避免資料庫間的通訊。

Sharding也可以有兩種方法，即垂直分區和水準分區。

垂直分區是按業務分，簡稱為分庫，即不同的業務使用不同的庫，互不相幹。垂直分區到一定程度，也無法擴充，這時需要水準分區。

水準分區則是将一個大表拆分為小表，每個小表位于不同的庫。每一個建立相同的schema。如根據主鍵的hash值來分區。

sharding的不足在于：

* 加大了應用代碼的複雜性，需要路由到正确的shard。

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

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

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

* 跨庫修改需要分布式交易處理，會限制可擴充性。是以應盡量避免。

* 單個shard的失效可能會使整個系統不可用(其實也不一定)。是以通常需要為每個shard再配置HA方案，如主從複制。

盡管有以上不足，分片對于一些大型網站還是廣泛使用，如Google, eBay, Facebook, Flickr。

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

這句話有點意思。

當然，還有一些其它一些新的資料庫架構可以實作橫向擴充，如NoSQL對于OLTP的擴充，Hadoop對于OLAP的擴充。不過已超出本文的讨論範圍了。