LSM-Tree压缩策略与写放大优化
LSM-Tree压缩策略与写放大优化
一、LSM-Tree的写放大困境：压缩的代价
LSM-Tree（Log-Structured Merge-Tree）通过将随机写转化为顺序写，实现了极高的写入吞吐量。然而，这种设计引入了写放大（Write Amplification）问题——同一条数据在多次压缩（Compaction）中被反复读取和重写。LevelDB/RocksDB的Leveled Compaction写放大因子可达10-30倍，意味着写入1GB有效数据实际产生10-30GB的磁盘I/O。
二、压缩策略对比
2.1 策略类型
graph TB subgraph "Leveled Compaction" A1[L0: 无序SSTable] A2[L1: 有序, 范围不重叠] A3[L2: 有序, 范围不重叠] A1 --> A2 A2 --> A3 end subgraph "Tiered Compaction" B1[L0: 无序SSTable] B2[L1: 多个有序SSTable<br/>范围可能重叠] B3[L2: 合并后SSTable] B1 --> B2 B2 --> B3 end subgraph "写放大对比" C1[Leveled: 10-30x<br/>读放大低] C2[Tiered: 3-10x<br/>读放大高] C3[Hybrid: 折中方案] end2.2 RocksDB压缩配置
class CompactionConfig: def get_leveled_config(self) -> dict: return { 'compaction_style': 'kCompactionStyleLevel', 'level0_file_num_compaction_trigger': 4, 'max_bytes_for_level_base': 256 * 1024 * 1024, # 256MB 'max_bytes_for_level_multiplier': 10, 'target_file_size_base': 64 * 1024 * 1024, # 64MB 'write_buffer_size': 64 * 1024 * 1024, } def get_tiered_config(self) -> dict: return { 'compaction_style': 'kCompactionStyleUniversal', 'level0_file_num_compaction_trigger': 8, 'max_size_amplification_percent': 25, 'size_ratio': 1, }四、架构权衡与边界分析
4.1 写放大与读放大的权衡
Leveled Compaction写放大高但读放大低（每层最多一个SSTable覆盖同一Key范围），Tiered Compaction写放大低但读放大高（同一Key范围可能有多个SSTable）。写密集场景优先Tiered，读密集场景优先Leveled。
4.2 压缩速度与空间放大的取舍
压缩速度越快，空间放大越小，但CPU和I/O占用越高。建议在业务低峰期执行Full Compaction，高峰期仅执行必要的Minor Compaction。
五、总结
LSM-Tree的压缩策略需要在写放大、读放大和空间放大三者之间权衡。Leveled Compaction适合读密集场景，Tiered Compaction适合写密集场景，Hybrid策略在两者之间折中。
落地建议：根据读写比例选择压缩策略；监控写放大因子，超过20x时考虑切换策略；在业务低峰期执行Full Compaction控制空间放大。