美图网高级DBA杨尚刚:数据库运维和性能优化之道

中云网消息  8月29日-30日,以“数据重构未来”为主题的D-Future七牛数据时代峰会在上海举行。七牛携百名创业明星,技术大咖汇聚国际时尚中心,共话数据发展,探讨行业未来!

美图网高级DBA杨尚刚带来以”数据库运维和性能优化之道“为主题的演讲,以下是演讲实录:

杨尚刚:我今天最后一场,我今天主要讲的数据库运维和性能优化的一些东西。

我2011年加入新浪,在新浪待了四年,主要是负责新浪微博的一些核心数据库架构设计,还有新浪数据平台底层软件优化,今年加入了美图,美图大家都知道,美图现在两款产品,一个美图秀秀还有一个美拍,现在用的人也非常多,这边我也是负责后数据存储的平台建设。下面两张图比较形象,相当于好多人都认为从左边这张图开始干,理想是右边,或者是更高级别的人物。

MySQL优点使用更简单,第二个免费。这两个是MySQL现在应用非常广泛的原因。第三个扩展性好,当然这个扩展性加引号,但是一旦你的规模达到上百万、上千台的时候,扩展因素打一个折扣,面临着一些挑战。第四个社区比较活跃,这个非常显然,这也是为什么现在PG没有比MySQL更广泛的原因,PG我也承认肯定比MySQL要好,但是你的社区一旦做得不好的话,还是非常不好的,酒香不怕巷子深。社区活跃是一个非常重要的点。最后一个MySQL虽然有非常多的问题,但是在现有的情况下MySQL还是依然能够满足我们现在大多数用户的需求。

说完它的优点再说它的缺点,第一它对复杂所谓支持不好,MySQL还是挺差的,之前我不知道有没有人看到,对一个语句,40条或者200条,肯定是40条快一些,反馈200条快一些这就是MySQL比较坑人的地方。第二对于SQL标准。第三个大规模集群方案不成熟,主要是知识面的支持上,官方没有一个很好的支持,还需要很多开元的二次开放才能支持好。下面这几个,ID生成器这个也不是那么重要。这个和方案相比,还是相对差一些。下面就是Online DDL这也是MySQL比较大的一个痛点,MySQL就会比较麻烦。下面是HA方案,MySQL没有一个非常可靠的方案,很多还需要依赖第三方工具。下面就是备份恢复这个也是比较复杂,展示机构少,这个时候比较被动,下面就是分支。

下面再说虽然有这么多问题,MySQL还是很受欢迎。第一个可靠性,第二经过大规模部署的验证,这种都已经在线上通过大规模的生产考验,所以大家都是认可的。下面这两个是比较支持的,找踩坑,很多技术都是并不是说它怎么着,还是需要看一下其他人的经验。这个就是DBAlife,比如像各种各样开发需求,各种各样的需求,你还得去满足。各种各样需求。下面就是SQL优化,也是DBA工作人员很大一部分,下面就是各种救火和故障,你的主库故障,各种各样问题,都是需要DBA去介入的。下面就是一些各种业务,项目上线,还有日常的沟通。

怎样能变得不苦呢?DBA涉及到各种更改和创建,它占了很多时间。如何去解放DBA的双手,主要是两个部分,第一建立数据库开发规范,第二个把固化基本原则到自动化审核流程里去,减少DBA的沟通成本和一些重复工作。

这是数据库开发规范,现在网上也有很多,我就不细说了,说说它的意义,数据库开发规范,保证线上的规模是统一的,是遵守创业规范的。这样对于你后面一些都是非常有好处的。这个开发规范如何去遵守,这个也是需要DBA去投入经历的,这个东西,虽然开发者会去看这个东西,这个就需要DBA主动去推这个东西,定期给开发培训,开发能够认识到规范一个重要性,也能减少DBA后续运维的一个成本。

这是一个简单的规范示例,主要是一些表情选择,还有定义,当然肯定比这个复杂多,如果你把规范定得很详细的话。

DDL自动化有三个部分,建表、审表和改表这都是日常的需求。这是一个主要流程,提交DDL,首先你系统里面会做一些语法检测,肯定还是要打回去要重新去改,语法通过,这些动作如果没自动化就需要DDL打电话发邮件,这部分工作就是看它是否符合开发规范,刚才提到的自己的选择,这部分不过的话,也是需要开发再去修改,开发修改的话,可以去线上支持。当然这里还会设置关于操作,比如你去做表还是发表一些创建的操作,要区分这个东西,这个操作还是尽量让开发直接去搞,开发肯定意识到了操作,如果是的话可能就需要DDL的选择,做一些提前预案这些东西。

