SlateDB对象存储中的SST文件压缩技术解析

背景与挑战

SlateDB作为一个基于云存储的键值数据库，面临着如何高效管理存储在对象存储(如S3)上的SST文件的挑战。与传统本地存储的LSM树实现不同，SlateDB需要特别考虑云环境下的API调用成本、网络延迟以及存储特性。

设计考量

在SlateDB的架构设计中，SST文件压缩策略需要平衡多个关键因素：

1. 写放大：由于云存储没有按字节计费，主要成本来自API调用次数，因此写放大相对不那么关键
2. 读放大：查询性能至关重要，需要尽量减少每次查询需要检查的SST文件数量
3. 空间放大：虽然云存储空间成本较低，但过多的空间占用会影响缓存效率和恢复时间
4. 元数据管理：需要高效跟踪大量SST文件的元数据

技术方案演进

项目团队经过深入讨论，最终确定了分阶段实施的压缩策略：

初始阶段：简单分层压缩

首版实现采用基本的分层压缩策略：

• L0层包含多个小SST文件(可能只有少量键值对)
• 定期将所有L0文件合并为一个新的有序运行(sorted run)
• 这种实现简单直接，便于快速验证概念

中期优化：混合压缩策略

基于Dostoevsky论文中的"惰性分层"(Lazy Leveling)理念：

• 除最大层外，其他层采用分层压缩
• 最大层采用层级压缩，保持单一有序运行
• 这种混合策略平衡了写放大和空间放大

长期规划：可插拔压缩策略

最终目标是支持多种可插拔的压缩策略：

• 通用压缩(Universal Compaction)
• 大小分层压缩(Size-tiered Compaction)
• 增量压缩(Incremental Compaction)
• 允许用户根据工作负载特性选择最适合的策略

关键技术细节

内存管理优化

为避免频繁访问对象存储，SlateDB采用多层缓存：

1. 内存中的MemTable
2. 合并后的内存表(包含多个WAL SST的数据)
3. 本地磁盘缓存
4. 最终回落到对象存储

压缩调度

考虑将压缩任务分布到不同计算资源：

• 高频小压缩由长期运行的轻量级节点处理
• 低频大压缩由按需启动的重量级节点处理
• 这种设计充分利用云计算的弹性优势

过滤器优化

采用Monkey论文中的技术，在不同层级间智能分配Bloom过滤器内存预算：

• 为较小层级分配更多bits/key
• 较大层级可容忍稍高的误报率
• 在保持总体低误报率的同时减少内存占用

性能考量

SlateDB特别关注云环境下的性能特征：

• 通过减少S3 API调用降低运营成本
• 利用本地缓存避免S3读取的高延迟(100ms级)
• 优化恢复时间，避免处理过多小SST文件
• 平衡压缩频率与查询性能

总结

SlateDB的SST压缩设计展现了云原生数据库的独特思考。不同于传统LSM实现过度优化写放大，SlateDB更关注云环境下的实际运营成本和性能表现。通过分阶段实现和可插拔架构，项目既保证了初期简单性，又为未来优化留下充足空间。这种平衡务实与前瞻的设计理念，值得其他云原生存储系统借鉴。