分库分表项目方案总结

环境信息

基于Java语言、Mysql数据库、Quartz任务调度。

本次分库分表的目的

问题现状

    随着业务的发展，ERP系统需求越来越广，系统界面、表结构、业务逻辑越来越复杂，报表查询的逻辑也越发的复杂，随着时间的推移数据量也逐渐飙升。随之引发了2个重要问题：

    性能差：通常一个报表所需的数据源，来自各种业务场景所定义的数据表，过滤条件也越发的复杂，数据量也巨大。这使得报表的性能骤降。一个报表查询通常要耗费几分钟，甚至几十分钟。

维护难：随着数据量逐年增加，数据库文件越来越大；对于日常的维护工作：备份、迁移、修复索引、分表等等；这些维护操作会越来越耗时；运维人员常常要夜里避开系统正常使用时间，才能维护此数据库。

解决方案

将经营业务数据分离至分析数据库（动态数据库），用于存储日常经营数据。通过调度任务将动态的经营数据调出业务库，经过一定的数据组织，传入专用的动态数据库（经营业务数据库）。

其他方案

分区表（与本方案不冲突，可选择一种进行实施，也可以结合使用）

总体流程

 

采用调度任务将日常经营的业务数据迁移至独立的数据库中。

数据流程

 

大致步骤

1. 根据系统配置参数，将数据按“年度、季度、月、周、日”建立分表；
2. 拆分建立相应的数据索引表；
3. 将业务库中的数据迁移至新库中，保存为一套源数据表，定义为ODS层，并同时保存一套维表数据；（这一步为了数据的实时性，后期改为用Flink cdc处理）
4. 将ODS层的数据，进行清洗打宽，保存为一套DW层数据；
5. 将DW层内的数据根据业务需求进行数据聚合汇总处理，保存为一套DM层数据；
6. 报表、分析视图、数据分析等业务，直接从分析库中的DM层拿数据。

备注：这里的ODS层、DW层、DM层，是参考了大数据分层架构的思想；由于数据本身是在关系型数据库中存储，所以在数据量大的表上进行了水平拆分。

重点

• 从根本上杜绝业务系统繁琐的join操作，已提高数据查询性能；
• 分表任务交于调度框架执行，必须选择一种可以高可用的框架，已保证方案的正常运行。（本项目目前采用Quartz）；
• 拆分后，可能存在部分业务需要跨库查询，可采用一些开源的框架进行此操作（比如MyCat、Cobar 等，本项目采用自研的框架）。

业务库中的数据保存期限

 

只保留3天的冗余数据在原库中（业务库），保证业务系统正常的使用。

方案的优点

对于业务系统和业务数据库：

• 数据量可控，存储空间不会随时间的推移无限制增长；
• 业务系统性能因为时间的推移而下降；
• 对于业务数据库的维护，不会因为时间的推移而变得困难。

对于新的分析数据库（动态数据库）

• 动态数据库数据按需存储，避免了大量的连接查询，大幅度提高了查询效率，提升了系统的性能；
• 对“动态数据库” 的操作维护，不会影响正常的“业务数据库” 和业务系统；

后期此数据库可以作为数据分析的数据来源，对此库的数据做大数据的分析，也可以很好的避免对“业务数据库”的影响，避免影响业务系统的正常使用。