CrateDB中字符串列存储压缩优化的探索与实践

背景与问题分析

在CrateDB的存储引擎实现中，团队长期维护着一个Lucene90DocValuesFormat的分支版本，该版本移除了术语字典(terms dictionary)的压缩功能。这一修改带来了显著的性能提升，特别是在处理高基数字符串列值的流式读取场景下。然而，这种定制化分支也带来了维护成本——无法自动获取Lucene主线的性能改进和新功能（如Lucene 10中引入的稀疏索引特性）。

性能测试表明，在select/hash_join基准测试中（涉及两个表通过字符串列进行连接操作），使用主线的压缩格式会导致严重的性能下降。特别当该字符串列被定义为主键时（意味着值唯一性），对术语字典的访问呈现完全随机模式，这对基于压缩块存储的数据结构极为不利——每次访问都可能命中不同的压缩块，使得解压缩开销无法分摊。

解决方案探索

团队尝试了多种技术方案来优化这一场景：

1. 预取优化：在BinaryColumnReference中实现prefetch方法，尝试按术语字典顺序批量加载1024个文档ID的值。虽然相比基线有所改善，但在大数据集下仍比分支版本慢约两倍，因为随机分布的文档ID仍会命中不同的压缩块。

2. 混合存储策略：考虑仅对主键列使用分支格式，其他字符串列回归主线格式。但这样会牺牲主键字符串列的稀疏索引功能。

3. 索引排序优化：实验性地对主键列实施索引排序，在小数据集场景表现优异，但在大规模流式处理时反而造成性能下降。测试数据显示：

   • 小数据集查询延迟降低128%
   • 但百万级数据查询延迟反而增加81.73%

4. 存储字段替代方案：尝试从存储字段而非排序集合文档值中获取主键值。虽然存储字段在顺序访问时可能有优势，但实测性能反而下降约5倍。

技术决策与最终方案

经过多轮验证，团队确定了最优技术路线：

1. 采用BinaryDocValues：相比SortedSetDocValues，BinaryDocValues在大规模顺序访问场景下展现出明显优势：

   • 在百万级数据查询中性能提升52.21%
   • 内存分配率从1570.07MB/s提升至2552.79MB/s
   • 显著减少GC压力（Young GC次数减少，平均耗时降低）

2. 存储空间权衡：虽然BinaryDocValues方案会使字段数据增长21%，但术语字典大小仅增加5.28%，总体存储空间增加约2.54%，在可接受范围内。

3. 保留定制化分支：鉴于实际业务场景中大量存在需要流式读取字符串数据的负载，最终决定暂时保留去除术语字典压缩的分支版本，同时将BinaryDocValues作为未来演进方向。

经验总结与未来方向

本次优化过程得出几个重要结论：

1. 访问模式决定性能特征：随机访问与压缩存储的相性较差，在设计存储格式时必须考虑典型查询模式。

2. 没有银弹方案：索引排序对小数据集有效但不利于流式处理，说明优化需要针对具体场景。

3. 性能与空间的trade-off：在某些场景下，适度的存储空间增长换取性能提升是合理选择。

未来工作将聚焦于：

• 全面转向BinaryDocValues的可行性验证
• 研究如何平滑迁移现有数据格式
• 探索对数值主键列应用索引排序以替代BKD索引的可能性

通过这次深入的性能优化实践，CrateDB团队对列式存储的底层机制有了更深刻的理解，为后续存储引擎的持续优化奠定了坚实基础。