商城商品历史数据处理

[chenyinle]

商品表ENT_PRODUCT、ENT_PRODUCT_ITEM作为商城最重要的数据表，涉及到的业务关联到的数据表比较多，而且数据规模相对较大，大约800万左右，而旧的（删除状态）的商品数据占了接近300万。所以，需要对目前的旧数据进行定期清理，清理了这部分数据对系统性能有一定的提升。

[chenyinle]

此任务分为4个阶段：

1、分析

为保证系统数据一致性，把商品表旧数据清理的同时，需要把其他的关联到的表的数据同时做处理。

这个分析的过程，需要非常的仔细和耐心，包括业务的查找、影响性评估等等。

具体的，需要把关联的数据表找出来，并且，关联的字段、数据统计影响、查询影响等，做成xls形式展现出来。

2、如何实现

繁琐的分析过程完成。实现时，这里有两种方式：效率高风险高的，效率低风险低的。

a、效率高风险高的方式，商品主表数据先清掉，相关的表的不存在关联关系的数据，随后清理。

譬如：
主表清理：delete from ent_product_item where status=5 and last_update_date<sysdate-interval '30' day
不存在关联关系的数据：delete from ENT_COMPANY_PRODUCT_COUNTER where not exists(select 1 from ent_product_item item where item.company_product_id=company_product_id)
..
此方式比较粗粒度，大概14个需处理的表，那么大概分为14个删除操作，大事务也不好处理，只能分为例如每个表一个事务，每个操作的耦合太低（不能保证各个表数据清理的一致性）。处理的相对较快，整个过程只需2、3个小时可完成，毕竟执行过程跨度太大，期间就造成了数据的不一致（虽然是维持2、3个小时），而且负载较高。

b、效率低风险低的方式，先保存到归档表，再清理数据。以商品主表数据作为标准，每处理一条商品数据，同时处理掉关联的表的数据。

譬如：
保存到归档表
em.createNativeQuery(tmp.get("saveSql"))
删除原来的数据
em.createNativeQuery(tmp.get("delSql"))

这样将过程细粒化了，并且每处理100条商品数据开一个小事务处理。处理100条（包含关联的表）作为一个原子操作，保证了数据的一致性要求。这种方式风险较低，但效率很慢，每处理10000条数据，耗时两个多小时，而负载不高。

最后，考虑了风险问题，采用第二种方式，配好定时任务，让它慢慢删，慢慢删。

3、测试

测试，包括负载的测试，系统其他业务测试（是否影响到，是否出错），数据的一致性检查，最后，放到线上进行少量数据处理（当然这时已经有相当把握的），看看是否有异常，没有异常就可以尝试处理多点数据，再看看是否依然良好。

4、上线

测试完成，再三评估风险，定好合适的时间段执行，把定时任务放上去服务器。

注：

此任务涉及的数据表，在附件里面有详细描述。

此类型任务，需要步步惊心，前提是前期的关联数据的分析，而关键是评估执行之前之前的工作（要不要DBA先备份数据？是否放在闲时操作？是否要先清空缓存？如何做风险处理？是回滚还是咋的？）、执行过程中的风险（负载、数据一致性）、执行后的风险（如缓存导致的问题）。

[chenyinle]

由于DBA监控到数据库的负载比较高，经开会讨论，决定找个空闲的时间，按照a的粗粒度方式（商品主表数据先清掉，相关的表的不存在关联关系的数据，随后清理），一次过清理这部分数据，已达到降低负载的效果。

清理过程会有不确定性，so，这些清理脚本(见附件sql.txt)交由DBA来处理。