传统的关系型数据库很难扩展，通常是纵向扩展，但到达一定程度时只能横向扩展。
数据库的横向扩展支持三种方法，即主从复制，集群和分片(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.
这句话有点意思。