谈谈MySQL水平扩展

写在前面

14年中换了一份工作,出国游荡了一阵子,目前工作离数据库内核远了点,离业务近了些,业务层面碰到的‘高深’技术问题也少了,旅行后发现人也懒了不少,导致博客都长草了

2015开始了,先表态一下目标:我2015年的目标就是搞定2014年那些原定于2013年完成的安排,不为别的,只为兑现我2012年时要完成的2011年年度计划的诺言

2015-goal

问题背景

工作中遇到数据库数据增长过快,单表一年之后预计到达35M行数据,可以预见MySQL性能将下降厉害,并且随着业务的规模化,担心单表将很难抗住并发压力,出现故障后恢复时间变长对业务影响也会变大,因此需要考虑数据水平扩展,目前项目采用Golang开发,一个Google开发的以简洁的语法,内建高并发模型,支持垃圾回收为主要特点的编译型语言,性能比Java好,开发效率比C/C++高,其目标是替代C/C++

分库分表

这四个字在阿里听得最多,其实这也是被问题和压力推动的,毕竟要支撑起那么大的业务,等着Oracle这样的公司提供解决方案是不靠谱的,还不如卷起袖子自己干,接着就陆续搞出并开源了Cobar,TDDL(不给出链接了,太容易搜到)这些数据库中间件,Cobar应该在TDDL之前,这个东西采用proxy方式,性能肯定不如以后续jdbc层面实现的TDDL,毕竟少了一次网络转发,现在TDDL在阿里核心系统上大量使用,不过外部用户想用起来这个没有那么容易,首先语言限制在了Java,另外还需要阿里配置管理服务Diamond的支持

要想水平扩展,就需要分库分表的支持,分库分表这四个字说起来很容易,按照id取模将数据打散分摊压力,但是干完这些之后需要解决由此带来的问题,这些很难:

1. 事务支持,扩库/扩表后事务就成分布式的了,问题难度显然上升了一个级别
2. 查询结果合并,这个看起来不难,但是把order by/limit/查询中不带分表字段等加上,要解决的问题还也不少
3. join,这个更难
4. 分库?分表?还是分库分表?这个需要考虑并做一个决定
5. 分完后能否合并?分容易,和很难
6.。。。

开源解决方案

数据库分库分表开源产品有很多,下图中列出了6个,它们已经在线上承载了较大压力,主要分为2类:代理及非代理,非代理方式是以library方式提供,library负责SQL解析,路由计算等,位于driver层,实现难度较大,一般仅支持少数几种语言;代理方式相当于一个多了一次转发,应用程序连接的是代理服务器,由代理服务器负责路由计算并发送SQL到目的DB,多一次网络,因此在性能上代理方式比非代理方式性能稍低

db-scale

这些解决方案中MySQL Fabric/TDDL两个为非代理方式,直接提供语言层面的支持,优点是性能会很好,劣势是支持的语言很受限制,TDDL支持支Java,MySQL Faric支持Java/PHP/Python,想实现其他语言支持,相当于再次实现一次,不过目前Java/PHP/Python非常流行,能够覆盖的用户很多了,TDDL对于外部用户来说,先用起来没有那么容易,和阿里平台紧密绑定,如果有时间配置Diamond的话,可以好好研究,这里不进行深入探讨

另外四个全部都是Proxy方式,以部分性能换来灵活性,这个就是仁者见仁智者见智的决定了,值得一提的是BAT中B也实现了一个Heisenberg的中间件,从部分代码、配置以及文件结构来看,这个是从Cobar来的,应该优化了部分特性,不进行赘述,有兴趣可以自己研究

MySQL Fabric
这个是MySQL官方水平扩展方案,号称管理目标为:farm of mysqld,其实我比较看好这个东西,原因是个人喜欢简洁的东西,总感觉Proxy方式多了一层转发带来了麻烦,除了性能外还有复杂性,运维起来也多了不少事情,毕竟这个进程down掉后可用性会受到影响,简单才是美,希望MySQL Fabric能够提供更多语言支持