当然刚才提的问题也是DDL的问题,MySQL是内部不支持的,960的DDL,很多实际在生产上用的话,还是有比较大的距离。为什么MySQL会有非常大的问题呢?它需要一个锁,一旦你去执行这些操作的时候,都是要组织表,而组织这个过程中,你不能再往里面写数据。你的业务数据是不能服务的,这样一般产品是不能接受的,所以这个是MySQL一个比较大的问题。

当然现在也有一些方案,比如像基于FacebookOSC的原理,下面表格主要和做对比,其他两个5.6的是不支持的,官方内置的这些东西,但是它的问题还是比较多的。包括解决不了DDL延时问题,还有用了也会有影响。比较多的是基于FacebookOSC的延伸体。

这个是OSC的原理,还是比较敞亮的。一开始核心是下面部分,调整块大小,同步数据,根据覆负载调整进度,一个比较核心。后面或者前面都是一些准备步骤,或者是一些简单的操作。看一下MySQL另外一个,慢日志,如果你要去做的话,很多都要根据慢日志去做的,如果有一个系统的话,发现某一个你就得去判断,看一下,有没有慢日志,这个基本上是一个比较常规的过程。

而这个里面很多步骤都是可以去自动化做掉的,这个的话,慢日志化系统,根据慢日志化系统开发,负责业务。

这个算一个基本系统架构,基本上主要依赖这个是分析MySQL比较好的,分析的结果也是非常详细,报表也是比较好用。

第二个Logstash,都可以。第三个Anemometer,开了一个系统,右边这个图就是基本的数据流程,也是非常简单,基本上就是数据和入库各种展示。

这个就是简单的页面,最上面是两个时间段的情况。比如昨天某个时间,下面框就是它提供的哪些展示,也可以定制。中间这个根据IP都可以去调整。下面是一些展示的过程,一个例子。这个就是你点进去某一个,它的变化曲线,在什么时候比较多都可以看到,包括也可以看到,在这可以直接点出来,它的结果,不需要再线上去看,扫描或者有没有都可以在这里面看到。所以说还是比较方便的。

另外一个的变化就是备份系统,备份系统是做这个行业首先要保证的,首先性能不是最重要的,安全是最重要的。所以备份都是最重要的。悲愤意义,很简单就是我为了数据恢复。下面备份的方式,MySQL备份方式也非常多,没有官方的一些支持,也是各种各样,像全量、增量、热备和冷备,物理和逻辑,延时,这种方式都是针对不同方式去做的。建立方式,基于热备加物理是更好的。如果能做出来最好,不能做的话,热备加物理也可以满足很多需求。如果你一些非常和核心的业务,考虑用组合的方式。

M:这是备份系统数据,在新浪做的系统,每年备份数据,做7000加次扩容,每年要做12加次数据恢复,当然这个东西,实践很多开发不注意,都可能导致不良的后果。数据量的话,每日志量每天3TB,数据总量在2PB,每天悲愤数据量百TB级。

备份优化我们主要做下面几个部分,第一主主要悲愤策略集中式调度管理,对格式化都不太好,还有热备至四,统计分析,还有校验问题,最后采用分布式文件系统存储备份。我们当时也调研过其他的,最终权利选择了这种。

当然分布式文件系统,之所以要用也是有一些痛点,下面几点,存储分配的问题,当时已经存储了六、七十台左右,你在真的需要存储管理容量,都需要人工去管理,能自动化但是做的不是特别好,还是比较复杂。NFS这个还是导致经常负载特别高,备份效率特别低,下面还是存储集中式管理,最后数据可靠性更好,可能会比单点问题会有好处的。

当然我们使用分布式系统我们也做了优化,第一个采用Pbzip压缩比能做到三分之一,降低多副本存储带来的存储成本,第二个使用压缩之后,降低网络带宽消耗。最后一个是erasure的方案调研,使用这种方案,也都比较成熟。右边是一个简单的架构图。

提到MySQL版本问题,MySQL版本现在是说官方有两个一个社区版、一个企业版,还有其他两个,MariaDB版是MySQL去做的。各国内来说还是用MySQL社区版比较多,MySQL企业版比较少,传统行业有钱的可能会选且版。

