郑州建站系统在线咨询,尼乐清网站建设,短视频运营岗位职责,常见的网站名称有哪些到数据归档#xff0c;很多人的第一个概念就是#xff0c;不就是无用的数据#xff0c;换个地方放吗#xff0c;直接拷贝#xff0c;删除不就得了#xff0c;有那么麻烦。我见到过的#xff0c;听到过的数据库归档的方法有以下几种1 数据通过人工的手段来进行清理… 到数据归档很多人的第一个概念就是不就是无用的数据换个地方放吗直接拷贝删除不就得了有那么麻烦。我见到过的听到过的数据库归档的方法有以下几种1 数据通过人工的手段来进行清理直接将表换名字然后在重建一个新的表承接数据。首先这样的做法一个字快这是这样做法的好处所在但另一方面要考虑的问题就是业务要不要停涉及的人有多少如果光是IT 的还好说但恰恰这样做绝对不会光光牵扯 IT 业务的人一定是要牵扯进来然后就是各种流程和通知要在几点几点某个业务甚至整体业务暂时停止。2 数据通过MYSQL dump 或者其他的备份方式将数据备份出来在将数据恢复到数据归档库中然后将备份的数据直接手动清理掉这样的做法速度也很快对业务的影响也比较小基本上可以算是透明的方式了但还是避免不了人工的介入并且也不可能是天天这样做。3 数据通过工具的方式来进行处理例如pt-archiver 的方式来进行数据的归档和清理但这个工具貌似bug不少pt-11264 自己设计数据归档自己设计数据归档的面就广了有使用程序来做的例如JAVA Python等等也有使用存储过程来进行的。下面就是一个MYSQL 针对一个数据库表归档的案例(这个案例也是有缺陷的但目前是秉承着够用就好以及时间成本的原则)首先设计一个归档要考虑的问题如下1 归档表的大小以及每日最大或最小的归档数据量或者数据过期时间 同时归档表是否必须是全量的数据归档还是可以抛弃一些数据例如有一些日志的归档中可能存在一些无用的数据是否还必须全量的归档等等都是要考虑的问题归档数据并不一定是原封不动的归档有的逻辑上只归档一些数据关键点也是可以的。2 归档的数据量数据归档一般根据上面的东西归档有一次性归档和规律有固定日期的归档一次性的归档一般归档的数据量比较大而有规律的归档则归档的数据量并不大对比两者的方式其实定期归档(有规律)的要有优势一些主要是数据是不断灌入的而数据的归档如果也是不断输出的这样整体这个表的数据量就会有一个平衡不会一下子少了很多要不就是在清理的前一天数据量已经大到一定的水平有可能影响性能。3 归档的方法自己定义数据的归档方面可以每次归档将数据灌入一个表也可以定期的将数据写入不同的归档表例如已归档日期和后缀的方式来将每次写入的数据进行分割或者建立分区表的方式来进行归档。4 归档的方式是否灵活有的归档的方法仅仅针对一个表来进行归档有的方法是可以灵活配置可以任意扩展。那就都任意扩展灵活配置不就好了其实随着能任意扩展或者灵活配置则工作量就会变大这也要考虑一个性价比具体要考虑表的数量以及归档的方式。下面就是一个简单的例子需求是一张表每天数据量在40- 50 万主要都是来自于客户的短信以及消息发送的内容。表中的数据要保留半年之内的其余的数据可以移走。以下以最简单的自动化的方案来讲下图是基于案例来讲的因为数据库是MYSQL 所以考虑了归档一次是多大的批量避免归档数据量过大的时候将生产库hang 死另外配置表主要的功能是有两个 1 限制一次拷贝和清理的数据量2 控制拷贝过期数据的日期限制下面是这段代码如果看的不方便下面有截图DELIMITER $$DROP PROCEDURE IF EXISTS archive_data;create PROCEDURE archive_data()BEGIN declare row_s int; #最大执行多少次每次1000条 declare save_month tinyint; #保留多少月之前的数据 declare times int; #执行次数记录 declare min_row_s int; # 当前数据库最小的tid declare archive_date datetime; select times : 1; #设置每天初始清理次数初始值 select row_s : max_row_clean from db_archive.db_config order by id limit 1; #获取当前配置库数据 select save_month : archive_save_date from db_archive.db_config order by id limit 1; select min_row_s : min(tid) from msgcdb.t_sms_message; #获取当前系统最小的TID号 select max_row_s : max(tid) from msgcdb.t_sms_message; #获取当前系统最大的TID号 select archive_date : DATE_SUB(CURDATE(), INTERVAL save_month MONTH); select row_s, save_month,archive_date,min_row_s,max_row_s; if min_row_s max_row_s then set times row_s 1; elseif min_row_s is null then set times row_s 1; end if; insert into db_archive.archive_log (save_month,times,min_row_s,max_row_s,archive_date,row_s,insert_time,delete_time,type_s) values (save_month,times,min_row_s,max_row_s,archive_date,row_s,sysdate(),sysdate(),initial); select times, min_row_s; while times row_s DO begin insert into db_archive.t_sms_message (tid,summary_id,uid,code,channel,batch_id,done_time,phone,sms_content,create_time,send_time,storage_time,status,estimatedTime,operate_type,origin,creator_id ,dept_id,del_flag,priority,template_id,repetitions_num) select tid,summary_id,uid,code,channel,batch_id,done_time,phone,sms_content,create_time,send_time,storage_time,status,estimatedTime,operate_type,origin,creator_id ,dept_id,del_flag,priority,template_id,repetitions_num from msgcdb.t_sms_message where tid min_row_s and tid min_row_s 1000 and status 0 and storage_time archive_date; set times times 1; insert into db_archive.archive_log (save_month,times,min_row_s,max_row_s,archive_date,row_s,insert_time,delete_time,type_s) values (save_month,times,min_row_s,max_row_s,archive_date,row_s,sysdate(),sysdate(),inserted); delete from msgcdb.t_sms_message where tid min_row_s and tid min_row_s 1000 and status 0 and storage_time archive_date; insert into db_archive.archive_log (save_month,times,min_row_s,max_row_s,archive_date,row_s,insert_time,delete_time,type_s) values (save_month,times,min_row_s,max_row_s,archive_date,row_s,sysdate(),sysdate(),deleted); select min_row_s,max_row_s; select min_row_s : min(tid) from msgcdb.t_sms_message; select max_row_s : max(tid) from msgcdb.t_sms_message; select min_row_s,max_row_s; if min_row_s max_row_s then set times row_s 1; elseif min_row_s is null then set times row_s 1; end if; end; END WHILE;END$$DELIMITER ;配置表归档日志表为什么要这么设计其实寻根溯源有两点1 简单有效够用原则2 设计配置表的主要原因是对于非IT 人员例如project manager 或者其他的人员也可以调整归档的时间例如 archive_save_date 的数字就是保留多少月的数据max_row_clean就是当前的数字 *1000 就是每天最大的归档数据量。通过这两个参数双重限制每天的归档的数据量避免归档的时间太长影响了备份或其他操作。而日志表本身就是一个查看归档成功失败的东西其中的type_s 就是表现数据归档操作状态的东西通过日志表可以反映归档多少数据每次操作消耗的时间以及当前操作获取的系统变量是什么方便出现故障时查看到底归档的数据少不少或者大致可能出现问题。下面是这两个表的结构这样归档有没有缺点当然有缺点马上就可以说出几个1 为什么还要在本地机归档数据不应该是传送到其他机器上吗2 为什么不设置每次归档的数量限制(每次限制操作的行数)这对MYSQL不是很用吗为什么要写死。3 为什么要用MYSQL 存储过程来做使用python不是更灵活其实一言难尽都和需求有关所以很多设计出来的东西外人一看一堆毛病如果你进入到他的内部一段时间估计你就懂得为什么会设计出这样或那样的东西。最近有一句话挺时髦资本根本不care你技术不技术除非你做到行业NO.1才有可能翻个身。群里有一些免费书可自取
