中云网消息 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,还有携程等嘉宾，大家有什么问题可以尽管问，咱们多准备几个话筒。