共计 2368 个字符，预计需要花费 6 分钟才能阅读完成。
Hello，大家好
随着业务的快速增长，业务体量变得越来越大，这个过程咱们会碰到各种问题，倒逼着咱们进行技术升级。
那明天咱们来聊下，这个过程将会碰到对于数据的问题。
数据增长带来的懊恼
业务快速增长，业务表数据记录一直在减少，这就会带来两个问题。
第一，数据库数据最终将会保留在本地磁盘中，数据记录越多，磁盘占用空间就会越多，对应残余可用空间就会越少。
残余空间达到肯定的阈值之后，将会引发磁盘空间的继续报警，耗费贵重的数据库生产服务器的资源。
第二，业务表记录越多，表查问的效率就会相应变低，另外表变更也会变的很麻烦。
那解决这个问题，解决办法有很多，那 明天介绍其中一种形式，数据归档。
数据归档
数据归档的解决思路非常简单，就是将生产库的数据转移到领有雷同表构造的数据库中，通过缩小生产库记录数量，从而进步数据查问等操作的效率。
数据归档的流程如图所示：
数据归档分为三个流程
创立一个新的数据库 - 归档库，而后在归档库创立与生产库雷同的表
一直查问生产库数据记录，同步复制到归档库
生产库删除曾经复制的数据记录
尽管数据数据归档流程非常简单，然而设计数据归档的计划，咱们必须想分明以下几个问题：
归档前：那些数据能够归档？归档库如何选型？
归档中：数据归档的执行计划
归档后：数据归档带来问题预案
归档之前
首先咱们须要思考第一个问题，那些数据能够归档？
表数据量很大，并且存在很显著的冷热数据，冷数据简直很少拜访。
一个十分典型的例子，订单数据。咱们通常拜访最近的历史订单，而一年前的历史订单查看就会很少。
又比方优惠券数据，还未过期的优惠券，可能须要被查问应用。而一年前过期的，或者说曾经被应用的优惠券，就会被很少拜访。
所以，设计数据归档的之前，咱们须要思考，咱们归档的数据是否适宜被归档。
第二，咱们须要思考归档数据库的选型。
数据归档次要目标是为了节约贵重的生产服务器存储，数据须要通过压缩后才会存到数据库。
所以，归档库须要抉择那些反对高压缩比的存储引擎。
咱们目前归档库选型应用 TokuDB 引擎的 MySQL 数据库，压缩比大概为 6:1。
归档之中
下面流程咱们看到，数据归档无非就是查问数据，插入数据，而后删除数据。
那咱们能够基于这个流程开发一个通用的归档脚本。
Google 搜寻了一圈，在 Github 上找到了一个归档小工具，基本上实现了数据归档的主动运行，对立的归档任务调度治理、主动监控和预警、主动生成报表。在肯定水平上节约了生产力，进步了运维效率。
github 地址：github.com/dbarun/mysq…
非凡归档需要
一般来说，通用数据归档脚本能够满足大部分状况。然而如果数据归档有一些非凡的要求的话，那就须要本人开发。
比如说，咱们有一个我的项目，数据归档的需要是批量查问 90 天前的数据，而后将这些数据插入到当年的归档表中。
举个例子，如果以后数据记录创立工夫为 2020-12-31，这个记录将会归档到 archive_2020 表中。
那如果这个数据记录创立工夫为 2021-01-01，那这个记录就会被归档到 archive_2021 表中。
那像这种有显著业务需要数据归档形式，那就须要咱们在我的项目中本人开发。
归档注意事项
第一，数据归档过程须要一直的读写生产库，这个过程将会大量应用的网络、IO。那为了避免对线上业务造成压力，数据归档个别只在业务低峰期执行。
另外咱们须要尽可能调优数据，尽量升高对线上业务的影响。
第二，数据归档之后，将会删除生产库的数据，这些数据删除之后，将会造成数据空洞。即数据删除之后，表空间并未及时的开释，当长时间没有新的数据填充，会造成空间节约的状况。
所以数据删除之后，咱们须要及时优化数据空洞，开释这些被节约的空间。
第三，如果数据归档中，影响了线上业务，那肯定要及时止损，完结数据归档，而后复盘问题，及时找到问题。
归档之后
数据归档之后，将会带来一些问题，咱们须要及时想好这些的预案。
数据幂等被毁坏
生产数据库，咱们能够应用惟一索引，避免插入反复数据。
然而数据归档之后，局部数据被归档到归档库，这样生产库就又能够插入这些数据库，这就会造成业务上插入反复的数据。
那这个问题，咱们能够应用 ID 发号器解决。生产数据库惟一索引存储 ID 发号生成的 ID，ID 发号器每天枯燥递增，那实践上就不会反复的 ID。
归档查问库 RT 较高
因为归档数据库应用高压缩比的存储引擎，这就会导致归档库查问 RT 变高，例如生产库查问是 1ms 的 rt，用 tokudb 会变成 2ms。
那这个问题，咱们就须要从业务下来思考，是否能够承受。
如果你是后盾类查问业务，能够承受高 RT 的查问，那咱们齐全能够应用归档库。
那如果你是前台类用户侧查问，查问 RT 要低，那就不能承受查问归档库。
然而从另一方面来讲，如果业务上要求查问 RT 肯定要比拟低，那这些数据真的适宜被归档吗？
归档数据缺失，造成业务影响
数据归档之后，生产库就会缺失这部分数据，那如果业务上正好须要应用这些数据，那就会造成业务上异样。
比如说，领取业务中，退款个别须要反对一年以内的订单。那如果退款的时候，正交易领取的数据正好被归档，那就会造成退款的时候找不到对应的领取数据，造成退款失败。
那这个问题解决办法有两种，第一个解决办法，双重查问。如果生产数据库找不到业务数据，那就去归档库查找。
这个解决办法适宜离线的业务。
第二个解决办法，设计一个兼容计划，提供数据逆向接口，反向将归档数据库的记录从新还原到生产库。
那这种解决办法，只适宜大量因为归档数据造成业务异样的业务场景。
总结
数据归档能够解决生产数据库因为数据量过多，从而引发磁盘空间预警，表查问、变更效率变低等问题。
然而工作计划都存在双面性，数据归档可能引发数据幂等被毁坏、归档查问库 RT 较高、归档数据缺失，造成业务影响等问题。
所以咱们设计数据归档的计划时，须要全面思考，提前准备预案，解决可能造成的业务问题