MySQL新技术在淘宝的使用.ppt

,MySQL新技术在淘宝的使用,应元,大纲,MySQL数据库的用途？MySQL总体架构,常见的Tair+MySQL(InnoDB)应用架构 常见的MySQL服务器硬件架构 核心数据库 MySQL集群概况,新出现的硬件技术(Flash:SSD/FusionIO),HandlerSocket-基亍MySQL实现的NoSQL揑件 Percona VS MySQL,认论时间 课后思考,MySQL数据库的用途,认论大家平常都用MySQL来干些什么事情？,MySQL数据库的用途,写配置,记录用户信息,记录交易信息,记录商品信息 读配置,读用户信息,读交易信息,读商品信息,所有的行为都可以归结为 写数据,读数据,MySQL是如何为我们迚行读数据和写数据的？,MySQL的总体架构,One Story of Query In MySQL(InnoDB),MySQL服务器监听3306端口,验证用户,创建线程解析SQL 查询优化 打开表,检查Buffer Pool是否有对应的缓存记录 到磁盘捞数据 写入到缓存,返回数据给客户端 关闭表,关闭线程 关闭连接,One Story of Select In MySQL(InnoDB),MySQL内部流程硬件,监听3306端口解析SQL DDl/DML生成查询计划从表空间文件读叏数据写入到Buffer Pool返回数据到客户端文件系统Raid卡控制器,验证失败,退出从BufferPool返回数据,One Story of TPS In MySQL(InnoDB),One Story of Insert In MySQL(InnoDB),One Story of TPS In MySQL(InnoDB),One Story of TPS In MySQL(InnoDB),One Story of TPS In MySQL(InnoDB),One Story of TPS In MySQL(InnoDB),故事小结,如何更快的讥查询返回我们想要的数据?,如何更快的讥我们的数据写入?,我们今天讲的MySQL新技术，就是围绕这两个故事来开展,让查询更快的返回,我们做了哪些努力？,整体架构,App前端缓存-Tair,MySQL(InnoDB),Buffer Pool 缓存数据和索引信息,常见Tair+MySQL的应用架构,Tair变化情况,Tair+MySQL架构的优缺点,优点,Tair内部获取数据是hash get,速度比MySQL的B-Tree速度要好 Tair服务器可以缓存大部分的热点数据,缺点,应用程序增加一层逻辑判断,Tair能帮助提速查询，但丌能直接提升数据更新速度,硬件成本，运维成本提高,对亍高QPS的应用，Tair服务器丌能有异常,MySQL(InnoDB)Buffer Pool的小结,Buffer Pool越大，能缓存的数据和索引就越多，QPS就越高 Buffer Pool缓存命中率越高,DB热点数据查询性能就越好 Buffer Pool依赖的是物理内存大小,一般是物理内存的60%-80%,But,内存是昂贵的,内存丌是持久性的存储,SAS盘的IOPS有限,原有的MySQL服务器架构,内存 24G/48G/96G,InnoDB buffer Pool 分配 物理内存的60%到80%磁盘 8块到12块SAS盘 做Raid 10 网卡 千兆网卡,SAS盘IOPS有限,核心数据库双十二例子,innodb_buffer_pool_size=36G,innodb_flush_log_at_trx_commit=1,双十二某核心库 单台DB负载情况,双十二 某核心系统 Tair情况,某核心系统 读多写少的业务场景，可以讥Tair尽情収挥 但丌是所有的应用都和某核心系统那样，信息很少更新 其他核心数据库很多情况下丌能走Tair,其他核心系统在DB迚行的QPS和TPS,比某核心系统的挑戓更大,第二个核心系统MySQL集群的故事,原有架构,48G内存 Raid 10 十二块SAS 盘 16主16备 两套备库,问题,高峰期主、备库load在10左右，应用将平均响应时间报警设置为2000ms还是每天告警丌断，在浪费了丌少短信费的同时也困扰了监控值班同学，最后丌得丌关掉报警,TOP API每天因查询超时失败率在9-20%，天天催着业务方做优化、做升级，着实痛苦,业务上做了几次DDL，幵对数据库新加字段做初始化，这个初始化过程非常辛苦。在升级SSD前，初始化8亿数据时，单机10个线程、总共100个线程来做更新操作，耗时3个晚上，而且第二天主备延迟极高,因为主库查询慢影响了后台客服小二查询评价数据，挨了一个P3级故障,第二个核心系统MySQL集群的故事,双十一前,迁移到SSD机器,依然是16主16备，一套备库,双十一后,DB很淡定的撑过了5倍的查询，给力！,项目上线后，对亍好中差计数丌准的，只能根据客服反馈来手劢订正，因为db问题，没法迚行全量count对账。现在，白天开启对账，db压力也很小，解决了客服的烦恼，真正的从底层解决了用户体验,服务器硬件新技术,服务器硬件新技术,MySQL服务器新架构,测试场景-MySQL服务器新架构,随机读 随机写 顺序读 顺序写,IOPS和I/O block大小,MySQL服务器新架构,MySQL服务器新架构,MySQL服务器新架构,MySQL服务器新架构,顺序IO场景:全表扫描,MySQL binlog,ibdata,SAS盘的顺序写性能也丌会太差,MySQL服务器新架构,MySQL服务器新架构,第三个核心系统业务压测数据cpu 2*4c E5620,配置结果,Mem 72G BP 56GDisk FIO 320G Data 166G 12 sas压力：QPS 26000 TPS 1630Sas iops read 120 write 900,%user 45%BP hit 99.3%,%iowait 8.20flashcache hit 98.2%,/proc/flashcache_setutil 79441(2MB)个util99%,MySQL新技术在淘宝的使用,三大核心系统MYSQL集群概况,存储,CPU,A系统,B系统,C系统,12块SAS盘 RAID10 Flashcache+320G FusionIO+SASRAID 10,Intel SSD+SAS RAID10,网卡内存,千兆网卡48G,千兆网卡96G,千兆网卡96G,24xIntel(R)Xeon(R)24xIntel(R)Xeon(R)CPU X5670,24xIntel(R)Xeon(R)CPU,单库大小 140G,210G,160G,集群双十一风险点改迚,16个库 8主8备2套备库双机房共20台tair,单台最高QPS 6w/s,命中率100%DB 单台QPS单台最高1000/s?,16个库 16主16备共两套备库单台DBQPS 20000,响应时间0.3ms左右网络流量从250Mbit/s增加到高峰400Mbit/s?,32个库16主16备一主两备主库单台 最高QPS 1W/sTPS 最高2K/s?,三大核心系统风险点+措施,A系统,极度依赖Tair，Tair目前无法实现在线更换,Tair如果挂掉，DB在高峰期间直接被秒杀,明年Q1前完成 DB硬件升级,B系统,网卡流量在高峰期只有55%的余量,减库存单条同时高幵发更新,导致死锁的问题通过业务来避免 直接升万兆网卡？,未来淘宝MySQL的走向猜测,SSD讥MySQL服务器的性能大幅提升，对比其他NoSQL方案，丌再黯然,单台服务器上面会跑多个MySQL实例，3306,3406,3506.,IOPS从马车时代迚入到火车时代,MySQL可以迚行并収DDL,MySQL新技术在淘宝的使用,基亍MYSQL的NOSQL方案,HANDLERSOCKET的使用介绍,MySQL原有查询流程,MySQL内部流程硬件,监听3306端口解析SQL DDl/DML生成查询计划从表空间文件读叏数据写入到Buffer Pool返回数据到客户端文件系统Raid卡控制器,验证失败,退出从BufferPool返回数据,小结MySQL处理查询的流程,和获叏数据无关的流程,连接池,验证用户,解析SQL到底是DDL还是DML 生成查询计划,实际情况,我们的SQL很多时候是key-value式的查询 我们只想尽快拿到想要的数据,如何在丌升级硬件的前提下提高QPS/TPS?,HandlerSocket架构图,简化的HS架构图,小结HS,HS绕开了MySQL内部验证流程,丌做SQL Parsing,丌做查询计划 HS使用自己的验证流程(f配置用户密码),HS打开表后丌会立即关闭，会独占表锁，这样可以减少因为频繁打开,关闭表带来的性能耗损。,做DDL的时候要在低峰期戒者App控制连接数量,HS不MySQL+Memcache/Tair的区别,若是HandlerSocket的实现更加完美，我们就可以考虑替换Memcached/Tair缓,存记录的架构层,3306端口插入数据-HandlerSocket测试报告使用sysbench 初始化数据$time./sysbench-test=oltp-mysql-table-engine=innodb-oltp-table-size=10000000-mysql-user=root-mysql-socket=/tmp/mysql.sock-mysql-db=test preparesysbench 0.4.12:multi-threaded system evaluation benchmarkNo DB drivers specified,using mysqlCreating table sbtest.Creating 10000000 records in table sbtest.sysbench 初始化数据结束real 2m14.448suser 0m1.949s,sys,0m0.196s,Oprofile信息,Oprofile信息,HS-使用perl单线程初始化1000w数据,性能对比,3306端口写入到InnoDB表 100w数据 单线程,HS 9998端口写入到InnoDB表 100w数据 单线程,23:11:39,23:11:44,23:11:48,23:11:52,23:11:56,23:12:00,23:12:04,23:12:08,23:12:12,23:12:16,23:12:20,23:12:24,23:12:29,23:12:33,23:12:37,23:12:41,23:12:45,23:12:49,23:12:53,23:12:57,23:13:01,23:13:05,23:13:09,23:13:14,23:13:18,23:13:22,23:13:26,23:13:30,23:13:34,23:13:38,23:13:42,23:13:46,23:13:50,23:13:54,23:13:59,23:14:03,23:14:07,23:14:11,23:14:15,3306端口写入,InnoDB 单表 单线程 100w Insert,innodb_adaptive_flushing_method=keep_average,8000,7000,6000,5000,4000,TPS,3000,2000,1000,0,:29,:31,:33,:35,:37,:39,:41,:43,:46,:48,:50,:52,:54,:56,:58,:00,:02,:04,:06,:08,:10,:12,:14,:16,:18,:20,:22,:24,:27,:29,:31,:33,:35,:37,:39,:41,:43,:45,:47,:49,:51,:53,:55,HS 9998端口写入HS单线程顺序揑入100W数据到InnoDB表innodb_adaptive_flushing_method=estimate1400012000100008000,6000400020000,TPS,时间对比 3306 InnoDB单表单线程写入100w数据消耗时间 time./mysql_perl.pl real 2m34.074s user 0m9.796s,sys,0m2.363s,9998 HS 端口 写入100w数据 单线程 time./insert_hs.pl real 1m26.516s user 0m20.445s,sys,0m31.359s,HS使用小结,分库分表的时候，如果表带有auto_increment的id，并収写入的时,候，会导致hs plugin处理自增字段出错,HS会一直拿住表锁，DDL会被堵塞，要想HS释放表锁，还得通过app,控制,某系统 的4台hs 凌晨4点多出现swap非常严重的情况，还导致的mysql,重启，原因是Java应用没有重用table cache,HandlerSocket思路是有价值的，但还需要时间去完善,HS小结二,简单的CURD语句,绕开了MySQL的SQL解析层,简单的事情用简单的工具来做 性能.性能.性能.适用场景,高幵发读,数据安全性丌太重要的场景 预热数据库,Percona VS MySQL,About Percona,About Percona,About Percona,Percona Server is an enhanced drop-in replacement for MySQL.,Percona Server 是MySQL的增强版的替代品,With Percona Server,Your queries will run faster and more consistently.You will consolidate servers on powerful hardware.You will delay sharding,or avoid it entirely.You will save money on hosting fees and power.You will spend less time tuning and administering.You will achieve higher uptime.,You will troubleshoot without guesswork.,Percona5.5.8 VS MySQL 5.5.8,Percona5.5.8 VSMySQL5.5.8,Percona5.5.8 VSMySQL5.5.8,Percona5.5.8 VSMySQL5.5.8,Percona5.5.18 Group Commit,5.5.18开始实现了Binary Group Commit的特性，在数据安全级别更高,的情况下，提供了更高的性能 测试数据集合大小约125G,测试SQL为全量数据中，随机读取。每条SQL按主键查询戒操作。混合,是比率Select:update:insert=10:1:,Supersmack,sync_binlog=1 innodb_flush_log_at_trx_commit=1,UPDATE,INSERT,混合场景,我们用了哪些Percona的相关产品,Xtrabackup,Percona Toolkit 2.0.1,ioprofile tcprstat,pt-collect and others,Percona5.5.18 webww，2012Q1 UIC 集群,更详细的日志信息,更详细的slowlog信息,Group commit(提升TPS)And others,性能/瓶颈/问题,新方案,难免遇到问题,Percona5.5 kernel_mutex问题,Objdump t 确讣是否有符号信息,Oprofile(MySQL编译加-g参数)Systemtap(kernel-debuginfo),gdb+poorman(丌建议在线上使用)Pstack(丌建议在线上使用),Tcprstat(计算DB端的平均响应时间)perf top(redhat 6u+2.6.32 kernel自带),MySQL新技术在淘宝的使用,谢谢大家,