垂直切分
将不同业务模块所使用的表切分到不同的数据库(主机)之上,这样的切能够称之为数据的垂直(纵向)切分
在架构设计中,各个功能模块相互之间的交互点越统一越少,系统的耦合度就越低,系统各个模块的维护性以及扩展性也就越好,实现数据的垂直切分也就越简单
垂直切分的长处
◆ 数据库的拆分简单明了,拆分规则明白;
◆ 应用程序模块清晰明白,整合easy;
◆ 数据维护方便易行,easy定位;
垂直切分的缺点
◆ 部分表的关联无法在数据库级别完毕,须要在程序中完毕;
◆ 对于訪问极其频繁且数据量超大的表仍然存在性能平静,不一定能满足要求;
◆ 事务处理相对更为复杂;
◆ 切分达到一定程度之后,扩展性会遇到限制;
◆ 过读切分可能会带来系统过渡复杂而难以维护;
水平切分
依据表中的数据的逻辑关系,将同一个表中的数据依照某种条件拆分到多台数据库(主机)上面
就是将表中的某些行切分到一个数据库,而另外的某些行又切分到其它的数据库中。为了能够判定各行数据被切分到哪个数据库中了,切分总是要依照某种特定的规则来进行的,如依据某个数字类型字段基于特定数目取模、某个时间类型字段的范围、或者是某个字符类型字段的hash值
水平切分的长处
◆ 表的关联基本能够在数据库端全部完毕;
◆ 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题;
◆ 应用程序端总体架构修改相对较少;
◆ 事务处理相对简单;
◆ 仅仅要切分规则能够定义好,基本上较难遇到扩展性限制;
水平切分的缺点
◆ 切分规则相对更为复杂,非常难抽象出一个能够满足整个数据库的切分规则;
◆ 后期数据的维护难度有所添加,人为手工定位数据更困难;
◆ 应用系统各模块耦合度较高,可能会对后面数据的迁移拆分造成一定的困难;
联合使用
在非常多大型的应用系统中,垂直切分和水平切这两种数据的切分方法基本上都是并存的。并且经常在不断的交替进行,以不断的添加系统的扩展能力。我们在应对不同的应用场景的时候,也须要充分考虑到这两种切分方法各自的局限,以及各自的优势。在不同的时期(负载压力)使用不同的结合方式。
联合切分的长处
◆ 能够充分利用垂直切分和水平切分各自的优势而避免各自的缺陷;
◆ 让系统扩展性得到最大化提升。
联合切分的缺点
◆ 数据库系统架构比較复杂,维护难度更大。
◆ 应用程序架构也相对更复杂;
数据切分及整合方案
数据库中的数据在经过垂直和(或)水平切分被存放在不同的数据库主机之后,应用系统面临的最大问题就是怎样来让这些数据源得到较好的整合
方案
总的来说,存在两种解决思路:
1、在每一个应用程序模块中配置管理自己须要的一个(或者多个)数据源,直接訪问各个数据库,在模块内完毕数据的整合;
2、通过中间代理层来统一管理全部的数据源,后端数据库集群对前端应用程序透明;
数据切分与整合可能存在的问题
引入分布式事务的问题
数据切分之后,可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer中了
MySQL5.0之后Innodb提供分布式事务支持,不过对于系统资源的消耗是非常大的
最好能够结合数据库以及应用程序两者来共同解决。各个数据库解决自己身上的事务。然后通过应用程序来控制多个数据库上面的事务
跨节点Join的问题
数据切分之后,可能会造成有些老的Join语句无法继续使用。由于Join使用的数据源可能被切分到多个MySQLServer中了
非得在数据库端来直接解决的话,恐怕仅仅能通过MySQL一种特殊的存储引擎Federated来解决
Federated会保存一份远端表结构的定义信息在本地,不过本地的表定义信息是不会跟着远端的表结构发生对应变化的,所以如果在更新远端表结构的时候并没有更新本地的表定义信息,就可能造成Query执行出错
推荐通过应用程序来进行处理,先在驱动表所在的MySQLServer中取出对应的驱动结果集。然后依据驱动结果集再到被驱动表所在的MySQLServer中取出对应的数据