mysql 数据库切分_mysql数据库切分
一、数据的垂直切分
概念:数据的垂直切分,也可以称之为纵向切分。将不同的表分散到不同的数据库主机中。
一个应用系统,总体功能肯定是由很多个功能模块所组成的,而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。
在架构设计中,各个功能模块相互之间的交互点越统一越少,系统的耦合度就越低,系统各个模块的维护性以及扩展性也就越好。
这样的系统,实现数据的垂直切分也就越容易。
1)可以根据功能模块来进行数据的切分,不同功能模块的数据存放于不同的数据库主机中,可以很容易就避免掉跨数据库的Join存在,同时系统架构也非常的清晰。
2)很难有系统能够做到所有功能模块所使用的表完全独立,完全不需要访问对方的表或者需要两个模块的表进行Join操作。根据实际的应用场景进行评估权衡。
1.迁就应用程序,将需要Join的表的相关某快都存放在同一个数据库中。
2.让应用程序做更多的事情,程序完全通过模块接口取得不同数据库中的数据,然后在程序中完成Join操作。
通过这样的垂直切分之后,之前只能通过一个数据库来提供的服务,就被分拆成四个数据库来提供服务,服务能力自然是增加几倍了。
垂直切分的优点
◆ 数据库的拆分简单明了,拆分规则明确;
◆ 应用程序模块清晰明确,整合容易;
◆ 数据维护方便易行,容易定位;
垂直切分的缺点
◆ 部分表关联无法在数据库级别完成,需要在程序中完成;
◆ 对于访问极其频繁且数据量超大的表仍然存在性能平静,不一定能满足要求;
◆ 事务处理相对更为复杂;
◆ 切分达到一定程度之后,扩展性会遇到限制;
◆ 过读切分可能会带来系统过渡复杂而难以维护。
Notice:在数据库进行垂直切分的时候,如何切分,切分到什么样的程度,是一个比较考验人的难题。只能在实际的应用场景中通过平衡各方面的成本和收益,才能分析出一个真正适合自己的拆分方案。
可能在某些操作的单次响应时间会稍有增加,但是系统的整体性能很可能反而会有一定的提升。
二、数据的水平切分
概念:水平切分主要是将某个访问极其平凡的表再按照某个字段的某种规则来分散到多个表之中,每个表中包含一部分数据。
就是按照数据行的切分,就是将表中的某些行切分到一个数据库,而另外的某些行又切分到其他的数据库中。
1)按照某种特定的规则来进行切分。
1.某个数字类型字段基于特定数目取模
2.某个时间类型字段的范围
3.某个字符类型字段的hash值。
2)使相关的数据进行切分之后尽量存放在相同的数据库中,即使是需要join查询,也可以非常简单的关联上,在数据库层面上就可以进行关联查询。
水平切分的优点
◆ 表关联基本能够在数据库端全部完成;
◆ 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题;
◆ 应用程序端整体架构改动相对较少;
◆ 事务处理相对简单;
◆ 只要切分规则能够定义好,基本上较难遇到扩展性限制;
水平切分的缺点
◆ 切分规则相对更为复杂,很难抽象出一个能够满足整个数据库的切分规则;
◆ 后期数据的维护难度有所增加,人为手工定位数据更困难;
◆ 应用系统各模块耦合度较高,可能会对后面数据的迁移拆分造成一定的困难。
三、垂直与水平切分的联合使用
每一个应用系统的负载都是一步一步增长上来的,在开始遇到性能瓶颈的时候,大多数架构师和DBA都会选择先进行数据的垂直拆分,因为这样的成本最先,最符合这个时期所追求的最大投入产出比。然而,随着业务的不断扩张,系统负载的持续增长,在系统稳定一段时期之后,经过了垂直拆分之后的数据库集群可能又再一次不堪重负,遇到了性能瓶颈。这时就需要进行水平切分。
实际上,在很多大型的应用系统中,垂直切分和水平切这两种数据的切分方法基本上都是并存的,而且经常在不断的交替进行,以不断的增加系统的扩展能力。我们在应对不同的应用场景的时候,也需要充分考虑到这两种切分方法各自的局限,以及各自的优势,在不同的时期(负载压力)使用不同的结合方式。
联合切分的优点
◆ 可以充分利用垂直切分和水平切分各自的优势而避免各自的缺陷;
◆ 让系统扩展性得到最大化提升;
联合切分的缺点
◆ 数据库系统架构比较复杂,维护难度更大;
◆ 应用程序架构也相对更复杂;
四、数据切分及整合方案
数据库中的数据在经过垂直和(或)水平切分被存放在不同的数据库主机之后,应用系统面临的最大问题就是如何来让这些数据源得到较好的整合
总的来说,存在两种解决思路:
1. 在每个应用程序模块中配置管理自己需要的一个(或者多个)数据源,直接访问各个数据库,在模块内完成数据的整合;
2. 通过中间代理层来统一管理所有的数据源,后端数据库集群对前端应用程序透明;
可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种,尤其是系统不断变得庞大复杂的时候。确实,这是一个非常正确的选择,虽然短期内需要付出的成本可能会相对更大一些,但是对整个系统的扩展性来说,是非常有帮助的。
五、数据切分与整合可能存在的问题
在实施数据切分方案之前,有些可能存在的问题我们还是需要做一些分析的。一般来说,我们可能遇到的问题主要会有以下几点:
◆ 引入分布式事务的问题;
◆ 跨节点Join的问题;
◆ 跨节点合并排序分页问题;
1. 引入分布式事务的问题
一旦数据进行切分被分别存放在多个MySQLServer中之后,不管我们的切分规则设计的多么的完美(实际上并不存在完美的切分规则),都可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer中了。
在这样的场景下,如果我们的应用程序仍然按照老的解决方案,那么势必需要引入分布式事务来解决。而在MySQL各个版本中,只有从MySQL5.0开始以后的各个版本才开始对分布式事务提供支持,而且目前仅有Innodb提供分布式事务支持。不仅如此,即使我们刚好使用了支持分布式事务的MySQL版本,同时也是使用的Innodb存储引擎,分布式事务本身对于系统资源的消耗就是很大的,性能本身也并不是太高。而且引入分布式事务本身在异常处理方面就会带来较多比较难控制的因素。
怎么办?其实我们可以可以通过一个变通的方法来解决这种问题,首先需要考虑的一件事情就是:是否数据库是唯一一个能够解决事务的地方呢?其实并不是这样的,我们完全可以结合数据库以及应用程序两者来共同解决。各个数据库解决自己身上的事务,然后通过应用程序来控制多个数据库上面的事务。
也就是说,只要我们愿意,完全可以将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务,并通过应用程序来总控各个小事务。当然,这样作的要求就是我们的应用程序必须要有足够的健壮性,当然也会给应用程序带来一些技术难度。
2.跨节点Join的问题
上面介绍了可能引入分布式事务的问题,现在我们再看看需要跨节点Join的问题。数据切分之后,可能会造成有些老的Join语句无法继续使用,因为Join使用的数据源可能被切分到多个MySQLServer中了。
怎么办?这个问题从MySQL数据库角度来看,如果非得在数据库端来直接解决的话,恐怕只能通过MySQL一种特殊的存储引擎Federated来解决了。Federated存储引擎是MySQL解决类似于Oracle的DBLink之类问题的解决方案。和OracleDBLink的主要区别在于Federated会保存一份远端表结构的定义信息在本地。咋一看,Federated确实是解决跨节点Join非常好的解决方案。但是我们还应该清楚一点,那就似乎如果远端的表结构发生了变更,本地的表定义信息是不会跟着发生相应变化的。如果在更新远端表结构的时候并没有更新本地的Federated表定义信息,就很可能造成Query运行出错,无法得到正确的结果。
对待这类问题,我还是推荐通过应用程序来进行处理,先在驱动表所在的MySQLServer中取出相应的驱动结果集,然后根据驱动结果集再到被驱动表所在的MySQLServer中取出相应的数据。可能很多读者朋友会认为这样做对性能会产生一定的影响,是的,确实是会对性能有一定的负面影响,但是除了此法,基本上没有太多其他更好的解决办法了。而且,由于数据库通过较好的扩展之后,每台MySQLServer的负载就可以得到较好的控制,单纯针对单条Query来说,其响应时间可能比不切分之前要提高一些,所以性能方面所带来的负面影响也并不是太大。更何况,类似于这种需要跨节点Join的需求也并不是太多,相对于总体性能而言,可能也只是很小一部分而已。所以为了整体性能的考虑,偶尔牺牲那么一点点,其实是值得的,毕竟系统优化本身就是存在很多取舍和平衡的过程。
3. 跨节点合并排序分页问题
一旦进行了数据的水平切分之后,可能就并不仅仅只有跨节点Join无法正常运行,有些排序分页的Query语句的数据源可能也会被切分到多个节点,这样造成的直接后果就是这些排序分页Query无法继续正常运行。其实这和跨节点Join是一个道理,数据源存在于多个节点上,要通过一个Query来解决,就和跨节点Join是一样的操作。同样Federated也可以部分解决,当然存在的风险也一样。
还是同样的问题,怎么办?我同样仍然继续建议通过应用程序来解决。
如何解决?解决的思路大体上和跨节点Join的解决类似,但是有一点和跨节点Join不太一样,Join很多时候都有一个驱动与被驱动的关系,所以Join本身涉及到的多个表之间的数据读取一般都会存在一个顺序关系。但是排序分页就不太一样了,排序分页的数据源基本上可以说是一个表(或者一个结果集),本身并不存在一个顺序关系,所以在从多个数据源取数据的过程是完全可以并行的。这样,排序分页数据的取数效率我们可以做的比跨库Join更高,所以带来的性能损失相对的要更小,在有些情况下可能比在原来未进行数据切分的数据库中效率更高了。当然,不论是跨节点Join还是跨节点排序分页,都会使我们的应用服务器消耗更多的资源,尤其是内存资源,因为我们在读取访问以及合并结果集的这个过程需要比原来处理更多的数据。
mysql 数据库切分_mysql数据库切分相关推荐
- mysql 数据表格切分_MySQL数据库垂直和水平切分
replication的限制:一旦数据库过于庞大,尤其是当写入过于频繁,很难由一台主机支撑的时候,我们还是会面临到扩展瓶颈.数据切分(sharding):通过某种特定的条件,将我们存放在同一个数据库中 ...
- mysql case默认_MySQL数据库架构和同步复制流程
在分布式系统里面,往往制约整个系统发展的瓶颈点就是数据库,所以数据库的架构和高可用以及数据库的切分都是我们值得花大力气去学习的. 首先我们来说说数据库的架构. 1.mysql主从架构,如图: 这种架构 ...
- mysql数据库监控程序_mysql数据库监控利器lepus天兔工具安装和部署
需要的核心包如下: 以下软件包只需要部署在监控机即可.被监控机无需部署. 1.MySQL 5.0及以上(必须,用来存储监控系统采集的数据) 2.Apache 2.2及以上 (必须,WEB服务器运行服务 ...
- mysql数据库语法_MySQL数据库基本语法
SQL WHAT(SQL是什么?) Structured Query Language:结构化查询语⾔ WHY(为何要使用SQL?) 难道仅仅使用SQL Server Management Studi ...
- Mysql常用词汇_mysql 数据库常用单词
说明:以下单词可能有多种含义,此文档只针对编程做解释.单词不多,熟能生巧,每日认真读读写写,效果不错.如有错误,请谅解并指出,谢谢大家! 黄金超 2017-4-7 连接MySQL数据库: mysql ...
- mysql删除原则_MySQL数据库的增删选查
数据库是专门存储数据对象的容器,这里的数据对象包括表.视图.触发器.存储过程等,其中表是最基本的数据对象. 创建数据库 在 MySQL 数据库中存储数据对象之前,先要创建好数据库. 语法: creat ...
- mysql select表达式_MySQL数据库SELECT查询表达式解析
数据的管理在很大一部分是在进行查找工作,而SELECT占据了很大的一部分 SELECT select_expr [,select_expr...] [ FROM table_reference WHE ...
- mysql数据库导出_MySQL数据库导入导出详解[转发]
1. 概述 MySQL数据库的导入,有两种方法: 1) 先导出数据库SQL脚本,再导入: 2) 直接拷贝数据库目录和文件. 在不同操作系统或MySQL版本情况下,直接拷贝文件的方法可能会有不兼容的情况 ...
- mysql断网_mysql数据库断网链接
{"moduleinfo":{"card_count":[{"count_phone":1,"count":1}],&q ...
最新文章
- SQL2K数据库开发二之查看和修改Sample数据库
- 如何保持在QA这条路上, 而不会想转换到RD去呢?
- vim括号操作(转)
- SAP UI5 应用开发教程之四十二 - SAP UI5 自带的 Diagnostics 诊断工具使用方法介绍
- windows下载、安装运行redis
- ida 字符串查找_IDA 搜索中文字符串
- oracle绑定值的结尾,Oracle Sql字符串多余空格处理方法小记
- octotree插件 --- 将 Github 项目代码以树形格式展示
- vue php tree,Vue 实现树形视图数据功能
- java抽奖_Java实现抽奖功能
- Go调用zlib实现压缩与解压缩
- 【王道操作系统笔记】操作系统的发展和分类
- 数据结构笔记(十七)--矩阵的压缩存储
- 计算机启动过程过程图,计算机启动过程图文详解(一)----计算机初始化启动过程...
- io vivado 怎么查看ps_一次诡异的磁盘IO使用率高排查
- 109-gamp与rtklib精度对比
- mysql注入转义绕过_SQL注入防御绕过
- STM32学习记录——MD300二维码扫描模块
- 《大护法》—— 花生镇里的成人童话
- 汽车营销如何破局?看懂车帝全域营销助品牌“破浪”