关系型数据库横向扩展的三种方法

本文是 Oracle Coherence 3.5一书，第一章: Achieving Performance, Scalability, and Availability Objectives，第二节：Achieving scalability中，数据库横向扩展部分的读书笔记。

传统的关系型数据库很难扩展，通常是纵向扩展，但到达一定程度时只能横向扩展。

数据库的横向扩展支持三种方法，即主从复制，集群和分片(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的扩展。不过已超出本文的讨论范围了。

扩展阅读

• Scaling Out SQL Server
• Relational Databases Are Not Designed For Scale | MarkLogic
• Scaling Up And Out | Dr Dobb’s