征信上报系统的渐进思路

公司最近在研究怎么将CMS 系统中的征信上报的功能，拆分出来。原来的系统在ORACLE 数据库中，每次需要通过存储过程进行数据的生成在同步到征信上报系统中。

一开始的想法是从CMS 系统中同步数据到中间库，然后在中间库中生成要上报的数据，在同步到征信上报系统中。

问题是数据怎么同步的问题？？？

CMS 系统中的部分表是没有时间戳的，所以要同步数据到任何的数据库可能都存在着全量同步的问题，而几十万每天的同步量，对于ORACLE 到 MYSQL 其实还好，调大MYSQL的change buffer ，关键的问题是每台都要同步重复的数据，这感觉的确是不太美好。

其实无论什么技术，是ORACLE 到 MYSQL ，ORACLE 到 MONGODB ，ORACLE 到 PG ，whatever, 都是属于技术的范畴，跳不出整体数据同步的思维，估计这事不好处理。

如何打破框架，将技术的问题，提升？？？

需要考虑的几个问题

1 ， 合同相对于其他数据是稳定的，也就是说合同不必要每次都要同步，将当前的合同全量同步到中间库中，那不是难事，后期只需要添加增量的合同数就好了，那数量级直线的下降。

2， 需要上报的数据，需要上报的数据无法是还贷逾期，还贷结清，还贷正常这三点。继续分析，那个数据量最大，当然是正常还贷的数据量最大了，而利用排除法，逾期的，和还贷结清的（无论是提前结清还是正常结清都算在内），这些人终归是少数的。

通过上面两点我们能归纳出点什么 ？？？

1  合同的数量没必要每台全量

2  上报的数据不需要全量，我只需要知道哪些人逾期了，哪些人结清了，根据粗略的统计，超不过千人每天。

那剩下的大量的人都是正常的，那正常的数据我们没有必要进行数据的同步，只需要计算出来就可以。

当然一个程序的设计从初步了解需求，到后续详细了解需求，最终产生一个结果，中间的道路很可能是曲折的，但至少这样的想法，打破了数据必须进行大量全量同步的魔咒。