全文19135字，预计阅读时间26分钟

一、业务介绍

为了更好的理解下面介绍的几点，我们先简单介绍一下业务的一些概念。

二、为什么要优化

在优化的时间点，整个助手的存储占用达到了几个P，每年的预算成本接近1000万。从业务角度，通过分析业务场景对应的mysql库，库中会记录对应应用的大小。分析后的大致数据如下：

在这里，会发现应用补丁包占用量非常大，同时发现总存储量——已知存储后，还有未知的P级存储。需要看这里应用的补丁包的存储占用是否符合预期。

因此，优化有几个正当理由：

高预算消耗 强迫症 寻找存储将清理无用数据的地方

整个清洗过程如下所述。

三、分析

优化的第一步就是分析如何优化，找出空闲存储，进行优化。在普通话中，这是一个猜测。这里的空闲，可以定义为消耗的存储交付的价值，并不像预期的那样。什么是储值？在几个部分。

有了初步的方向，需要进行更准确的确认，判断盈利空间。从以下两个角度进行验证。

▲储物空间分布

▲更新流量分布

有了上面的数据，从基本面可以看出，节流更新的存储消耗更大，但实际流量值却很低。基于此，可以确定应该启动数据保存更新的补丁包。

四、优化思路

就像把大象放进冰箱一样，打开门——放大大象——关上门。优化不是手动删除存储。整个过程参考了大象装冰箱的思路，分为三个步骤：

4.1 恢复

正所谓“知己知彼，百战百胜”百度优化，降低做事风险的首要方法，应该是把事情搞清楚。对于已经存在好几年的老企业，如何找出来也有一些经验。

最后在综合信息整理的基础上，完成基于数据流的业务流程图。整个过程有点像

在《漫漫长夜》的调查过程中，抓住每一个线索，完成最后的谜题。

谜题一——增量更新场景的数据流

从图中可以看出，主存储分为“开发者应用、客户安装应用、省流量补丁包”三个部分。补丁包的生成步骤为：

获取开发者安装的应用 生成开发者安装的应用和更高版本应用的补丁包

谜题 2 - 用户安装的应用程序集合

谜题 3 - 增量更新处理

核心数据处理流程如下：

4.2 制定计划

既然是存储优化，主要看排序后的数据过程的各个环节是否可以优化百度优化，是否需要优化。首先，磨刀不会误砍木头，通过api从BOS导出完整列表。由于历史积累，总共有1亿+条数据。然后，在原有增量更新策略的基础上，制定相应的优化策略。

在整理计划的过程中，我深深感受到了项目评估和持续跟进的重要性。下面给出几个例子。

在处理的过程中，发现了上述未知的P级空间。发现原来的物理机迁移了，自己运维的数据库没有迁移。结果之前的增量包虽然占用了BOS存储，但是在db中却找不到。评估对业务没有实际用处，最后清理一下（很酷）。

4.3 执行计划

这是最简单的过程，需要注意的核心是设计验证方法和回滚方案。我不会在这里详细介绍。整个效果从峰值P水平下降到百T水平，排除毒素，轻松搞定。

五、总结

用习惯的五题法做复习，总结你在整个过程中学到的东西。

5.1 为什么会有这么大的无效存储量？

方案未清仓，研发反馈产品设计未考虑历史库存问题

5.2 应该考虑谁？

在研发上，我个人认为产品与研发的和谐边界是产品提供用户需要完成的功能，技术提供解决方案。该产品不需要关心它的存储时间。它只需要提出需要执行用户数据保存更新的时间段。研发根据产品功能决定补丁包是否可以存档和删除。

5.3 原始系统缺少什么？

文件积累和监控 & . 一定要做好文档的积累，等到有一天系统需要优化的时候，可以看到系统为什么会这样；改进监控，让你知道你所知道的；要经常，相同的业务逻辑可能会从产品到产品的演进发生变化。因地制宜的设计已成为历史的包袱，保持开放的心态，回顾过去，着眼未来。

5.4 如何避免？

依靠您的经验，同时考虑相反的情况。事情有对立面。很多时候我们在思考问题时，只关注眼前看到的点。阳光下一定有阴影。作为研发，我们可以多思考问题的背后是什么，这样才能更全面地考虑问题，少停留。一些技术债务。

5.5 如何做得更好？

系统永远为产品服务，但研发要考虑投入和产出，不仅要考虑研发的投入和产出，还要和产品一起考虑产品的投资回报率。从另一个角度看问题，你会发现不同的技术解决方案，也许可以。

很多信息可咨询http://www.yoyi8.com