ITPUB论坛-中国最专业的IT技术社区

 找回密码
 注册
查看: 16775|回复: 18

Mysql的读写分离真的能提高性能吗?

[复制链接]
认证徽章
论坛徽章:
69
奥运会纪念徽章:射击
日期:2016-09-06 23:08:25马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11马上加薪
日期:2014-08-04 13:43:552013年新春福章
日期:2013-02-25 14:51:24复活蛋
日期:2013-02-18 11:25:01奥运会纪念徽章:沙滩排球
日期:2012-10-27 14:59:31ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:32奥运会纪念徽章:柔道
日期:2012-09-21 09:08:36ITPUB 11周年纪念徽章
日期:2012-09-28 17:34:42
发表于 2009-6-30 10:12 | 显示全部楼层 |阅读模式
在网上经常看到这样的文章,某某论坛压力太大,于是在后台把mysql服务器分离成两台A、B,A专门做写操作,再通过数据复制把数据写到B,读取数据都来自B

很疑惑,除了机器的性能强大和IO能获得一些好处(一台机变两台机)以外,真的能改进性能吗?B机器还照样要写(复制也是写),而且写得一点不少。中间产生的lock也是一样的。复制可以稍微有几秒的不同步时间,感觉就跟采用了低优先级写差不多,差别只是,如果用了低优先级写,在写入的时候网页要停顿一下,现在用了复制,网页不停顿了,但可能再打开的时候发现还没写上(因为可能存在复制时延),其实都是半斤八两了
论坛徽章:
52
2015年新春福章
日期:2015-03-06 11:57:312012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:32:552012新春纪念徽章
日期:2012-02-07 09:59:35
发表于 2009-6-30 10:23 | 显示全部楼层
原帖由 tigerfish 于 2009-6-30 10:12 发表
在网上经常看到这样的文章,某某论坛压力太大,于是在后台把mysql服务器分离成两台A、B,A专门做写操作,再通过数据复制把数据写到B,读取数据都来自B

很疑惑,除了机器的性能强大和IO能获得一些好处(一台机变两台机)以外,真的能改进性能吗?B机器还照样要写(复制也是写),而且写得一点不少。中间产生的lock也是一样的。复制可以稍微有几秒的不同步时间,感觉就跟采用了低优先级写差不多,差别只是,如果用了低优先级写,在写入的时候网页要停顿一下,现在用了复制,网页不停顿了,但可能再打开的时候发现还没写上(因为可能存在复制时延),其实都是半斤八两了




应该说使用读写分离......有几个好处
1.增加冗余
2.增加了机器的处理能力(硬件资源增加了)
3.对于读操作为主的应用,使用读写分离是最好的场景.....因为可以确保写的服务器压力更小....而读又可以接受点时间上的延迟

若真是想解决数据的写瓶颈,可能还是需要从架构的角度去考虑....MySQL提供复制与读写分离的代理框架,对大多数用户而言的....是种低成本,简单容行的方案

若你的要求高,象TT等公司,他们肯定会考虑再扩充的....

使用道具 举报

回复
论坛徽章:
1
2010数据库技术大会纪念徽章
日期:2010-05-13 09:34:23
发表于 2009-6-30 11:41 | 显示全部楼层
原帖由 jinguanding 于 2009-6-30 10:23 发表




应该说使用读写分离......有几个好处
1.增加冗余
2.增加了机器的处理能力(硬件资源增加了)
3.对于读操作为主的应用,使用读写分离是最好的场景.....因为可以确保写的服务器压力更小....而读又可以接受点时间上的延迟

若真是想解决数据的写瓶颈,可能还是需要从架构的角度去考虑....MySQL提供复制与读写分离的代理框架,对大多数用户而言的....是种低成本,简单容行的方案

若你的要求高,象TT等公司,他们肯定会考虑再扩充的....

说的很对,像论坛这种访问以读为主的类型,读写分离肯定是有用的,楼主可以用show status收集数据分析下读写的量,
更高级的优化应该是把update和访问频繁的数据cache在内存中了,个人认为比较高级的优化需要深入分析业务,确定负载较高的几个点,再寻找解决方案。
根据80 20 的原则,只要解决20%的最消耗性能的点,80%的性能问题可以得到解决。

使用道具 举报

回复
论坛徽章:
41
ITPUB元老
日期:2007-04-18 10:10:372012新春纪念徽章
日期:2012-02-13 15:09:232012新春纪念徽章
日期:2012-02-13 15:09:232012新春纪念徽章
日期:2012-02-13 15:09:232012新春纪念徽章
日期:2012-02-13 15:09:232012新春纪念徽章
日期:2012-02-13 15:09:23迷宫蛋
日期:2012-05-09 13:09:18双黄蛋
日期:2013-01-21 12:55:59马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14
发表于 2009-6-30 16:48 | 显示全部楼层
读写分离主要用来分摊读的压力,如果读压力不大的话,就没有多大意义了。

使用道具 举报

回复
认证徽章
论坛徽章:
69
奥运会纪念徽章:射击
日期:2016-09-06 23:08:25马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11马上加薪
日期:2014-08-04 13:43:552013年新春福章
日期:2013-02-25 14:51:24复活蛋
日期:2013-02-18 11:25:01奥运会纪念徽章:沙滩排球
日期:2012-10-27 14:59:31ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:32奥运会纪念徽章:柔道
日期:2012-09-21 09:08:36ITPUB 11周年纪念徽章
日期:2012-09-28 17:34:42
发表于 2009-6-30 20:17 | 显示全部楼层
原帖由 WESTLIFE_XU 于 2009-6-30 16:48 发表
读写分离主要用来分摊读的压力,如果读压力不大的话,就没有多大意义了。




