文档章节

听云的分库分表实践【转】

强子大叔的码田
 强子大叔的码田
发布于 2016/06/28 09:34
字数 2342
阅读 410
收藏 10

前段时间,Oracle官方发布了MySQL 5.7的GA版本。新版本中实现了真正意义的并行复制(基于Group Commit的Group Replication),而不再是基于schema的并行复制。这一特性极大的改善了特定场景下的主从复制延迟过高的状况。随着MySQL成熟度的提升,越来越多的用户选择使用MySQL存放自家的数据,其中不乏使用MySQL来存放大量数据的。

在过去的半年多时间里,听云业务量呈爆发式增长,后端的数据量由去年第一季度的几TB增长到几十TB,业务量翻了十几倍。后端应用及数据库面临的一个突出的问题就是频繁的进行扩容来应对前端流量的增长。数据库层面我们使用MySQL来分布式存储业务数据,数据库集群的架构也比较简单,我们使用开源中间件Amoeba来实现数据的拆分和读写分离。Amoeba后端有几百个数据库的节点组,每个节点组中都包含一对主从实例。master实例负责接受write请求,slave负责接受query请求。如下图:

2.23.png 

正确的拆分姿势

随着可选择的开源中间件越来越多,好多数据量并不是很大的使用者都会过早的考虑水平拆分数据库。但其实过早的水平拆分未见得是一件有意义的事情。主要原因有两个:一个方面是水平拆分会对现网的业务造成冲击,如果系统在设计之初就没有考虑过后续要进行拆分的话,这个冲击就会被放大。比如业务中有大量的多表join的查询,或者是对事务有强一致性的要求时,水平拆分就捉襟见肘了。另一方面,如果过早的进行了水平拆分,那么到达一定程度后再想要垂直进行拆分时,代价是很大的。以听云app为例,当我们业务库拆成8个分片后,有一天发现数据增长的很快,于是决定对其进行垂直拆分,将小时纬度和天纬度的数据拆分到一个新的实例上去,这时我们不得不同时部署8个节点组来将现有的8个分片上的小时纬度和天纬度的数据迁移出来。工作量相当大。如果水平拆分到了64个片,那么这时要想再做垂直拆分,保证累的你不要不要的。

所以更合理的路线是这样的,首先对业务数据进行垂直拆分,原本一个库按业务单元垂直拆分成多个库,同时应用中配置多个数据源或者使用中间件来访问拆分后的多个库,对应用本身来说,基本没做什么改动,但是后端存储的容量和性能却翻了好几倍。如果某天出现瓶颈之后,再来考虑水平拆分的事情。

优雅的从n到2n

2.45.png 

水平扩展过程中最让人头疼的是数据的迁移,以上图中迁移mod(mobile_app_id,4)=2的数据为例,最开始的做法是先创建两个新的节点组shared0_new和shared2,拿shared0的全备恢复到shared0_new和shared2,然后在shared0_new上删除mod(mobile_app_id,4)=2的数据,在shared2上删除mod(mobile_app_id,4)=0的数据,删除操作完成后shared0_new、shared2与shared0做同步,同步删除操作执行过程中的数据增量。同步追上之后,切换amoeba的路由规则,然后下线shared0。这种方式问题很多,首先时耗很高很高,delete完了之后并不能释放存储空间,还要optimize table,同样也是一个漫长的过程。针对大表的delete会产生一个很大的transaction,会在系统表空间中申请很大一块undo,delete完成后事务提交。这个undo空间并不会释放,而是直接给其他事务复用,这无疑会浪费很多存储空间。

后来我们想到一个便捷的办法,就是利用mysqldump的—where参数,在备份数据的时候加一个mod(mobile_app_id,4)=2的参数,就可以单独备份出余数为2的数据,然后拿这个逻辑备份恢复到shared2上去,高效且优雅。

数据倾斜

MySQL分布式存储不可避免的一个问题就是数据倾斜。业务在运行一段时间之后,会发现少部分shared数据增量特别快,原因是该shared上面部分用户的数据量较大。对于数据倾斜问题我们目前的措施是将这些shared迁移到1TB存储上来,但这并非长久之计。因此我们目前正在做一些新的尝试,比如对Amoeba做了一下扩展,扩展后的Amoeba支持将某一个mobile_app_id的数据单独指向后端一个shared节点组,即一个shared只存放一个用户的数据,同时采用ToKuDB存储引擎来存储这部分数据,ToKuDB能够对数据进行有效的压缩,除了查询性能稍有损耗之外,基本具备InnoDB引擎所拥有的特点,而且在线表结构变更比InnoDB快好几倍不止。这些测试基本已经进入尾声,很快将会应用到生产环境。

分布式join

分布式join在业界仍没有完美的解决方案,好在听云业务在设计之初就从业务上避免了多表的join,在业务库中,报表中的每个纬度都会有一张表与之对应,因此查询某个纬度直接就会查询后端的某张表,都是在每张表上做一些操作。目前比较流行的分布式join的解决方案主要有两种:

1、全局表的形式。举个例子,A表 join B表,B表分布式存储在多个shared上,如果A表比较小,可以在所有的shared上都存一份A表的全量数据。那么就可以很高效的做join。看起来很美好,但是限制很多,应用的场景也很有限。

2、E-R形式。举个栗子,用户表user(id,name)和订单表order(id,uid,detail),按用户id分片,order表的uid引用自user表的id。存放订单时,首先确定该订单对应用户所在的shared,然后将订单记录插入到用户所在的shared上去,这样检索某个用户所有的订单时,就可以避免跨库join低效的操作。

