Apache KvRocks 存储引擎中 L0-L1 层压缩优化方案探讨

背景与问题分析

在基于 RocksDB 的存储引擎 Apache KvRocks 中，数据压缩策略对系统性能有着重要影响。当前实现中，L0 和 L1 这两个最上层的数据层级默认不进行数据压缩，这一设计主要基于以下考虑：

1. 热点数据访问：L0-L1 层级通常包含最频繁访问的数据，不压缩可以减少解压缩带来的 CPU 开销
2. 写入性能优化：避免压缩操作可以降低写入延迟

然而，在某些特定场景下，这种默认策略可能并非最优选择。特别是当业务数据具有以下特征时：

• 数据压缩率较高（如达到 8-10 倍压缩比）
• 系统写入吞吐量非常大
• L0-L1 层级的数据频繁参与 compaction 操作

在这种情况下，L0-L1 层不压缩会导致：

• 存储空间放大
• 增加 I/O 压力
• 提升 compaction 操作的读写负载

技术方案设计

针对这一问题，社区提出了可配置化的压缩策略方案。核心思路是为 L0-L1 层级引入可调节的压缩配置能力，允许用户根据实际业务特征进行优化。

配置参数设计

经过讨论，最终确定采用以下配置参数：

rocksdb.nocompression_for_first_levels

该参数采用整数值，表示前 N 个层级不进行压缩。例如：

• 设置为 2（默认值）：保持现有行为，L0-L1 不压缩
• 设置为 1：仅 L0 不压缩
• 设置为 0：所有层级都启用压缩

实现原理

在技术实现上，该功能通过修改 RocksDB 的 compression_per_level 选项来实现。具体逻辑为：

1. 解析用户配置的 nocompression_for_first_levels 值
2. 构建压缩级别字符串，前 N 个层级设置为 kNoCompression
3. 后续层级使用用户配置的压缩算法（如 LZ4、ZSTD 等）
4. 将该配置应用到所有列族(Column Family)

应用场景建议

根据不同的业务特征，建议采用以下配置策略：

1. 常规 OLTP 场景：保持默认值 2，优先保证读写性能
2. 高压缩比数据场景：可设置为 1 或 0，利用压缩减少 I/O 和存储开销
3. 冷热数据分离场景：结合其他优化手段，如 TTL 或手动 compact，灵活调整压缩策略

性能考量

启用 L0-L1 压缩时需要注意：

1. CPU 开销增加：压缩/解压缩操作会消耗额外 CPU 资源
2. 写入放大效应：压缩可能增加写入延迟
3. 读取性能影响：热点数据需要解压缩，可能增加读取延迟

建议在实际生产环境中进行充分的基准测试，找到最适合业务特征的配置值。

总结

Apache KvRocks 通过引入可配置的 L0-L1 压缩策略，为用户提供了更灵活的存储优化手段。这项改进特别适合数据压缩率高、写入吞吐量大的业务场景，能够有效平衡存储空间、I/O 开销和 CPU 利用率之间的关系。用户可以根据自身业务特征，通过简单的配置调整获得最佳的性能表现。