数据刷新中的并行改进(r5笔记第72天)

昨天按照计划进行了系统升级，多多少少还是碰到了一些问题。 有一个问题不算紧急，但是也在计划之中需要进行调优和改进。是关于数据的复制刷新的使用。为了更加清楚的描述问题，自己画了下面的一个简单的示意图来说明。 其实真实环境要远远比这个复杂，这是简单说明问题点到为止即可。 这是一个数据字典数据型数据，也算是静态数据，配置数据等的刷新示意图，数据的源头只有一个，数据都在active的一个schema上，其他几个类似的节点都在维护这样一套类似的结构，但是因为节点都是分布式的，所以都分散在不同的机器上，数据的刷新目前是采用物化视图来做的。远程的刷新是通过db link+物化视图来完成的。 对于下层应用来说，还是根据业务规则连接到不同的节点中。

大体的情况就是如此，在生产中进行数据刷新的时候，如果进行并行复制，其实对于主节点还是有很大的压力的。而且目前的刷新情况也是一个串行的方式。 比如我们存在表a,b,c 则在不同的节点中进行刷新的时候，是先刷新a，在各个节点一次刷新，然后刷新b，然后继续刷新c，依次类推。在最后的时候，只需要切换对应的快照schema即可。即上图中红色和蓝色的部分，最后把schema进行切换即可，对于应用来说是透明的，如果数据出现问题进行undo也是很轻松的事情。 所以在采用刷新的时候，也是考虑了主节点中的负载和压力，采用了串行的方式进行刷新，但是一方面保证了压力，但是刷新时间就是一个比较明显的问题了。时间会随着节点的增多而进行指数级增长。 在尽可能不改动逻辑，少改动逻辑的情况进行的调研情况，得知这种数据的刷新频率还是不高的，可能几周才会进行这样的一次刷新，而且在刷新的过程中，对于应用app1来说优先级是比较高的，app1中的刷新完成之后，会有一些业务的预处理，对于app2,app3的数据刷新速度就没有很严格的要求了。慢一些还是可以接受的。 所以的改进思路就是分成两部分来处理，两条腿走路。对于app1优先刷新，而且对于app1中的表进行并行切分。 比如里面有15张表，就可以分成多个并行刷新session来处理。一方面刷新的都是不同的表，不会有之前热点快的争用的情况，而且这个过程完成了就对后续的处理优先级就会大大降低。依赖性就大大降低了。

当然了这个过程还有很多的细节需要考虑，主要的一个思路就是对于近上千张静态数据表进行快速的刷新，有几个要点需要考虑。 一个就是并行切分的把握，因为数据字典表的数据量相对来说不算很大，总体来说分区表还是很少存在的，所以进行并行切分的时候可能直接根据segment的情况就能够得到一个大体的数据分布情况了。 优先刷新app1需要的节点之后，对于后续的节点可以还是保留原有的方式进行刷新即可。 看起来思路还是比较简单的，但是能够使得方案落地还是需要做不少的工作，后续对切分的细节进行分享。