十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章主要讲解了“怎么理解MyCAT中的DDL”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“怎么理解MyCAT中的DDL”吧!
创新互联建站"三网合一"的企业建站思路。企业可建设拥有电脑版、微信版、手机版的企业网站。实现跨屏营销,产品发布一步更新,电脑网络+移动网络一网打尽,满足企业的营销需求!创新互联建站具备承接各种类型的成都网站设计、成都网站建设、外贸网站建设项目的能力。经过10余年的努力的开拓,为不同行业的企事业单位提供了优质的服务,并获得了客户的一致好评。今天开发同学提了一个需求,是希望对某一个时间范围的表做DDL操作,看起来好像复杂度也不高。
但是我一看开发同学提供的信息时就有点犹豫了,因为端口是8066,也就意味着使用了中间件。这是一套MyCAT的环境,一共有4个节点,每个节点拆分成了4个逻辑节点,所以有16个sharding分片,正是应了那句话:百库十表。虽然目前看起来节点数也不多,但是看看这个表hisrecord的分片逻辑就会发现,远远比我们想的要更丰富一些。
这个表是按照日期来存储数据的,即数据的存储单位是日。表名类似于rec20180301,rec20180302这种。所以按照这种增长的趋势,可以根据时间维度不断扩展,同时又对每天的表做了细粒度的拆分,每个日表会有16个分片做hashl路由。
开发同学的需求是对某一天之后的日表添加字段,变更第一天的数据需要对该字段添加默认值,之后的就不需要默认值了,这个从业务的角度来说,是因为应用层升级,需要这个属性,如果有些业务暂时还没有迁移过来,有一天的时间来缓冲调整修复。所以目前的需求的福利就是我们要修改的表目前没有写入,做变更不用考虑在线业务的写入影响。
我简单算了下,按照目前的修改幅度,影响的日表有177个。
mysql> select datediff('2018-11-01','2018-05-08');
+-------------------------------------+
| datediff('2018-11-01','2018-05-08') |
+-------------------------------------+
| 177 |
+-------------------------------------+
1 row in set (0.00 sec)
按照16个分片来算,这个数量就相当大了,有2800多张表。
mysql> select 177*16;
+--------+
| 177*16 |
+--------+
| 2832 |
+--------+
1 row in set (0.00 sec)
涉及的DDL表有2个,即2个DDL语句,所以算下来就是5600多张表了。所以你看一张表就能拆分成2000多张表,一年有差不多5800张相关的表。
如果在这个基础上考虑当天的表结构变更,那就更复杂了。
我们来简单看下MyCAT里面的schema.xml配置。
里面配置了16个分片,即dn50-dn65,database是histrecord01-histrecord16
。。。
对表的分片规则是按照hash取模来计算的。
要做这个工作,手工完成的可能性太低,所以准备了如下的脚本,借鉴了之前同事的一些思路。
我们输入两个时间,即起始时间,终止时间。app_sql/create_sql.sql是表结构的定义文件。这个脚本的意义在于不断的处理表结构信息,打上时间戳,写入另外一个脚本文件,按照日期循环100天,就写入100次。
startdate=`date -d "20180508" +%Y%m%d`
enddate=`date -d "20181101" +%Y%m%d`
#定义循环主函数
function main(){
while [[ ${startdate} < ${enddate} ]]
do
echo ${startdate}
cat /home/mysql/app_sql/create_sql.sql >> /home/mysql/app_sql/alter_his_record.sql
sed -i "s/20180508/${startdate}/g" /home/mysql/app_sql/alter_his_record.sql
echo "" >> /home/mysql/app_sql/alter_his_record.sql
echo
startdate=`date -d "+1 day ${startdate}" +%Y%m%d`
done
}
#执行主函数
main
所以很快就完成了上述的基本操作。当然MyCAT端是不支持DDL语句的。所以我们需要在每个节点上单独去执行相应的变更DDL。
根据得到的脚本略作改动,就可以分发到不同的sharding节点侧了。整个过程持续了不到半个小时,很多时间都是在不断的确认中,因为这个变更的影响范围确实有点大。
当然这个问题的前提是我们已经创建好了日表,如果没有日表的话,我们还是需要重新配置一下,然后在MyCAT端reload一些配置。
把这个任务扩展一下,就会发现,中间件层面的数据处理更侧重于TP业务,而且是插入密集型的业务,如果是节点间的交互分布式,那这个方案就不大适合了。同时不断的拆分从业务的角度来说,历史数据的归档保留和数据的聚合需求还是有的。可能在这个时候中间件层面的支持就很有限了,我们在一定程度上可能需要其他的解决方案。
感谢各位的阅读,以上就是“怎么理解MyCAT中的DDL”的内容了,经过本文的学习后,相信大家对怎么理解MyCAT中的DDL这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!