对于海量的互联网业务来说，除了线上的数据库，还需要有一套对应的历史数据库，用于查询历史的数据。比如查看历史微博、查看淘宝历史交易。

历史数据库架构

业务会将最新的数据变更插入在线的 MySQL 数据库，但 MySQL 数据库仅保留最近半年的数据，超过半年的数据会存放在历史数据库系统中。对于历史数据库的选型来说，一般可以是（分布式）MySQL 数据库、HBase、ElasticSearch。

• 历史数据库是 MySQL，那么基本和线上架构一致，只是存储的容量会更大。但缺点是，即便使用分布式架构，数据节点的扩容需要搬迁数据，这部分工作相对比较麻烦一些。
• HBase 是 Hadoop 生态的大数据系统，是一个 KV 系统，非常适合进行点查询，其对于数据的扩容也是非常容易。但是它的缺点是不支持事务，没有二级索引，所以在使用时会有诸多限制，比如二级索引需要自己创建索引表，索引表和主表的数据一致性有可能会存在问题。
• ElasticSearch 是文档数据库，其他特性与 HBase 类似，支持数据节点动态的扩缩容，查询支持也更为丰富一些

选型需要结合业务具体分析，通常更倾向于使用 ElasticSearch，简单易用。

迁移系统

迁移系统需要做以下两件事情：

• 将线上数据尽可能地准实时同步到历史数据
• 清理线上数据库系统，仅保留最近一段时间的数据，如半年的数据

DTS 是 Data Transfer Service，数据迁移服务，负责将在线数据准实时地同步到历史数据库。

DTS 的实现原理是订阅 MySQL 的二进制日志变化，将数据库的变更同步到历史数据库。虽然原理并不复杂，但是由于是异构数据库系统，在数据消费这里还需要做不少的工作。此外，要做到准实时要求，如仅 30 秒内的延迟，对于 DTS 也是一种考验。

业界的 DTS 有 Maxwell、Canal。但通常这些 DTS 仅负责订阅二进制日志，消费需要用户自己实现存储到不同的数据库。

DAS 是 Data Archive Service，数据归档服务，负责清理超过一定时间的线上数据，同时需要确保清理的数据都已经在历史数据库中。所以，DAS 又需要做两件事情：

• 获取超过某个阈值的数据，确保这些数据都已经在历史数据库中
• 根据调度，在非业务高峰期，从 MySQL 数据库中删除超过某个阈值的数据

在库表结构设计中，要求每张业务核心表都要有一个最后修改时间的字段，因此那些数据已经超过某一时间点，如半年，是比较容易知道的。然后，再进行线上数据与历史数据库的核对即可。

第二个步骤会真实删除线上数据库中的数据，风险较高，但通过多次数据校验和逻辑判断，DAS 可以确保删除数据的正确性，从而正确删除超过阈值的数据。