ps平面设计主要做什么,应用宝aso优化,免费正版高清素材库,图书网站开发介绍分布式数据库已经进入了全面快速发展阶段。这种发展是与时俱进的#xff0c;与人的需求分不开#xff0c;因为现在信息时代的高速发展#xff0c;导致数据量和交易量越来越大。这种现象首先导致的就是存储瓶颈#xff0c;因为MySQL数据库实质上还是一个单机版本的数据库与人的需求分不开因为现在信息时代的高速发展导致数据量和交易量越来越大。这种现象首先导致的就是存储瓶颈因为MySQL数据库实质上还是一个单机版本的数据库而只要是单机就必然会遇到的一个问题就是存储问题因为存储是硬需求而CPU和内存如果不够的话只是性能不好并不会直接否定方案或者架构。 存储问题的解决其实我们每一家公司或者个人都一直在努力着。解决方案大概有三个方面 1、增大磁盘 这种方式应该是最直接、最简单的方案了因为磁盘空间不足了当然加磁盘是手到病除比如现在是800G可以增加到2T这是没问题的如果现在已经达到了2T当然还是可以增加到5T的盘。但实际上这个时候可能DBA就要捏把汗了这么大数据量的MySQL实例如何运维如果数据坏了如何恢复呢时间成本呢 5T的数据量已经非常吓人了估计在业内各大公司没有DBA会希望自己运维的MySQL实例达到这个量级吧 其实我个人认为这个已经是不能接受的量了最合适的是保持在1T以下超过就要想办法了。 当然数据量不宜达到这个大小的原因可能会有人考虑到这是性能的问题其实不然或者性能问题很小。因为InnoDB采用的是B树的存储方案小表最坏情况下没有查到数据是要找3层也就是3个页面的IO而大表需要的是4个页面的IO影响不大。 2、数据压缩 为了减少数据对磁盘空间的占用我们通常也会将数据做压缩处理通过一个语句即可搞定是InnoDB原生支持的一种方式。一般情况下会将数据占用减少到原来的三分之一到一半不等效果还是足够明显的不过这样处理之后的数据在性能上会有所下降对于响应要求比较高的业务可能需要谨慎考虑一下。 但这种方式还是治标不治本在数据量继续增长的情况下过段时间之后依然会面临相同的问题这种情况下就不能继续使用这种方式来实现了。 3、数据分片 数据分片的解决方案现在业内用得也很多这种方案已经超出了MySQL本身包括HBase、Redis等也都在使用这种方案应该说这种方案是最具扩展性的并且可以称得上是无限扩展。而上面两种方案根本谈不上扩展性。所以这种方案在业内成为主流并且这种方案才能称得上是分布式存储具体的实现也层出不穷。当然存在优秀的分布式解决方案也存在一些“伪”分布式方案了。 一、分布式解决方案需求 1、扩展性 使用分布式其实最主要的就是扩展性如果空间不足了可以很方便容易的扩展节点个数并且将数据做新的平衡处理。这个过程要不影响业务使用对业务透明。 2、支持事务 分布式数据库对于业务本身使用方面与单机区别不大也就是对业务透明因为使用MySQL是支持事务的那么MySQL变身为分布式之后事务特性还是不能少的所以整体上看来还是要支持分布式事务。 3、SQL语句无限制 业务需求的多样性导致在SQL需求上面都是比较广泛的针对业务的透明性如果某些SQL语句不支持那这样导致的问题是一方面限制了业务程序的功能和性能另一方面导致业务程序与“分布式数据库”的捆绑问题。 4、性能足够好 使用分布式数据库其实基本上是对性能的要求比较低的业务才会这样选择即使是这样还是性能越高越多人才会选择这样的分布式数据库。 5、元数据变更透明性 元数据变更在任何数据库中都是存在的。在单点情况下改表操作我们有多种友好的方法来实现。但到了分布式环境下可能这种操作就成为了问题因为数据的分片导致了元数据的变更需要多点修改进而很多问题就来了比如原子性、数据可见性、正确性等等所以这是最基本的问题。 6、底层数据库的高可用性 话说经济基础决定上层建筑在分布式数据库中也是一样的如果底层数据库的不稳定或者数据复制延迟亦或出现数据不一致的问题则上层应用的访问正确性就没法保证所以底层数据库最基本的就是保证数据一致性高可用。 二、流行分布式数据库解决方案 1、中间件分库分表伪分布式 在MySQL界一个存在很久的话题就是“哪个中间件实现的分库分表方案比较好” 当然对于同一个问题不同人有不同的理解也都具有两面性的特征有人说好也有人说不好我们首先看一下这种方案是如何实现的。 MyCat的实现架构大概如上图所示其实如果只看图的话这样的架构真是完美无缺自动分片、自动聚合、分布均衡都实现的非常好。 但事实并非如此。 我们可以通过问答的方式一步步认清楚这种方式的核心问题 问题1MyCat如何知道数据分片原理或者说是如何决定路由路径的 这个问题在图上面是看不出来的。 MyCat是如何定义或者决定一条SQL语句的执行方式或者如何决定去哪里取数据及写入到哪里的解决这样的问题是需要某一个地方来存储的它的做法是——schema.xml配置文件竟然用配置文件来搞定。 那这样问题就多了修改分库分表规则之后如何保证配置与数据同步更新即使不使用schema.xml配置文件而是用数据库存储那配置规则的变更与数据节节点中数据的迁移也是没办法保证统一的势必会对业务造成影响。 问题2如果需要扩展节点了并且需要做rebalance如何来做 很多用户基本都是重新准备一套集群或者先把数据一点点手动导出导入导到目标节点之后然后去手动修改schema.xml配置文件然后做一次reload操作这样就实现了重新路由但这样同样会导致上面的结果。 并且这个过程需要处理好多数据处理完成之后各种检查并且占用空间需要两倍这样折腾一个DBA只要干一次可能就有辞职的冲动。 问题3全局表是什么东西 MyCat支持一个所谓的全局表用来解决跨节点数据聚合的问题。实现方法是在每一个分片上面都创建这样的全局表它的定义是不怎么修改查询比较频繁表可以定义为全局表这样的话在每一个分片节点上只要用到这个表就可以实现本地查询连接等操作。 这样的确是可以解决部分问题但问题是如果分片多的话假如分片100个如何保证数据一致性这么多节点的XA事务影响是什么如果出现不一致或者访问错误引起的问题就是数据结果错误这样的结果肯定不是业务想要看到的吧这还不是最关键的一个数据库集群搞这么一个特殊处理的东西是何道理 问题4MyCat究竟做了什么事情 作为一个中间层本职工作应该是接收客户端的SQL请求通过语法分析根据读写原则确定一个集群中一个读写节点即可然后就等着结果集的返回。对于结果集本身中间层并不需要去关心只需要将结果集或者异常原原本本发回给客户端即可。 而MyCat做的事情远比这个多在语法分析之后再做语义分析拿到对应数据库表结构同时判断这个表的分发路由规则再找到语句中的数据及涉及到的列再决定路由到哪个分片中。如果在分发时路由规则配置错误或者程序计算错误会导致整个语句的结果出现不可预知的问题。 请问这前半部分是一个中间层应该做的事情么竟然还要关心语句中涉及到的表结构、主键、数据等信息这其实都是数据库要做的事情啊实则是越俎代庖。 再请问所做的这些事情能比一个专业数据库做得更好么 咱再看后半部分等收到结果集之后MyCat为了处理一些结果集的聚合计算需要把各个节点本来已经封装好的结果集二进制MySQL协议流数据解析出来然后通过需要计算出来这个计算有可能非常慢并且不是所有的都可以搞定计算完成之后再打包成MySQL协议流数据传给客户端。 请问这样的中间层做了这么多事情性能如何保证而本身这些聚合计算Order By、Group By的处理本身是数据库的事情实则还是越俎代庖。 问题5通过SQL语句的变换实现分布式是不是有点困难 MyCat这种中间层代表了宣称分布式数据库的一类使用方式但这种实现方法实际上都是通过在SQL语句上做文章从客户端拿到的是SQL语句给后端数据库的也是SQL语句但这两个SQL语句是经过变换的。 当然这种方法也只能这样因为后端数据库只接收SQL语句。试问一个复杂的SQL语句查询操作通过SQL变换或重写就能实现对不同分片数据库的分布式查询 想想就清楚了虽然SQL语句通用灵活但可扩展性或者重写的逻辑还是有点复杂的吧当然了有人可能会说我们有兜底的啊大不了把这个语句就改一下库名表名然后其它保持不变分给每一个节点去执行这样总没问题吧是的你说的没错。 问题6在同一个事务中要修改不同节点的数据是如何处理的 这个问题就是我们通常所说的分布式事务了。究竟是怎么回事呢MyCat下面对的是MySQL Server也就是说MyCat只能用SQL语句与MySQL Server交流这样就是局限于MySQL的SQL语句的功能了。 那在分布式实现上面MySQL XA本身有多少人用MyCat如果实现一个跨节点的数据更新不用MySQL XA还能用其它什么 别无他选。本身依赖一个没有太多人用、并且可能存在很多问题包括性能、Bug的功能这样上层MyCat乃至应用程序的可靠性如何保证 当然基于这些问题有些方案选择不用XA如果某些节点失败了选择忽略不解决这当然也可以妥协嘛——不需要底线的。 问题7MyCat后端数据库的架构是什么如何保证稳定可靠高可用 这个据某些文章宣传说之前可以选择主从复制现在可以选择Galera Cluster或者也可以选择更新的MGR。 当然不得不说从前到后可能确实保证了更好的可靠性但有一个很大的问题是Galera的门槛比较高遇到问题的话很少人能解决掉。再到MGR本身还得等能用还要比较长的时间这问题还是要回到主从复制这是老问题了主从复制的一致性很难保证MyCat如果通过读写分离策略将读打到从上面而这个正好有延迟这样产生的后果可能是整个应用程序的计算结果是错误的。 当然可以说有延迟检查那问题是延迟检查的话是不是还有一个参数可以配置呢如果延迟超过100秒的话就去查主库 没错不过100秒难道就不是延迟了那可以设置为0看到的0你以为真的是0其实还是主从复制的劣根性。所以问题还是回到了起点经济基础决定上层建筑基础不好上层如何是好 问题8分片多了的情况下性能是如何保证损失最小的 这个问题我并不知道MyCat有没有做过优化比如10个分片如果一个语句的执行会涉及到这十个分片那在每个分片上重写语句之后就要分别在这十个分片上执行对应的语句了。 执行时是串行还是并行串行的话性能必然会下降10倍以上所以做得好点的话就是并行了但并行的实现方法是在MyCat这个连接上面创建10个线程去处理这十个节点的执行情况。那这样的连接多了MyCat产生的对系统的冲击就非常大了性能还是不行。 当然也可以说这里做了连接池没错是可以的但MyCat是这样做的么这样做了性能又如何呢如果有一个超时整个访问就失败了。 问题9配置文件或者配置库出问题整个集群会出现什么情况 前面已经说了MyCat用的是schema.xml来配置的分库分表策略这是一个配置文件MyCat本身的高可用如果配置多套的话他们的同步问题是如何解决的如果没有同步或者同步出问题或者延迟等某一个MyCat挂了业务切换到其它的MyCat时此时的情况就是故障……故障…… 因为数据都乱了。 有可能造成的问题是写入了错误的位置进而导致整个集群的数据被写坏。感觉比直接被删了还严重。 同样的问题感觉MyCat可能会优化这点也许会改为将其集中存储在某一个数据库中这样集中管理的话就不需要同步了想法是好的但这相当于是把鸡蛋放在一个篮子里面了如果这个配置库出问题了业务何去何从 问题10DDL如何进行 这个问题也许是每个人都关心的事情了MyCat把数据都分而不相关的分片MySQL节点了这样很多在单点上的改表策略都不能用了而DDL又是一个必须要保证每个节点同时完成的事情那在分布式上面是如何保证的呢 根据我的调研好像现在使用MyCat的人都是通过“同一时刻启动在每一个节点上更新表结构”这样的方法来做的当然还得选择是半夜当然我个人觉得也是可行的因为毕竟已经使用了它而没有更好的办法来解决这个问题。 当然咱再说后果如果做不到无缝原子修改那对业务的影响不是一星半点可能会有很多SQL会报表不存在的问题。如果一个语句和另一个语句修改完成时间相差比较多的话两个相减的时间就是故障时间了。 问题11据我调研MyCat还实现了自动故障切换的功能请问这个靠谱么 我们现在讨论的是分布式架构方案而这个问题讲的情况是某一个MyCat发现了后端数据库连不上了会自动切换的功能。这就非常明显了我们要的是分布式某“一个”MyCat节点认为的问题就真的是它所认为的吗 也就是说一个节点并不能保证判断的或者看到的现象是真实的那这种情况下就存在误切换的情况而如果其它中间层节点还不知道这个情况或者未及时收到切换的消息就出现了多点写入的问题挺可怕的。 这不是自相矛盾吗 我们要的是分布式结果又存在“独断”的环节可靠性又下降了不少。关于分布式监控切换的问题因为在去哪儿用的mysql-sentinel对Galera Cluster做的监控我对这点深有感触所以不得不在这里讲一下。 问题12在MyCat上面备份是如何做的能做到恢复一个快照吗 说起备份做为数据库使用者应该没有一个不清楚没有一个人会觉得不重要吧当然重要是重要但这种事情属于重要不紧急的工作但没有是不行的这个连公司内审这一关都过不了也许我们每一个人都不会希望能用到它。 言归正传这么重要的备份工作在MyCat上又是什么情况呢 可能了解一些基本原理的人都比较清楚Xtrabackup、mysqldump等也都是可以用的但备份完了之后可能心里还是感觉没底因为这样的工具只能对一个MySQL节点做备份。如果分10个分片10个MySQL节点的话可以通过备份十次即可完成但需要注意的是备份了十次产生了十个备份集而并不是一个备份集这十个备份集之间是完完全全没有关系的此时我可能就提出一个比较极端的问题来 如果哪天当然我们都不希望有这样的一天整个机房挂了当然假如“幸运”的是有备份那在这种情况下如何恢复一个可用的数据一致及完整的集群快照呢 这个时候可能会有人很快地说将十个备份集都恢复了启动了即可。 但问题是这十个没有关系备份时间又不是同一时刻完成的同一个表的十个分片最新数据有的是8点的有的是9点的或者有的甚至是昨天的。这样恢复出来的表能用么基于这样的表产生的查询结果靠谱么可想而知。 当然可能也有人会说我们的数据不需要一致快照或者更有甚者只需要备份元数据路由表或者配置文件即可那这样就没问题了如果MyCat只是定位于用来存储Zabbix监控数据或者日志数据可以丢失不要的数据、一文不值的数据那我觉得没毛病。 或许有人还会说我们的机房不会挂或者我们的存储本来就是跨机房的挂了的话直接切到另外的机房就行了。那此时又有问题了如果切换的时候有复制延迟丢失了部分数据那整个集群又会出问题。因为只要有一个分片的数据出问题整个集群就有问题了。 或者另一个问题就是假设你的机房真的不会挂但我们经常会遇到的需求是我要取前几天某时刻的数据那此时还是需要通过备份然后恢复一个快照这个时候还有何话可说你告诉我究竟如何做到 可能还会有人有疑问他会说我们是逻辑备份啊这样备份出来的是整个库或者表的一致性快照这不就解决问题了么 我很同意这位同学的看法说得对极了是可以很完美地解决一致性问题但只要熟悉一点点MySQL的人都知道类似mysqldump这样的逻辑备份工具是何其慢现在都用分布式存储了那肯定是数据量非常大这个时候还在使用这样的逻辑备份你是想干哈即使备份完成了那有没有试过逻辑数据的恢复几个G的数据要恢复多久你算过没有想想都头疼一条不归路…… 问题13如果已经在使用MyCat了发现它的风险确实太大了我如何能下掉呢 这个问题非常好说明你已经在思考做为一个数据负责人如何保证数据的可靠性和避免风险的问题了。MyCat风险确实高但如果已经上了“贼船”并且想下掉的话此时我可能想问一下做一回事后诸葛亮上这个架构的时候为什么不多考虑一下呢公司的数据就是金钱你这样想上就上想下就下来回折腾能升值么万一数据写乱了这个时候可没有人赔你钱还不如上云呢。 不过既然上了那咱就聊聊如何下掉的问题我目前感觉最靠谱最稳妥的办法貌似只有一个步骤如下 第1步先停业务将所有的写业务都停止也不用找深夜时间了因为12小时根本搞不完。 第2步通过上面所讲的mysqldump做逻辑备份将所有的库导出来生成.sql文件。 第3步然后找一个靠谱的MySQL架构真正的分布式数据库或者磁盘足够大的话可以不采用分布式采用Share Nothing的方案即可也许你需要的并不是分布式只是被忽悠了将.sql文件导入进去。 第4步再后就将读业务迁移到新的数据库架构上面去。 第5步将写业务也迁移到新的数据库架构上面去然后启动他们这个时候应该是可以提供正常的数据库服务了。 我们可以注意一下这个过程从第1步到第5步需要多少时间这个当然是硬时间是要移动数据的逻辑备份和恢复都那么慢我觉得时间的单位可以用天来统计了。 这个时候负责人就可以想想我用MyCat是图什么啊业务的免战牌挂了好几天只是为了弥补当年的一个错误决定追悔莫及。 当然也许有些人也会有其它办法但因为各个分片都是相互独立的还是存在上面的所说的在不停止业务的情况下的“一致性快照”的问题。 最后我想说的是对公司的数据一定要慎之又慎要时刻保持负责的态度折腾数据真的不能升值啊。 问题14MyCat的配置复杂吗上手容易么 我们只需要看一个图片就行了。你能想象这是它的配置文件么看了之后我估计你也没有任何使用它的欲望了很多人在使用之后是这样评价的 “MyCat这类碰都不想碰” 配置文件如下 竟然是一个XML文件这个产品经理当时是如何想的后面也没有想着做个优化 问题15最后一个问题现在做分库分表做得好的有哪些 有哪些一个都没有这是一条不归路啊。 因为说白了它是一种伪分布式方案基础是不好的上层就做不好所以永远是在补各种坑走得很累累人累己。 现在可以回过头来想一想为什么一些很强大知名的公司做的中间件产品并没有做这些事情比如ProxySQL、Maxscale、MySQL Router等为什么呢难道他们的技术不好或者是没有这样的需求 我还是觉得需求是有的人与人、业务与业务的需求是一样的但解决方法可能就不一样了他们可能早就认为这是一条错误的道路所以就不会去选择走而MyCat这种方案可能就要回过头来想想未来的路了。 2、互联网处理大规模在线访问数据的做法 解耦思想充斥着互联网技术栈的方方面面为什么这样做我想应该是大家都不想拖泥带水也不想牵一发而动全身罢了。而在MySQL数据库层面使用了重量级的中间层之后你会发现大一统看起来是很不错但这样牵一发很可能动全身这其实并不是好事情。 MySQL这种数据库是在互联网领域兴起并被大规模使用的在比如账务、订单、计费等关键业务上使用的也不在少数。 在大型互联网公司MySQL的使用一定是分库分表的通过各种垂直切分和水平切分把一个数据库变成一堆数据库也就是所说的数据库集群。但是很少看到在使用的MySQL的时候会在上面架设一层重量级的所谓分布式的中间层这样导致的就是紧耦合了与互联网的高效联运相违背互联网的数据库集群都应该是物理上离散的每一个实例可以自由的控制和迁移也就是所谓的解耦。 解耦的好处可以让你自由处理每一个独立的实例或者集群方便根据实际情况应对业务带来的变数该升级的升级该缩容的缩容为每一个业务或者每一个业务的数据库定义不同的维护等级灵活掌握随机而变。 解耦的好处可以提升数据库的绝对性能数据从业务到磁盘或者从磁盘到业务经历的路径越短其效率也就越高。很多使用MySQL的做法就是用一个简单的中间层分发SQL这样的中间层功能清晰、结构简单、灵活高效一般不会损失太多性能这就像MySQL出品的MySQL Router、MariaDB出品的Maxscale、Percona的ProxySQL还有国内极数云舟的Arkproxy他们的行为都为选择使用中间层去实现数据架构指明了一个方向。 解耦的好处可以让你的数据库只干数据库最擅长的事情它能保证你的数据安全存储它能保证你的数据高效存取它能保证你数据并发处理它能保证你的数据灵活接入这还不够吗 综上所述我们再次确信一个真理MySQL因简单而高效因高效而流行不要舍本逐末听信忽悠误入歧途。 当然如果不想在业务层做分库分表来适配MySQL数据库的架构而想通过对业务透明的分布式数据库来提供业务服务的话我推荐真正意义的分布式数据库解决方案它能解决的是强大的存储扩展能力、分布式运算、对业务读写透明以及友好的故障转移等问题这是它们的优势也是它们的初衷。 3、真正意义的分布式解决方案 真分布式方案其实已经不用太多说了达到上面所述的需求即可。并且目前也有比较成熟的方案比较有代表性的产品有Google的SpannerF1、以及国产数据库SequoiaDB、TiDB等等。 对比之下这种分布式数据库对业务无侵入MySQL数据实现了云存储特征100%兼容MySQL扩展性非常好天然支持分布式事务、数据节点及路由节点延迟非常小通过一致性算法来保证了数据的强一致性如此种种都是立足于一个正确的基点之上来建立起高楼大厦势必将基于MyCat的伪分布式数据库解决方案推入无人问津的深渊直至淘汰与消亡。 三、总结 使用MyCat的用户其实还是挺多的现在在了解业界市场的情况下我也是比较能理解他们因为需求有但真的是没有解决方案选择使用实则无奈之举毕竟他是开源的骂归骂也无怨言因为免费嘛有的用还有什么可言语的呢我也推荐大家去试用一下只有知道痛了才会感觉现在有新的方案出现的美好。 本文所述的关于MyCat的一系列问题主要目的是考虑到为了让业内同学不要继续采坑所以做了一些总结所述内容限于本人目前对MyCat的理解与认识如果有纰漏或者不足的地方欢迎指正或者给予补充感谢。 文章来源于 DBAplus社群 微信公众号 文章链接https://mp.weixin.qq.com/s/McWCXGE8JsgHAz1V2liFHw 转载于:https://www.cnblogs.com/keme/p/9774093.html
