码迷,mamicode.com
首页 > 数据库 > 详细

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

时间:2016-07-13 17:54:04      阅读:248      评论:0      收藏:0      [点我收藏+]

标签:

本文是 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的扩展。不过已超出本文的讨论范围了。

扩展阅读

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

标签:

原文地址:http://blog.csdn.net/stevensxiao/article/details/51872795

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!