业务数据归档方案

业务系统随着上线时间的加长，系统数据增加越来越多，目前普遍采用mysql数据库作为存储设备，数据有几种区分：1、数据有一个时效性，操作完后不会再使用（可能会进行报表统计）2、操作完后，数据不会进行修改操作，只是进行查询 3、数据随时都会进行操作查询。

第一种场景，可以把数据归档到历史库中备份，减轻主应用库的压力。

第二种场景，归档到历史库后，虽然不会进行修改的操作，但是还是会充斥大量的查询操作。随着历史库的数据量逐渐增大，查询压力慢慢的转移到历史库中，如果归档及处理历史库就变得极为重要。此种场景的历史数据只会进行查询操作，可以按照主业务的操作进行分区处理，对于分区的条件选择就变得尤其重要。另外资源允许可以进行分库及分表操作，把不同的数据定位到不同的库表中，可以极大的减轻查询压力。对于分区跟分库分表有各自的优缺点，这儿就不一一列举了。

对于有些数据复杂数据可能需要进行多表关联，查询效率极低，可以考虑冗余一张针对此业务的单表。

第三张场景，没有冷数据，所有数据都有可能进行操作，查询频率一样。针对这些数据前期当然需要进行适当的规划，采用适当的分库分表，具体可以按照不同的业务分库，减轻单个库的压力。再根据业务进行取模分表。如果需要多表关联的数据不建议进行分库分表，此类数据进行多表关联查询效率会很低。可以采用冗余字段冗余表的方式来操作，对于主要的数据进行不同的表设计，带来的副作用就是冗余多份数据。

以上可能主要针对的是关系型数据库的操作，当然可以采用hadoop来做一些数据处理存入Hbase等非关系型数据库，因目前并没有接入到Hbase中的应用所以暂不做讨论。

数据量增大对于数据报表的需求可能压力会很大，此种报表需求接入到hbase当然是一种选择，另外可能利用canal对数据库数据进行再次存储，存储成报表需求的数据结构。

随着大数据时代的来临，数据的价值越来越大，我们应该更好的利用数据来做好分析，售后的业务有太多需要挖掘的地方，分析客户的返修率，退货习惯，返修原因等，加强商品的管理，减少客户返修率等。