Dropbox存储系统工程实践数据压缩Magic Pocket
大公司也这样？改完系统：先上线，再看哪儿炸
收录于 2026/5/15 18:11:09
大公司也这样？改完系统：先上线，再看哪儿炸
作者： Renato Losio | 译者： 田橙 | 来源： InfoQ
Dropbox 近日分享了其内部对象存储系统 Magic Pocket 的一次重大优化经历，揭开了大公司也会踩坑的真实一面。
背景问题
Magic Pocket 是 Dropbox 的不可变对象存储系统，数据一旦写入便不可修改。这种设计提升了可靠性，但也带来了副作用——删除操作不会立即释放空间，只会留下未使用空间。
今年初，Dropbox 发现一个名为 Live Coder 的新服务生成了大量严重未填满的存储卷，有些卷的使用率甚至低于 5%，造成严重的数据碎片化和存储浪费。
解决方案
团队重新设计了压缩策略，推出 L2 和 L3 两级方案：
- L2 策略：优先处理低填充率卷，将多个稀疏卷合并为接近满载的新卷
- L3 策略：通过 Live Coder 服务将极度稀疏卷中的有效数据流式迁移到新的纠删码卷中
压缩过程通过从旧卷中收集有效数据块，写入新卷并淘汰旧卷，实现物理层面的空间回收。
核心启示
- 大规模系统的变更影响难以事前完全预测
- 不可变存储设计需要配套的空间回收机制
- 监控和快速响应比完美的前期规划更重要
正如 Hacker News 用户的评论：原以为这种体量的公司都会拿生产数据反复建模推演，结果发现也差不多：先发了再说，看看哪儿先炸。