随着业务增长，公司数据规模不断膨胀，表变多、变大。一方面占用的磁盘、CPU等物理资源疾速上涨，另一方面大表性能下降且变更困难。实际上，很多大表的数据无需保留很久，比如某些业务可能只需要保存最近1周或最近3个月的数据。
对此类表，可依据业务要求，在线上环境只保留指定天数的数据，其余超出时间范围的过期数据可予以删除。出于某些原因，比如催收、线上业务查冷数据等，从生产环境删除的数据不能直接丢弃，需要存档以备不时之需，所谓归档。
2、数据归档的现状目前拍拍贷主要使用的是MySQL数据库服务，那么我们使用大磁盘容量的机器搭建几套主从结构的MySQL集群，配上高可用机制，将生产环境指定库表、指定时间范围之外且满足其他指定条件的数据按照一定的顺序定期分批导入到这些目标集群，并在每批确认导入成功后对源生产环境的数据予以删除，下批再从上次结束的位点开始导入、删除，如此循环重复，使生产环境表的数据始终维持在指定的时间范围。至于归档目标环境的数据则可以根据公司的要求统一保留指定的时间，比如1年。对于归档目标环境过期的数据可以进行直接删除处理。
3、已知的归档问题上述是一个典型的归档系统需要完成的基本功能和基本的处理流程，如果数据规模不是很大且增幅稳定而且表结构固定，那么上述流程可以很好的运行的。但现实的情况是公司数据规模庞大、数据增长迅速，而且由于业务发生变化等原因，后端的表结构可能需要跟着变化。而且，还需要考虑归档对生产集群正常业务的影响、对主从延迟的影响和DDL的影响等（这部分内容不在本文讨论范围）。
对于表结构变更有两种处理方式：
?“温和型”：在发现源端表结构发生变更后，相应的在目标端的表上执行同样的变更，以确保两端表结构一致数据可以正常写入；?“粗暴型”：一旦发现源端表结构发生了变更，则在目标端轮转一个新表（旧表重命名，然后按源表新的表结构在目标端重建表）以确保源和目标表结构统一。“温和型”的解决方式不仅可以处理表结构不一致的问题，而且也可以避免轮转表导致的数据查询问题，但是，对于MySQL来说，当归档表变得很大的时候，DDL通常会非常耗时。
“粗暴型”的解决方式可以很好的处理结构不一致问题，但如前边所述，一些线上的业务可能需要查询归档环境的冷数据，比如，用户想要查询半年前的订单数据，对于这类表简单粗暴的将其重命名会对业务查询归档数据造成困难；
对于数据规模大、数据增长快这一情况，尽管选用了大磁盘容量的机型来存储归档数据，但因表多且数据量大往往在运行几个月后磁盘空间即被写满。这部分数据因为还没超出指定的有效期，所以还不能从归档目标环境直接清理，而MySQL又不能方便的进行容量扩展，所以只能考虑将现有的归档作业迁移至新的归档目标集群进行归档，而这一迁移也会对需要访问归档环境数据的应用造成影响。
上述问题可简要概括为二个主要痛点：
?快速OnlineDDL；?存储容量；二、方案探索弹性伸缩和快速OnlineDDL不是我们在归档环境遇到的个案问题，其实也是数据库业界普遍会遇到的两个问题，尤其是现如今各类海量数据的大背景下，也因此出现过诸多解决方案。
TiDB分布式数据库集群，它几乎支持前述提到的各个特性同时高度兼容MySQL，这对于我们的业务是非常友好的，但是存在一些问题，比如无法很好的和现有的归档工具兼容，而且太重。
另外比如，TokuDB存储引擎就可以快速安全的处理DDL，而且是作为MySQL插件的方式提供的，所以对于基于MySQL的应用几乎可以不用进行任何改造就可以在TokuDB引擎上运行。而且TokuDB引擎有很高的压缩比，这一点对很多资源敏感型的用户也很具吸引力。
1、TokuDB特性高达25倍的数据压缩
快速插入
使用读取自由复制消除从属延迟
热模式更改
热索引创建-在将索引添加到该表时，TokuDB表支持插入，删-除和查询，没有停机时间
热列添加，删除，扩展和重命名。当修改表添加，删除，扩展或重命名列时，TokuDB表支持插入，删除和查询，无需停机
在线备份
2、ToukuDB压缩率3、Tokudb性能当CPU时间可用于压缩及解压数据时，压缩效果最佳。如果工作量是由I/O引起的，而不是由CPU引起，压缩便能够提高整体性能。压缩是通过消耗更多的cpu资源来换取减少IO消耗，最终带来性能的提升，如果应用是IO密集型，而不是cpu密集型，那么可以利用剩余的cpu来提升应用性能。
三、TokuDB在归档环境的应用实践为了优化数据归档流程，提高目前人肉归档的效率，dba团队开发了一套数据归档系统，在配置中心填写归档需求，包括源地址、目的地址、归档条件、归档频率等，然后任务中心会根据归档频率，通过agent下发pt-archiver归档指令到相关实例，同时提供归档结果展示，做到集中化、自动化、可视化；
配置中心：
任务中心：
日志展示：
四、关于使用TokuDB的一些建议1、限制不支持外键(foreignkey)功能，如果您的表有外键，切换到TokuDB引擎后，此约束将被忽略。
TokuDB不适大量读取的场景，因为压缩解压缩的原因。CPU占用会高2-3倍，但由于压缩后空间小，IO开销低，平均响应时间大概是2倍左右。
onlineddl对text,blob等类型的字段不适用
没有完善的热备工具，只能通过mysqldump进行逻辑备份
2、适用场景访问频率不高的数据或历史数据归档
数据表非常大并且时不时还需要进行DDL操作
3、关键性参数配置参考tokudbcachesize=Ram*70%
tokudb