关系型数据库横向扩展的三种方法
2016-07-10 19:03
288 查看
本文是 Oracle Coherence 3.5一书,第一章: Achieving Performance, Scalability, and Availability Objectives,第二节:Achieving scalability中,数据库横向扩展部分的读书笔记。
![](http://i.imgur.com/BIMUDLB.jpg)
传统的关系型数据库很难扩展,通常是纵向扩展,但到达一定程度时只能横向扩展。
数据库的横向扩展支持三种方法,即主从复制,集群和分片(sharding)。
![](http://i.imgur.com/6wW1gTz.png)
主数据库可以读写,从数据库只读。最常用的场景就是实现读写分离,或业务分离,即运行报表,备份,数据仓库等应用。
这种方法的问题是主与从之间数据非完全同步,可能会读到两个不同的版本。另一个问题是,如果只有主库接受读写,那么主库迟早会过载,因此不算是真正的scale out。
不过主从库数据的延迟,有的业务是可以接受的。另外,利用一些实时复制的工具如GoldenGate,从库也是可以写的,这时可以利用从库做其它的业务,从而达到横向扩展的目的。这也算是主从复制的一个新趋势。
1个数据库可以有多个实例,来访问共享存储上的数据库。
每一个节点都可以读写,从应用角度来看,代码无需改变。负载均衡也是自动的。
集群存在的问题包括:
* 写数据时需要内存中数据的同步,数据加速带来竞争,影响扩展性
* 难以设置和管理
* 由于存储是共享的,读操作也不能无限扩展
集群适合于读密集的应用,如数据仓库和BI。
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的扩展。不过已超出本文的讨论范围了。
Relational Databases Are Not Designed For Scale | MarkLogic
Scaling Up And Out | Dr Dobb’s
![](http://i.imgur.com/BIMUDLB.jpg)
传统的关系型数据库很难扩展,通常是纵向扩展,但到达一定程度时只能横向扩展。
数据库的横向扩展支持三种方法,即主从复制,集群和分片(sharding)。
![](http://i.imgur.com/6wW1gTz.png)
主从复制
主从复制(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 ServerRelational Databases Are Not Designed For Scale | MarkLogic
Scaling Up And Out | Dr Dobb’s
相关文章推荐
- SQL---Chapter01 数据库和SQL
- SAE MySQL使用例1
- Centos6.5安装mysql不能启动,应该安装mysql-server
- mysql用户名和密码忘记了怎么办?
- navicat for Mysql:2003 can't connect to mysql server on 'localhost'(10038)问题的解决方法
- 数据库设计的三大范式、BCNF、4NF
- PostgreSQL 输出 JSON 结果
- centos下nginx+postgresql+php+memcached+apc
- C++ Redis服务端搭建与客户端开发
- Mac 重新设置MySQL的root密码
- MySQL 性能监控 4 大指标
- MySql-半同步复制
- redis.conf配置详解
- MySql-Undo及Redo详解
- 优化MySQL数据库性能的八大方法
- MYSQL添加新用户 MYSQL为用户创建数据库 MYSQL为新用户分配权限
- MongoDB分片
- redis源码分析-adlist(链表)
- MySQL性能优化的最佳20+条经验
- 最新 DEDECMS SQL 注入 0day