在现代数据库系统中，字符串类型的数据占据了相当大的存储空间。根据 CedarDB 团队的调研，真实世界的数据库中约有 50% 的数据以字符串形式存储，这使得字符串压缩成为影响整体性能和存储成本的关键因素。然而，在 HTAP（混合事务分析处理）场景下，压缩策略的选择变得更加复杂：我们既需要高效的压缩率来降低 I/O 开销，又不能让解压开销成为查询执行的瓶颈。本文将聚焦于 CedarDB 中 FSST（Fast Static Symbol Table）压缩算法的核心参数，探讨如何在 OLTP 与 OLAP 混合负载下实现压缩率与解压性能的最佳平衡。
HTAP 架构下的压缩挑战
在深入参数调优之前，我们需要理解 CedarDB 的混合存储引擎 Colibri 是如何处理热数据和冷数据的。CedarDB 采用行存与列存相结合的策略：新写入的数据以未压缩的行存形式保存在热区，这部分数据通常会被 OLTP 查询频繁访问；而随着时间推移，不再频繁访问的冷数据会被迁移到压缩列存格式中。这种设计天然地将压缩的开销与收益进行了分离：热数据追求极致的读写延迟，冷数据则优先考虑压缩率和扫描吞吐量。
FSST 正是为冷数据设计的一种轻量级字符串压缩方案。与传统的字典压缩不同，FSST 通过识别频繁出现的子字符串（称为符号）并将其映射为单字节编码来实现压缩。其核心优势在于支持随机访问：任何一条压缩后的字符串都可以单独解码，无需扫描相邻数据，这使得 FSST 非常适合列存场景下的谓词下推和向量化执行。然而，FSST 的解压过程毕竟比直接读取原始字符串或字典编码更耗时，因此在 HTAP 场景下必须仔细权衡何时启用 FSST 以及启用哪些参数配置。
FSST 核心参数解析
符号表规模与逃逸码机制
FSST 的符号表最多包含 255 个有效符号，保留一个值（255）作为逃逸码。这意味着在压缩过程中，如果某个字节序列无法用符号表中的任何符号表示，系统会输出逃逸码后跟原始字节。这种设计的 Trade-off 非常直接：符号表越大，能够覆盖的常见模式越多，压缩率越高；但符号表必须适配 CPU 的一级缓存（约 32KB），过大反而会降低遍历查找的速度。实践中，CedarDB 的做法是选择压缩增益最高的 255 个符号，压缩增益的计算公式为 gain(symbol) = frequency(symbol) * size(symbol)，即该符号在样本中出现的次数乘以其长度。
块大小与采样策略
FSST 采用两阶段压缩流程：首先基于输入样本构建符号表，然后用该符号表对完整数据进行编码。样本的选取至关重要：如果样本不能代表整体数据的分布特征，构建出的符号表在实际数据上的压缩效果会大打折扣。CedarDB 将压缩块的大小设定为 2 的 18 次方，即每块约 256K 条记录。这个数值经过了综合考量：块太小会导致符号表的元数据开销占比过高，块太大则会延长首次构建符号表的时间，并降低压缩的颗粒度。更重要的是，256K 条记录足以让常见的模式在样本中高频出现，从而构建出有效的符号表。
压缩率惩罚阈值
这是 CedarDB 在 HTAP 场景下引入的一个关键决策参数。由于 FSST 的解压开销高于简单的字典查找，如果仅仅节省几个字节就启用 FSST，往往得不偿失。CedarDB 设定了一个 40% 的惩罚阈值：只有当 FSST 压缩后的数据比次优方案小 40% 以上时，系统才会选择启用 FSST。这个阈值是通过在 ClickBench 和 TPC-H 基准上反复测试后确定的，它确保了 FSST 的启用能够带来实质性的收益，而非仅仅是数字上的优化。
HTAP 场景下的调优策略
OLTP 热数据的压缩规避
在典型的 HTAP 场景中，OLTP 查询往往针对最近写入的数据，这些数据位于热区，以行存形式存储，不经过任何压缩。FSST 的参数调优在这里几乎不产生影响，因为热数据根本不使用 FSST。然而，需要注意的是，当冷数据被重新激活为热数据时（例如历史订单被重新编辑），它需要从列存格式解码回行存格式，这个过程的开销应该被纳入整体延迟预算的考量中。
OLAP 冷数据的压缩优化
对于 OLAP 查询访问的冷数据，FSST 的参数配置直接影响扫描性能。从 CedarDB 公布的基准测试结果来看，在冷运行（数据从磁盘读取）场景下，FSST 能够带来显著的提速：ClickBench 上部分查询的响应时间降低了 40%，TPC-H 上也有约 10% 的提升。这主要得益于压缩后数据量的减少降低了 I/O 时间，而解压 CPU 开销相对磁盘读取延迟可以忽略不计。在这种情况下，可以适当放宽压缩率阈值的限制，让更多数据列使用 FSST，尤其是那些在查询中频繁作为过滤条件的字符串列。
谓词下推与 DICT_FSST 混合模式
CedarDB 支持一种称为 DICT_FSST 的混合压缩方案：先对字符串建立字典，再对字典内容应用 FSST。这种设计的精妙之处在于，字典键是固定长度的整数，可以直接用于等值比较，而无需完全解压字符串。对于需要进行等值过滤的 OLAP 查询，DICT_FSST 既保留了字典压缩的快速过滤能力，又通过 FSST 进一步压缩了字典本身的存储空间。如果你的工作负载中包含大量针对字符串列的等值连接或过滤操作，DICT_FSST 往往是比纯 FSST 更好的选择。
监控指标与回退策略
在实际部署中，我们需要持续监控以下指标来判断 FSST 参数配置的有效性。首先是压缩率监控，CedarDB 提供了系统表 cedardb_compression_infos 用于查看各列的实际压缩效果。如果某个字符串列的压缩率持续低于预期，可能需要考虑增大样本量或调整块大小。其次是查询性能监控，特别是那些涉及 LIKE 谓词或字符串长度函数的查询，在热运行状态下可能会因为 FSST 解压而变慢。如果观察到这类查询的响应时间出现明显退化，可以考虑在特定列上禁用 FSST，或回退到纯字典压缩。
另一个值得关注的参数是冷热数据的切换间隔。CedarDB 建议在配备现代 NVMe SSD 的服务器上，将热数据保持为行存的时间窗口设置为 10 到 40 秒。过短的间隔会导致频繁的数据格式转换，过长的间隔则会让本应及时压缩的冷数据继续占用行存空间。具体的数值应该根据实际的 I/O 负载和查询模式来调整。
结语
FSST 为 HTAP 数据库的字符串压缩提供了一个兼顾压缩率与随机访问性能的解决方案，但其参数配置需要在具体场景下仔细调优。符号表规模决定了压缩的精细程度，块大小影响符号表的构建质量，压缩率阈值则是控制解压开销与存储节省之间平衡的关键开关。在实践中，建议从 CedarDB 默认的 40% 阈值和 256K 记录块大小开始，通过监控压缩率和查询性能逐步调整。对于以扫描为主的 OLAP 工作负载，可以适当降低阈值以获取更高的压缩收益；对于解压密集型的查询，则应保持或提高阈值，并考虑使用 DICT_FSST 混合模式来加速谓词评估。
参考资料
- CedarDB 官方博客：《Efficient String Compression for Modern Database Systems》（2026 年 1 月 29 日）
- VLDB 2020 论文：《FSST: Fast Random Access String Compression》（Peter Boncz, Thomas Neumann, Viktor Leis）
- CWI/UVA 硕士论文：《FSST+: Enhancing String Compression Through Common Prefix Extraction》（2025 年 8 月）