对于我一楼所说的B机器,读和写的压力(或量)比原先都并没有减少,差别就是复制可以允许些微的时延,相当于低优先写,减轻了一些锁冲突的问题

使用道具 举报

回复
认证徽章
论坛徽章:
69
奥运会纪念徽章:射击
日期:2016-09-06 23:08:25马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11马上加薪
日期:2014-08-04 13:43:552013年新春福章
日期:2013-02-25 14:51:24复活蛋
日期:2013-02-18 11:25:01奥运会纪念徽章:沙滩排球
日期:2012-10-27 14:59:31ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:32奥运会纪念徽章:柔道
日期:2012-09-21 09:08:36ITPUB 11周年纪念徽章
日期:2012-09-28 17:34:42
发表于 2009-6-30 20:19 | 显示全部楼层
原帖由 jinguanding 于 2009-6-30 10:23 发表




应该说使用读写分离......有几个好处
1.增加冗余
2.增加了机器的处理能力(硬件资源增加了)
3.对于读操作为主的应用,使用读写分离是最好的场景.....因为可以确保写的服务器压力更小....而读又可以接受点时间上的延迟

若真是想解决数据的写瓶颈,可能还是需要从架构的角度去考虑....MySQL提供复制与读写分离的代理框架,对大多数用户而言的....是种低成本,简单容行的方案

若你的要求高,象TT等公司,他们肯定会考虑再扩充的....





对于机器B,它的负荷情况并没有比原先单机的情况减轻,还是要写那么多(通过数据复制),还是要读那么多(读集中在它身上)

使用道具 举报

回复
论坛徽章:
0
发表于 2009-7-1 09:08 | 显示全部楼层
任何一种方案都不是万能的,也不可能完全适合每个单位的业务需求,我觉得使用m-s想减轻你的负荷,首先应该判断现有的架构,问题出现在哪?m-s是否真的适合现有架构的改良,比如说你的数据量特别的大,并发访问比较高等等,看看是否数据切分更适合?是否数据库前端代理更适合?等等,方案永远是方案不一定是最终的解决手段,适合现有架构改良是最好的。

使用道具 举报

回复
论坛徽章:
10
会员2007贡献徽章
日期:2007-09-26 18:42:102011新春纪念徽章
日期:2011-02-18 11:43:342010广州亚运会纪念徽章:帆船
日期:2010-11-13 17:33:442010年世界杯参赛球队:科特迪瓦
日期:2010-10-08 11:21:35ITPUB9周年纪念徽章
日期:2010-10-08 09:31:222009日食纪念
日期:2009-07-22 09:30:00生肖徽章2007版:猴
日期:2008-01-02 17:35:53生肖徽章2007版:鸡
日期:2008-01-02 17:35:53ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44ITPUB十周年纪念徽章
日期:2011-11-01 16:20:28
发表于 2009-7-1 12:56 | 显示全部楼层
master的写是并发的。

slave 的写是顺序的,通过bin-log日志。所以slave写所消耗的资源没有master大。

使用道具 举报

回复
论坛徽章:
52
2015年新春福章
日期:2015-03-06 11:57:312012新春纪念徽章
日期:2012-02-13 15:12:252012新春纪念徽章
日期:2012-02-13 15:12:25生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:33:22生肖徽章2007版:龙
日期:2012-02-07 10:32:552012新春纪念徽章
日期:2012-02-07 09:59:35
发表于 2009-7-1 13:18 | 显示全部楼层
原帖由 tigerfish 于 2009-6-30 20:19 发表





对于机器B,它的负荷情况并没有比原先单机的情况减轻,还是要写那么多(通过数据复制),还是要读那么多(读集中在它身上)



你还是没明白我的意思....虎..........


我意思,对于小集群内部只能做到这样,写是一样多的,读是分散掉了(可能会考虑Slave 机多点)

你数据量大,可以考虑进行数据切分嘛.....也就是可以考虑再扩展其架构,现在有很多代理框架的....

使用道具 举报

回复
认证徽章
论坛徽章:
69
奥运会纪念徽章:射击
日期:2016-09-06 23:08:25马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11马上加薪
日期:2014-08-04 13:43:552013年新春福章
日期:2013-02-25 14:51:24复活蛋
日期:2013-02-18 11:25:01奥运会纪念徽章:沙滩排球
日期:2012-10-27 14:59:31ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:32奥运会纪念徽章:柔道
日期:2012-09-21 09:08:36ITPUB 11周年纪念徽章
日期:2012-09-28 17:34:42
发表于 2009-7-1 14:11 | 显示全部楼层
原帖由 jinguanding 于 2009-7-1 13:18 发表



你还是没明白我的意思....虎..........


我意思,对于小集群内部只能做到这样,写是一样多的,读是分散掉了(可能会考虑Slave 机多点)

你数据量大,可以考虑进行数据切分嘛.....也就是可以考虑再扩展其架构,现在有很多代理框架的....




我们目前不存在瓶颈

只是对这种技术手法表示困惑,用过的人宣称,确实有很大改进,我只是想从技术上探讨、解释,为什么表面上看起来并没有减少读写量,但却能获得实际效果?

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 电子杂志 团队 统计 虎吧 老博客 知识索引树 读书频道 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 | IT博客
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛 | SAP ERP系统
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
京ICP备16024965号 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表