傳統的關係型數據庫很難擴展，通常是縱向擴展，但到達一定程度時只能橫向擴展。
數據庫的橫向擴展支持三種方法，即主從複製，集羣和分片(sharding)。
圖是偷的，內容是整理過的 ~ T.T
主從複製：
主從複製——最易配置，對應用改動最小，並可以減輕主庫的負擔。 主數據庫可以讀寫，從數據庫只讀。
應用場景場景——實現讀寫分離，或業務分離，即運行報表，備份，數據倉庫等應用
存在問題——
1，主與從之間數據非完全同步，可能會讀到兩個不同的版本
2，如果只有主庫接受讀寫，那麼主庫遲早會過載，因此不算是真正的scale out
不過主從庫數據的延遲，有的業務是可以接受的。另外，利用一些實時複製的工具如GoldenGate，從庫也是可以寫的，這時可以利用從庫做其它的業務，從而達到橫向擴展的目的。這也算是主從複製的一個新趨勢。
集羣Clustering：
集羣——也稱爲shared everything或shared disk架構。最知名的就是Oracle RAC，1個數據庫可以有多個實例，來訪問共享存儲上的數據庫。 每一個節點都可以讀寫，從應用角度來看，代碼無需改變。負載均衡也是自動的。
存在問題——
1，寫數據時需要內存中數據的同步，數據加速帶來競爭，影響擴展性
2，難以設置和管理
3，由於存儲是共享的，讀操作也不能無限擴展
集羣適合於——讀密集的應用，如數據倉庫和BI
分片(Sharding)
分區——是庫內的
分片——是庫外的，也叫分表分庫, 是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.
這句話有點意思。