大数据量下mysql实践

大数据mysql实践杨青2015.7.18内容如何保证数据库可用性？

解决思路--数据冗余（复制）如何提高数据库读性能？三种方式提高读性能如何保证数据一致性？主从一致性、数据库与缓存一致性数据库如何扩展？

n库变2n库、增加字段、数据库迁移数据库拆库四中场景单key、1对多、多对多、单key分库后业务的查询如何保证数据库可用性？可用性，数据冗余（复制）1，保证“读”高可用的方法：复制从库，冗余数据，如图：带来的问题：主从数据不一致，主从延迟解决方案：a)忽略错误后，继续同步b)重新做主从，完全同步

2，保证“写”高可用方法：双主模式，即复制主库，冗余数据，如图：带来的问题：双主同步key冲突，引发数据不一致解决方案：a）方案一：由业务层保证key在两个主上不冲突b）方案二：数据库自增id奇偶数3，双主当主从用，不做读写分离，在主库挂掉的情况下，从库当主库顶上，如图：优点：读写都到主，解决了一致性问题；双主当主从用，解决了可用性问题带来的问题：如何提高读性能？

如何提高数据库读性能？一，建立索引建立非常多的索引，副作用是：a）降低了写性能b）内存空间有限，索引占用大量内存，其内存中数据减少，查询数据命中率降低，查询时扫描磁盘，IO增多；但是否想到，不同的库可以建立不同的索引呢？如图不同的库可以建立不同索引，主库只提供写，不建立索引二，增加从库这种方法会引发主从不一致问题，从库越多，主从时延越长，数据不一致问题越严重解决办法：如上所述如何提高数据库读性能？三，增加缓存传统缓存的用法是：a）写请求时，先淘汰缓存，再写数据库；b）读请求时，先读缓存，缓存命中则返回，失败则读数据库并将数据入缓存；

带来的问题：a）所有业务层都要关注缓存，“主从”数据不一致，造成缓存脏数据问题；b）数据复制引发一致性问题，由于主从延时的存在，可能引发缓存与数据库数据不一致；

解决思路：a）增加服务端缓存，如图好处是：1）引入服务层屏蔽“数据库+缓存”2）不做读写分离，读写都到主的模式，不会引发不一致b）不做读写分离，读写都到主的模式，不会引发不一致如何保证数据一致性？一，主从不一致解决方案方案一：引入中间件，如图中间件将写数据路由到主，在一定时间范围内（主从同步完成），该数据上的读也路由到主；方案二：读写都到主，不做读写分离，不会不一致，如图二，数据库与缓存不一致解决方案：两次淘汰异常数据的读写，导致旧数据写入缓存，一次淘汰不够，要进行二次淘汰a）写请求时，先淘汰缓存，再写数据库，额外增加一个定时机制，一定时间（主从同步完成）后再次淘汰；b）读请求时，先读缓存，命中返回，失败则读数据库并将数据入缓存（此时可能旧数据入缓存，但会被二次淘汰淘汰掉，最终不会引发不一致）数据库扩展--数据库n库变2n库？需求：原来N个库，现在要扩充为2N个库，希望不影响服务，快速完成数据库扩展最开始，分为2个库，分别0库和1库，均采用“双主当主从用”的模式保证可用性，如图：接下来，将从库提升主库，并修改服务端配置，快速完成数据库扩库，由于是2扩4，不会存在数据迁移，原来的0库变为0库+2库，原来的1库变为1库和3库，如图：最后，解除旧的双主同步（0库和2库不会数据冲突），为了保证可用性增加新的双主同步，并删除掉多余的数据这种方案可以秒级完成N库到2N库的扩容。存在的问题：只能完成N库扩2N库的扩容（不需要数据迁移），非通用扩容方案（例如3库扩4库就无法完成）扩展后均采用“双主当主从用”的模式，如图：数据库扩展--增加字段、数据迁移、增加索引一，追日志方案a）记录写日志b）倒库c）倒库完毕d）追日志e）追日志完毕+数据校验f）切库二，双写方案a）服务双写b）倒库c）倒库完毕+数据校验d）切库mysql5.6版本Innodb存储引擎实现OnlineDDL原理：将DML操作日志写到一个缓存中，待完成索引创建后再将数据写到数据表上，达到数据的一致性Facebook的OnlineSchemaChange原理：1,创建需要实行alter操作的临时表，然后再临时表中更改表结构；2，在源表上创建触发器(3个)分别对应insert、update、delete操作；3，从源表拷贝数据导临时表，拷贝过程中对源表进行的写操作都会更新到新建的临时表；4，rename源表，把临时表改为源表，将源表删除，触发器删除数据库拆库