Cobar
Cobar是阿里的中间件,以Proxy方式提供服务,在阿里内部大量使用,目前已经开源在github了,赞开源精神,据说在很多外部公司有一些成功使用的案例,配置比较容易,不需要依赖其他东西,有Java环境就OK,小试了一把,事务支持比较麻烦,需要通过set autocommit=0来实现,如果想要完美支持的话,还是需要修改JDBC或对应语言的MySQL library,分库示意图(Cobar中d.t分到两个库中:d1.t,d2.t):

cobar-frame

Cobar支持分布式分表,但是不支持单库分多表,前段(对接APP)和后端(对接MySQL)都实现了MySQL客户端协议,比较友好,对于扩表结果集的合并也支持,写其内部的SQL parse工程师功底应该比较深,显示起事务会报错,应该是“BEGIN”或者“Start transaction”不包含分表信息的缘故,但是这个可以通过defer到后面一个包含分表信息的SQL过来一起发到目标库中执行或者通过分布式事务,比如2PC来支持,执行效果:

cobar-mysql

Atlas
虽然个人对数字公司没啥好感,但是这个Atlas还是非常有特点的,它是基于MySQL-Proxy上二次开发的,主要支持两个特性:分表和读写分离,但是分表的话只支持单库多表,即事实上是不支持分布式分表的,所有分表都在同一个库中,小试了一把,下面是分库示意图(四个分表t_0,t_1,t_2,t_3在同一个库中):

atlas-frame

Atlas扩展性限制在单实例最大性能,但是好处是:事务支持的很好,因为不存在跨库事务,有些事情反而变得简单,读写分离这个东西其实没有水平扩展那么难,毕竟MySQL的备库很好搭,不得不吐槽一下,通过atlas看到的不是一张完整的表,而是各个分表,只能通过分表的字段定位和操作数据,否则会报错,与Cobar对比后,Atlas这个产品其实简洁也粗糙很多,但是的确有它特有的应用场景:

atlas-cmd

另外,Atlas配置稍微简单一些,但是分表算法支持上相对于Cobar显得并不完善

Vitess
Vitess是Youtube开源的数据库扩展及高可用方案,已经用于生产环境,功能强大,但是构架复杂,部署及运维成本较高,构架图:

vitess

Vitess在app与database之间存在vtgate及vttablet两个server,vttablet实现了MySQL连接池及row cache,与MySQL实例是一对一关系,可以当成是MySQL前端,一般与MySQL部署在一起,所有落到MySQL的query都需要经过vttablet,vtgate是一个proxy,负责路由计算以及app及vttablet之间的数据转发,分表规则及配置数据存放在topology中(zookeeper实现),因此每个query执行需要走的路径较长,虽然vttablet实现的连接池和row cache可以加速query执行速度,但是zookeeper访问,app与vtgage、vtgate与vttablet之间两次数据转发都要走网络,如果网络不够稳定可以预见性能损失较大

通过与vitess开发者确认,vtgate会缓存topology的分表规则数据,因此相对于其他proxy方案,只是多了一层vttablet的转发代价,但是考虑到row cache的加速,最后性能应该相差不大

另外,这个项目是采用Golang语言的,这对于Golang项目优势非常明显,采用本文中Vitess之外的方案,go-sql-driver无法支持事务,详见google-group vitess讨论

总结

本文源于项目实际需求,对国内外开源的MySQL水平扩展方案做了一个简单总结,可以看到国内互联网公司这这方面做得很不错,再次为他们的开源精神点赞

《谈谈MySQL水平扩展》上有15条评论

  1. 阿里云最近公测的DRDS分布式数据库,看起来会更加强大;
    对于楼主分析的Vitess方案,个人感觉vttablet这层row_cache没什么用? mysql本身已经有了buffer pool了,虽然这个只是页面级的,存在热点的问题。
    另外,团队内现在正在做基于代理的分布式数据库方案,希望不久也能被加入到楼主的分析选项中。

  2. atlas支持分库了https://github.com/Qihoo360/Atlas/wiki/Atlas-Sharding

    阿里DRDS对数据自动迁移貌似支持比较好了?从Spanner论文反映的广告用户MySQL痛点看,数据手工拆分维护是最大的痛点,MySQL复制数据一致性其次(目前semisync基本完善),再次分布式事务(场景有,但是很少)

    比较看好基于Go的开发。
    楼主去哪了:-)

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注