QuestDB符号列LIKE/ILIKE/REGEXP操作性能优化分析

背景介绍

在QuestDB 8.1版本中，开发团队对符号列(SYMBOL)的LIKE/ILIKE/REGEXP操作进行了优化。这项优化通过先过滤符号表并存储整数代码列表，然后使用该列表过滤行数据的方式，旨在提高这些操作的执行效率。然而，在实际使用中发现，当符号列中不同值的数量较多时，这种优化反而可能导致性能下降。

问题现象

以一个XRP交易数据表为例，表中包含一个名为"pair"的符号列，该列有46,143个不同的值。当执行包含LIKE操作的查询时，8.1版本比8.0.1版本慢了约100倍（从60ms增加到6000ms）。

技术分析

优化原理

8.1版本引入的优化机制工作原理如下：

1. 首先对符号表进行过滤，生成匹配的符号代码(int)列表
2. 然后使用这个整数代码列表来过滤实际的行数据

这种设计基于的假设是：符号表的过滤操作比直接对字符串进行操作更高效，特别是当符号表较小时。

性能瓶颈

然而，当符号列包含大量不同的值时，这种优化策略会遇到以下问题：

1. 符号表扫描开销：处理大符号表时，扫描和过滤符号表本身就会消耗大量时间
2. 内存使用：需要存储大量的符号代码，增加了内存压力
3. 缓存效率：大符号表会降低CPU缓存命中率

实际案例表现

在报告的案例中：

• 表中有46,143个不同的符号值
• 查询时间范围内有507个不同的pair值
• 经过LIKE过滤后剩下493个pair值
• 8.0.1版本直接处理字符串，耗时60ms
• 8.1版本采用符号表过滤方式，耗时6000ms

解决方案建议

针对这一问题，可以考虑以下改进方向：

1. 动态优化策略：根据符号表的大小决定是否启用此优化

   • 对小符号表使用符号代码过滤方式
   • 对大符号表回退到直接字符串处理方式

2. 阈值配置：允许用户配置符号表大小的阈值参数

   • 自动或手动决定是否启用优化
   • 提供系统级或查询级的配置选项

3. 统计信息利用：基于统计信息智能选择最优执行路径

   • 收集符号表的基数统计信息
   • 基于统计信息自动选择最优算法

最佳实践

对于使用QuestDB并遇到类似性能问题的用户，建议：

1. 监控符号列基数：关注高基数符号列的使用情况
2. 版本选择：对于包含大符号表的场景，暂时使用8.0.1版本
3. 查询优化：考虑重写查询，减少对大符号列的LIKE/REGEXP操作
4. 等待修复：关注后续版本中对此问题的修复

总结

QuestDB 8.1对符号列操作的优化在大多数情况下能提高性能，但在处理高基数符号列时可能出现性能回退。开发团队已经意识到这一问题，并计划通过使优化成为可选特性来解决。用户在使用时应了解这一特性，并根据实际数据特征选择合适的版本或等待后续优化。