电商项目之如何迁移千万级别的数据表

1 背景

电商系统一般都会有一张表记录买家的浏览器信息,包含但不限于浏览器ip、浏览器cookie信息、浏览器user-agent、当前页面的url、当前页面的refer。买家在电商网站上每一次操作,都会记录到该表。该表的数量量至少达到千万级级别。该表有什么用处?用于给电商系统的B端做数据分析、数据概览展示、报表展示使用的。也能用于挖掘数据价值。做数据统计的查询,千万级的表查询性能极低,因此针对不提升数据库性能的情况下(不增加服务器成本),与业务方协商取得同意,允许保留最近3个月的数据。那么怎么保留最近3个月的数据呢?如何独立地完成这项任务?

2 前言

此博客非面试题,而是真实遇到的场景,如果没接触过这种场景,还真不知道要怎么搞。因为生产环境正在使用着这张千万级的表,不能简单地认为操作navicat将数据导出然后再导入。稍有不慎,就会导致生产级别的故障。

3 解决方案

核心思路:先建表,然后重命名表

假设这张千万级的数据表的名字是t_broswer_page_view,下面也简称为pv表

  1. 先创建一张与pv表结构一样的表,表名随意,此处用t_broswer_page_view_bak
  2. t_browser_page_view表重命名为另一个名字,此处用t_browser_page_view_20230113
  3. t_broswer_page_view_bak重命名为t_broswer_page_view
  4. 根据业务需要,将最近的几天数据从t_browser_page_view_20230113迁移到t_broswer_page_view(因为数据概览的页面一般都会默认展示当天或者最近一周的数据,因此我们首先迁移的是最近7天的数据)。然后将剩下需要保留的数据迁移到t_broswer_page_view

疑问:为什么要先建表然后重命名?而不是先将pv表重命名为t_browser_page_view_20230113,然后直接建表pv表?

如果采用后者,如果建表的SQL出现问题导致建表失败,那么生产环境就会出现长时间该表不可用的情况,会引发生产故障。而采用前者,我们把表建好,剩下的就是只需重命名的操作,重命名的操作只需1秒,即生产环境该表不可用的时间只是1秒而已。因此采用前者的解决方案。

4 注意点

  1. 迁移数据的操作如果需要运维人员执行,最好是提供需要执行的SQL脚本,这样可以减少沟通成本和降低出错概率。
  2. 数据迁移前必须和领导、业务部门达成一致的沟通结果,然后再进行数据迁移,迁移完成后,要及时告知领导以及业务部门,形成闭环。
  3. 数据迁移前,自己必须要有一个优化效果。比如统计迁移前有多少条数据,迁移后有多少条数据,删除了多少条数据(即节省了多少磁盘空间,提升了多少数据库性能,通常可以用百分比描述)。
  4. 迁移完成后,后端开发工程师需要立刻看看迁移后的数据是否正常,每隔若干分钟看看数据的产生是否正常。

你可能感兴趣的:(解决方案,数据库)