且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

记一次数据同步需求的改进(一)

更新时间:2022-09-02 10:05:54

最近有个需求,开发的同事找到我,提出了下面的需求
由于平台业务发展需要,需要将test_account_log 和test_protect_log 表前一天的增量同步到新增的两张表上
对于这个需求看起来还是蛮简单的。自己结合这两张报的设计方式发现没那么简单。
首先对这两个表做了分库分表,从图中可以看到,其实分成了4个库,16个用户,每个用户按照业务逻辑保存了一部分的明细数据,从目前的数据量来看,累计数据还不算大。
记一次数据同步需求的改进(一)记一次数据同步需求的改进(一)记一次数据同步需求的改进(一)
如果按照开发的需求,需要抽取保留前一天的增量数据,这个需求还是需要好好斟酌的。
因为是评估,还是要做一些工作的,不能凭空来想决定可不可行,
首先来抓取了
我抓取了部分用户下表中数据的增长情况,这个过程还是在备库完成,基本每天的数据变化频率不高,下面是test_account_log的数据情况,test_protect_log的频率要更低一些。
2015-10-05       7487
2015-10-06       8140
2015-10-07       8436
2015-10-08       7763
2015-10-09      13933
2015-10-10      15391
2015-10-11       9357
2015-10-12       7680
2015-10-13       5575
2015-10-14       5427
2015-10-15       5697
2015-10-16       6095
2015-10-17       7370
2015-10-18       6869
2015-10-19       5634
2015-10-20       5562
2015-10-21       4900
2015-10-22        694
可以看出每天的数据变更其实不大,10多个累计起来就几万,还是比较小的,从增量数据的情况来看,还是很容易能够实现的。
如果每天的都在百万,千万,那就需要进一步评估确认了。
于是我提了下面几个问题,把这些问题的责任人都指定,谁来负责确认哪些都标明,因为这个还是需要协同来完成。
1.提供增量抽取sql语句   --开发同学
请从业务上评估,提供增量抽取sql语句。
    取昨天的增量:
后续得到开发同学的反馈,发现这个operation_date字段上没有相关的索引,也就意味着这种抽取还是会有潜在的风险。
select * from test_account_log where operation_date>=to_date(‘2015-10-25’,’yyyy-mm-dd’) and operation_date=to_date(‘2015-10-25’,’yyyy-mm-dd’) and operation_date<to_date(‘2015-10-26’,’yyyy-mm-dd’)

2. 目前test_account_log,test_protect_log没有operation_date相关的索引,需要创建额外的索引  --开发同学,DBA
因为不存在相关的索引,所以还是需要考虑能够添加索引,如果能够添加,索引列是为多个相关字段还是单单为operation_date
开发同学的反馈,创建索引的语句为:
create index account_log_date on test_account_log (operation_date)
create index protect_log_date on test_protect_log (operation_date)
对这个索引的创建,我需要从历史的sql执行情况来分析是否合适,是否会有潜在的原因导致执行计划的变更。
3.请确认是否operation_date为变化字段,如果这个值发生变化,增量抽取的数据就会有问题。--开发同学
比如 log_id          uid     operation_date
         1              100    2015-10-21 xxxx
如果发生变化
          1             100    2015-10-23 xxxx
在增量抽取的数据中就会存在重复数据(log_id,uid.xxxx)
这一点看似会忽略,但是却是至关重要,因为仅仅根据开发的需求来完成,如果不考虑这种数据变更的影响,那后面就会有非常多的隐患。
得到开发同学的反馈为:
该表的数据都不会变化,只会增加。因为这个表是一个历史数据表,所以里面的数据是不会修改的。

4.汇总后的表放哪儿确认完再讨论,技术上是可以支持的。不过基于安全和后期数据量的情况,还是需要找领导审批   --找主管审批确认
所以一个简单的问题仔细分析之后,还是在于其范围之内,可以很容易就实现的。后续的就是实施的过程了,当然这个过程会有很多的转折点,可能会对这个需求产生更大的影响,甚至推翻需求重来,后续再来解读。
</to_date(‘2015-10-26’,’yyyy-mm-dd’)