下面是我的建议,你选MySQL社区版。但是如果对于大多数用户来说,社区版稳定,对于后期的支持肯定会比MySQL企业版更好一些。最后就是MariaDB在国内用的非常少,而且优化方向和社区版还是有一定的差距。

这个是MySQL主流版本,当然之前那些都比较老了,5.0、4.几现在主流的是5.0.现在主流的就是5.6和5.5,现在一般用5.6就可以了,也是一个比较稳定的版本。5.5的话,是保守用5.5.

下面是MySQL复制问题,MySQL复制的话,好多人都会遇到一个比较坑,MySQL复制延迟问题和MySQL安全问题。

MySQL复制采用一些不可靠的投递,不管有没有执行这些问题都会存在,所以说安全性还有延时问题被很多人诟病的一个点。

下面的图就是它的一个框架,右面红框里面就是瓶颈原因,使用或者概念。

这种概念的简化,现在也有很多了,像第一5.6的方案,5.6也是一个半成品的方案,也不能解决很多瓶颈,能解决一些特定的瓶颈。二个以为代表的第三方工具,还有sharding,把你的数据弄的更小这也是一个比较好的方案。

这是5.6和5.7的并行复制的优化,5.6刚才提到一个比较麻烦的问题,假设我是一个,你就不能用了,5.6只能根据一个副题复制,我有十个我可以取十个点,这样只有一个库你开不开没什么区别。另外一个5.7说起来比较复杂,5.7基于,这种方式是可以跳出副题复制的。它并行率是非常高的,5.7是一个相对比5.6好很多的并行复制解决方案。

MySQL除了复制,下面还有很多,很多人听说过的几类,这类似的方案有很多。怎么去选择?从两个方面去考虑,你需不需要支持,比如说如果你哪个不需要,用MySQL就可以了。如果你对这种需要多点写入,类似于需要一些MySQL这种方式。对比这个,做这个图可以去选择,合适的复制方式。

这个是半同步,半同步的话,比原生复制多了一点,从这个时间里面可以看出来,上面就是原生,写到从头不管了,下面就是半同步,半同步是需要同步其中有一个同步,是需要返回的,所以安全性比较可靠的。

半同步复制优化在5.6和5.7有很多的,5.6还是一个同步,5.7可以设置多个同步。这样的话安全性可以更好地去保证。下面就是对半同步更好的优化。最后通过改进5.6的MySQL提升半同步的性能。

这就是MySQL5.7,这个是官方提供的多主复制方案,现在5.7已经有了,是可以达到多组同步复制化。如果说这个东西以后能做得好一点的话,会是一个比较好的方案。

下面是InnoDB的引擎优化,ACID也是目前做得比较好的引用,包括一些特性或者变化,或者是MVCC的一些支持都是非常好的。一些主要参数,主要参数是跟性能有关的基本就这几个,5.6加了一些,变化不是特别大。这个图就是不同redo,这个图左边是redolog5.5限制不能超过4G,这样的话,在这种压力的时候可控还是有的,每一段时候会刷一次,就会有一次性能对比,大的时候,刷的频率就会低很多,就会平稳很多。

这个图是SSD上的优化,这也是不太需要优化的。后面这几点,InnoDB压缩和cgroup这还是需要的使用单机多实例,都是非常有需要的。

这个是现在MySQL5.6最新5.7版本,它在一些比较重要的参数上都有一些重要改进。说几个,第一个在5.6的时候还是一样,5.7已经默认。这样安全性会比之前版本黑更好,而且是已经默认参数。下面还有一些预热这部分也都是默认,还有一个也比较全部改。下面一个也已经改了,这样数据安全性会更好。

下面再说一个,TokuDB.InnoDB的特点,是一种基于结构,正是因为这个原因,所以写入密集场景非常好,并且压缩都是非常不错,也是原生支持,还是有很多吸引人的地方。下面就是主流分支都支持,官方目前最新版本应该是这样,已经默认了。

MySQL压缩的我们做的一个对比,MySQL有三种。移动也是压缩,它压缩是用到中间这种方式,右边图就是一个对比,可以看到,压缩比是最好的黄色的,比另一个小好一些,好两到三倍。现在使用的时候,都会使用这种InnoDB来做,写字优化是非常好的。

