MySQL分库分表

垂直切分

将不同业务模块所使用的表切分到不同的数据库(主机)之上,这样的切能够称之为数据的垂直(纵向)切分

在架构设计中,各个功能模块相互之间的交互点越统一越少,系统的耦合度就越低,系统各个模块的维护性以及扩展性也就越好,实现数据的垂直切分也就越简单

垂直切分的长处

◆ 数据库的拆分简单明了,拆分规则明白;

◆ 应用程序模块清晰明白,整合easy;

◆ 数据维护方便易行,easy定位;

垂直切分的缺点

◆ 部分表的关联无法在数据库级别完毕,须要在程序中完毕;

◆ 对于訪问极其频繁且数据量超大的表仍然存在性能平静,不一定能满足要求;

◆ 事务处理相对更为复杂;

◆ 切分达到一定程度之后,扩展性会遇到限制;

◆ 过读切分可能会带来系统过渡复杂而难以维护;

水平切分

依据表中的数据的逻辑关系,将同一个表中的数据依照某种条件拆分到多台数据库(主机)上面

就是将表中的某些行切分到一个数据库,而另外的某些行又切分到其它的数据库中。为了能够判定各行数据被切分到哪个数据库中了,切分总是要依照某种特定的规则来进行的,如依据某个数字类型字段基于特定数目取模、某个时间类型字段的范围、或者是某个字符类型字段的hash值

水平切分的长处

◆ 表的关联基本能够在数据库端全部完毕;

◆ 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题;

◆ 应用程序端总体架构修改相对较少;

◆ 事务处理相对简单;

◆ 仅仅要切分规则能够定义好,基本上较难遇到扩展性限制;

水平切分的缺点

◆ 切分规则相对更为复杂,非常难抽象出一个能够满足整个数据库的切分规则;

◆ 后期数据的维护难度有所添加,人为手工定位数据更困难;

◆ 应用系统各模块耦合度较高,可能会对后面数据的迁移拆分造成一定的困难;

联合使用

在非常多大型的应用系统中,垂直切分和水平切这两种数据的切分方法基本上都是并存的。并且经常在不断的交替进行,以不断的添加系统的扩展能力。我们在应对不同的应用场景的时候,也须要充分考虑到这两种切分方法各自的局限,以及各自的优势。在不同的时期(负载压力)使用不同的结合方式。

联合切分的长处

◆ 能够充分利用垂直切分和水平切分各自的优势而避免各自的缺陷;

◆ 让系统扩展性得到最大化提升。

联合切分的缺点

◆ 数据库系统架构比較复杂,维护难度更大。

◆ 应用程序架构也相对更复杂;

数据切分及整合方案

数据库中的数据在经过垂直和(或)水平切分被存放在不同的数据库主机之后,应用系统面临的最大问题就是怎样来让这些数据源得到较好的整合

方案

总的来说,存在两种解决思路:

1、在每一个应用程序模块中配置管理自己须要的一个(或者多个)数据源,直接訪问各个数据库,在模块内完毕数据的整合;

2、通过中间代理层来统一管理全部的数据源,后端数据库集群对前端应用程序透明;

数据切分与整合可能存在的问题

引入分布式事务的问题

数据切分之后,可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer中了

MySQL5.0之后Innodb提供分布式事务支持,不过对于系统资源的消耗是非常大的

最好能够结合数据库以及应用程序两者来共同解决。各个数据库解决自己身上的事务。然后通过应用程序来控制多个数据库上面的事务

跨节点Join的问题

数据切分之后,可能会造成有些老的Join语句无法继续使用。由于Join使用的数据源可能被切分到多个MySQLServer中了

非得在数据库端来直接解决的话,恐怕仅仅能通过MySQL一种特殊的存储引擎Federated来解决

Federated会保存一份远端表结构的定义信息在本地,不过本地的表定义信息是不会跟着远端的表结构发生对应变化的,所以如果在更新远端表结构的时候并没有更新本地的表定义信息,就可能造成Query执行出错

推荐通过应用程序来进行处理,先在驱动表所在的MySQLServer中取出对应的驱动结果集。然后依据驱动结果集再到被驱动表所在的MySQLServer中取出对应的数据

跨节点合并排序分页问题
posted @   上好佳28  阅读(9)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
点击右上角即可分享
微信分享提示