四类场景覆盖99%拆库业务a）“单key”--用户库如何拆分：user(uid,xxxx)b）“1对多”--帖子库如何拆分：tiezi(tid,uid,xxxx)c）“多对多”--好友库如何拆分：friend(uid,friend_uid,xxxx)d）“多key”--订单库如何拆分：order(oid,buyer_id,seller_id,xxxx)1，“单key”--用户库如何拆分？用户库，10亿数据量user(uid,uname,passwd,age,sex,create_time);业务需求如下:a）1%登录请求=>whereuname=xxxandpasswd=xxxb）99%查询请求=>whereuid=xxx结论：“单key”使用“单key”拆库2，“1对多”--帖子库如何拆分？帖子库，15亿数据量tiezi(tid,uid,title,content,time);业务需求如下:a）查询帖子详情（90%请求）select*fromtieziwheretid=xxxb）查询用户所有发帖（10%请求）select*fromtieziwhereuid=xxx结论：“1对多”使用“1”分库，如帖子库1个uid对应多个tid，使用uid分库，tid生成时加入分库标记数据库拆库3，“多对多”--好友库如何拆分？好友库，1亿数据量friend(uid,friend_uid,nick,memo,xxxx);业务需求如下:a）查询我的好友（50%请求）selectfriend_uidfromfriendwhereuid=xxxxb）查询加我为好友的用户（50%请求）selectuidfromfriendwherefriend_uid=xxxx结论：“多对多”，使用数据冗余方案，多份数据使用多种分库手段4，“多key”--帖子库如何拆分订单库，10亿数据量order(oid,buyer_id,seller_id,order_info,xxxx);业务需求如下a）查询订单信息（80%请求）select*fromorderwhereoid=xxxxb）查询我买的东东（19%请求）select*fromorderwherebuyer_id=xxxxc）查询我卖出的东东（1%请求）select*fromorderwhereseller_id=xxxx结论：“多key”一般有两种方案a）方案一，使用2和3综合的方案b）方案二，1%的请求采用多库查询分库后业务查询分库后出现的问题：单库时mysql的sql功能不再支持了1，海量数据下，禁止以下方法a）各种联合查询b）子查询c）触发器d）用户自定义函数e）“事务”都用的很少2，分库后，in查询如何查？用户库如何进行uid的in查询user(uid,uname,passwd,age,sex,photo,create_time,...);partitionkey：uid查询需求：in查询：whereuidin(1,2,3,4,5,6)解决方案：服务做uid处理方案一：直接分发方案二：拼装成不同sql，定位不同的库分库后业务查询3，分库后，非partitionkey的查询如何查？方案一：业务方不关心数据来自哪个库，可以只定位一个库例如：有头像的用户查询，如图:方案二：结果集只有一条数据，业务层做分发，只有一条记录返回就返回结果例如：用户登录时，使用username和passwd的查询询，如图:4，分库后，夸库分页如何查？问题：orderbyxxxoffsetxxxlimitxxxa）按时间排序b）每页100条记录c）取第100页的记录单机方案orderbytimeoffset10000limit100分库后传统解决方案，查询改写+内存排序a）orderbytimeoffset0limit10000+100b）对20200条记录进行排序c）返回第10000至10100条记录分库后业务查询优化方案一：a）技术上，引入特殊id，作为查询条件b）业务上，尽量禁止跨页查询单库情况a）第一页，直接查b）得到第一页的max(id)=123（一般是最后一条记录）c）第二页，带上id>123查询：WHEREid>123LIMIT100多库情况a）将whereid>888limit100分发b）将300条结果排序c）返回前100条优点：避免了全局排序，只对小量记录进行排序分库后业务查询优化方案二：模糊查询a）业务上：禁止查询XX页之后的数据b）业务上：允许模糊返回=>第100页数据的精确性真这么重要么？优化方案三：查询改写与两段查询需求：orderbyxoffset10000limit4;如何在分库下实现（假设分3库）步骤一、查询改写：orderbyxoffset3333limit4[4,7,9,10]<=1库返回[3,5,6,7]<=2库返回[6,8,9,11]<=3库返回步骤二、找到步骤一返回的min和max，即3和11步骤三、通过min和max二次查询：orderbyxwherexbetween3and11[3,4,7,9,10]<=1库返回，4在1库offset是3333，于是3在1库