美图网杨尚刚：数据库运维和性能优化之路
互联网IDC圈9月2日报道，8月29日-30日在上海国际时尚中心举行的D-Future数据时代峰会是七牛为大家带来的一场数据盛筵，汇聚了业界领袖、行业专家，他们将从产业的角度和技术的角度来解读数据从何而来，数据如何应用，数据重新构未来。
数据库优化是一个很大的问题，迄今为止一直困扰着所有的数据库管理员和程序员。会上美图网的杨尚刚跟大家分享了数据库运维和性能优化方面的内容。
杨尚刚
以下是杨尚刚演讲内容（根据速记整理）：
杨尚刚：我今天最后一场，我今天主要讲的数据库运维和性能优化的一些东西。下面是我的微博，有兴趣可以加一下。
我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比较懒，导致的问题，但是还有一个想看看极限，到底能到多少。这个东西其实不大，确实是有风险，我们也清楚，一个单表恢复，这个肯定有风险，但是你的方案足够成熟，其实也都是可以接受的。这个东西在你当前能解决问题的情况下，没必要搞一些过于超前的方案。能解决问题的情况下，或者在你能力范畴之内，能解决问题，就可以了。
最后就是总结，你整个数据库的标准化或者自动化，在早期都需要关注的，第二个平台化和服务化也是做了一个基础平台主要目标，优化也是无止境的，还有适合自己才是最好的。所以说有时候拿着锤子不要看所有东西都是钉子，要选择自己合适的，要选择自己把控的东西，不要为了尝试一些新技术而去尝试，很多东西都是有成本的。
这是我的微博、微信，有兴趣可以加一下。
当前题目：美图网杨尚刚：数据库运维和性能优化之路
文章源于：http://azwzsj.com/article/sdcpjc.html
