傳統的關係型數據庫很難擴展，通常是縱向擴展，但到達一定程度時只能橫向擴展。
數據庫的橫向擴展支持三種方法，即主從複製，集羣和分片(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的擴展。不過已超出本文的討論範圍了。