这个就是我们之前做的一个MySQL写入性能对比。可以看到上面几个陡的都是InnoDB,一开始特别高的是另外一个。很多可以看到InnoDB一开始跟他只明白四、五千,而TokuDB在整个过程中都是非常稳定。

TokuDB有一些问题,还是有不少漏洞,现在版本更新非常快,所以更新面还是要谨慎使用。

最后说一下数据库存储变迁,近几年也是变化非常快的,还有一个集中式分布式的演进,这个东西也是一个过程,不是谁好谁坏的过程,也是一个相互演进的过程。比如像最早的机械硬盘时代,从诞生到2001年之前都是在机械硬盘,机械硬盘也比较差,前三、四年发展,来适应这种机械硬盘的读写特性,但是随着互联网的发展,它的瓶颈越来越明显,当时最多的一个上面,挂20多以上,全是机械硬盘,挂20多个一旦出现一些缓存问题,还是不行,单一性实在太差。这种性能问题,导致你需要批判,因为你性能太大,数据太小,满足你业务的一个需求。

后来就是闪存时代,最早是NAND技术出现,互联网是最新开始吃螃蟹,在2001年的时候,成本高很多,每GB很高,它的也是非常明显,有击败被的提升。所以说在当时闪存刚刚起步的时候,主要性还是保持一个怀疑。后面再往下发展,混合存储,闪存还是太贵了,手机成本节约,会出现混合存储,代表性就是用SSD的缓冲来解决这样一个问题。你的读写最好有比较明显的热点,微博这几年也用过两年多,当然中间还是有很多问题。下面就说到问题,运维SSD的寿命还是非常大。

责任就是现在的时代,闪存2.0时代都不是问题,成本低,基本上都采用SSD这种方式。

SSD肯定还会有人怀疑,随着SSD出现就有问题,SSD寿命会不会有问题,肯定会有问题,有一个极限,如果你买SSD产品你写80T都有限制,当然这个东西对你业务来说你要算一下能够扛多少年,你算算能写好多年,这个寿命不太需要考虑。第二个SSD比HDD会不会更可靠,这是非常显然的,肯定是可靠,因为它的一些问题,非常容易出现磁盘的损害,非常容易出现,整体比SSD低很多。第三故障率,很快刚才一样比HDD要好很多,所以现在不用需要怀疑。

为什么要采用善存,因为这种人还是要比机器贵,人你要算工资,机械材料便宜。

最后说一下分布式存储,这个我们之前也测试过,基于MySQL,我觉得它在未来这几年也是一个不错的方向,它对于规律和数据库的收缩性都是非常有好处的。当然它的缺点或者它一个风险,你发现它放在一个里面,当然技术发展这个问题肯定会逐渐解决的。

这就是之前好多人问的,我们当时在微博上搞了60亿表的问题,当然数据也是比较核心,数据也都是这种粉饰。所以它单表的话,单表的数在60亿以上,原因也有很多。DB比较懒,导致的问题,但是还有一个想看看极限,到底能到多少。这个东西其实不大,确实是有风险,我们也清楚,一个单表恢复,这个肯定有风险,但是你的方案足够成熟,其实也都是可以接受的。这个东西在你当前能解决问题的情况下,没必要搞一些过于超前的方案。能解决问题的情况下,或者在你能力范畴之内,能解决问题,就可以了。

最后就是总结,你整个数据库的标准化或者自动化,在早期都需要关注的,第二个平台化和服务化也是做了一个基础平台主要目标,优化也是无止境的,还有适合自己才是最好的。所以说有时候拿着锤子不要看所有东西都是钉子,要选择自己合适的,要选择自己把控的东西,不要为了尝试一些新技术而去尝试,很多东西都是有成本的。

这是我的微博、微信,有兴趣可以加一下。

主持人:到现在时间过得挺快的,这两天的全部正式环节就到这结束了,再次谢谢大家支持!还有一些非正式的环节,临时加上去一个环节是,我这边除了今天还没有因为要赶着回去的嘉宾留下了,我也把七牛轻易不上台的技术大牛请过来,我刚在群里说了,有什么问题大家尽管问,现在留下的,从这边据说是大数据领域最帅的技术大咖,七牛技术总监陈超大家也听他演讲了,还有CEO,还有携程等嘉宾,大家有什么问题可以尽管问,咱们多准备几个话筒。