目前的开源中间件中,MyCat对分布式join处理的是比较细腻的。阿里的DRDS对于分布式join的处理也是这样的思路。

MySQL擅长什么

任何一种工具可能都只是解决某一个领域的问题,肯定不是放之四海而皆准的。正确的使用方式是让工具做自己擅长的事情。关系型数据库擅长的是结构化的查询,本身并不擅长巨量数据的清洗。我们在出2015年度APP行业均值数据报表时,需要将后端所有shared上的相关数据汇总起来然后做进一步的分析,这些数据最终汇总在5张表中,每张表都有几亿条的记录。然后对5、6个字段group by之后取某些指标的 sum值,最初尝试在MySQL中处理这些数据,MySQL实例给出24GB的内存,结果OOM了好几次也没有出结果。最后把数据拉到了hadoop集群上,使用impala引擎来汇总数据,处理最大的表近7亿条记录,9min左右出结果。所以,不要有all  in  one的想法,要让系统中的每个组件做自己擅长的事情。

分布式MySQL架构下的运维

MySQL分布式虽然解决了存储和性能问题,但是在运维支持过程中却带来了一些痛点。

1、跨分片统计数据。中间件是无法对后端的全量数据做查询的,类似年度APP行业均值报表这样的跨分片的全量数据的查询,只能使用自动化脚本从后端逐个shared上提取数据,最终再汇总。

2、DML。经常会有变更表结构的需求,这样的操作大部分中间件是支持不了的,如果只有一个库好说,当后端几十个shared时,就比较头疼了,目前我们并没有很好的处理办法,只能使用自动化脚本批量到后端shared上执行命令,执行完成后,运行一个校验的脚本,人工核对校验脚本的输出内容。

应对这样的情景,发型必然会稍显凌乱,但是目前仍旧很无奈,有必要重新设计一下我们的脚本,写一个输出更加友好,完全自动化的工具出来。

© 著作权归作者所有

强子大叔的码田

强子大叔的码田

粉丝 910
博文 1439
码字总数 1221048
作品 9
南京
架构师
私信 提问
乐视秒杀架构解读:从零开始搭建百万每秒订单系统

在各种秒杀活动大行其道的今天,订单系统的性能与稳定日益重要。乐视集团作为这一技术的佼佼者,在多次的电商狂欢节中都能抢占商机、拔得头筹,其表现无疑为其他企业和厂商提供了非常有价值的...

DBAplus社群
2016/06/15
0
0
浙江移动首个基于阿里云技术的生产应用上线成功

一、项目背景 为落实公司“十三五”战略,建立“架构先进、运营高效、内外兼顾”的IT体系, 浙江移动近日受总部信息技术中心委托和指导,探索传统企业与互联网公司新型合作模式,跟踪行业发展...

阿里云头条
2018/05/11
0
0
每秒处理10万订单支付架构

一、库分表 在redis,memcached等缓存系统盛行的互联网时代,构建一个支撑每秒十万只读的系统并不复杂,无非是通过一致性哈希扩展缓存节点,水平扩展web服务器等。支付系统要处理每秒十万笔订...

rickiyeat
2017/11/09
0
0
PHPer面试指南-MySQL 篇

本书的 GitHub 地址:https://github.com/todayqq/PHPerInterviewGuide 什么是索引,作用是什么?常见索引类型有那些?Mysql 建立索引的原则? 索引是一种特殊的文件,它们包含着对数据表里所...

angkee
2018/01/24
0
0
每秒处理10万订单乐视集团支付架构

声明:本文为CSDN原创投稿文章,未经许可,禁止任何形式的转载。 作者:梁阳鹤,乐视网boss平台技术部架构师,主要负责乐视集团支付,乐视会员系统,商业运营平台等系统架构工作。开源数据访...

chaun
2016/05/11
156
1

没有更多内容

加载失败,请刷新页面

加载更多

kibana汉化

kibana5 / 6 需要下载补丁包,https://github.com/anbai-inc/Kibana_Hanization 其中 v6 版本原生支持国际化,只需要添加资源文件并且配置即可 kibana7 v7版本官方内置汉化资源,在配置文件 ...

细肉云吞
26分钟前
5
0
spring boot 自定义日志 log4j2

使用默认的日志在实际开发中会存在很多问题,比如备份文件名称无法自动重命名、各个等级的日志被放在一个文件中等,所以实际开发中为了更好满足我们的需求,我们一般都会自定义采用配置的方式...

雷开你的门
30分钟前
7
0
PCB设计-Allegro软件入门系列-设计参数配置(上)

前言 经历了导入网表,和放置器件后,我们就要画板子了,但是必要的设计参数也要先准备好,磨刀不误砍柴工。 《一》显示参数 这里主要设置DRC报错标志大小和飞线显示类型 (1)DRC标志可以适当...

demyar
31分钟前
7
0
js实现微博、微信分享

html <!-- 分享 --><div class="share-box"> <b style="vertical-align: middle;">分享到:</b> <a title="分享到新浪微博" class="shareSina"><span class="share-icon"></span><......

张兴华ZHero
47分钟前
7
0
创龙TMS320DM8168浮点DSP C674x + ARM Cortex-A8的CPU、NAND FLASH、NOR FLASH

TL6678-EasyEVM是广州创龙基于SOM-TL6678核心板而研发的一款多核高性能DSP开发板。开发板采用核心板+底板方式,底板采用沉金无铅工艺的四层板设计,尺寸为200mm*106.65mm,它为用户提供了SOM...

Tronlong创龙
50分钟前
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部