TimescaleDB中SkipScan在压缩数据场景下的成本模型优化

背景概述

在TimescaleDB 2.20版本中，我们发现SkipScan操作在处理压缩数据时存在一个性能优化机会。当查询需要从高度筛选的数据中获取唯一值时，当前的查询计划器可能会做出非最优的选择，特别是在比较索引扫描(IndexScan)和顺序扫描(SeqScan)加排序的成本时。

问题现象

考虑一个典型的时间序列场景：我们需要从压缩的指标表中查询特定时间点后的所有唯一设备ID。例如：

SELECT DISTINCT device FROM ht_metrics_compressed WHERE time > '2020-01-28';

在这个查询中，'2020-01-28'是表中记录的最新时间点。理想情况下，查询优化器应该选择SkipScan执行计划，因为它本质上是对每个唯一值执行一次LIMIT 1查询的重复操作。

当前实现的问题

当前的成本模型存在以下不足：

1. 总成本比较的局限性：优化器仅比较IndexScan和SeqScan加排序的总成本，而SeqScan的总成本可能更低，因为它应用了高度选择性的时间过滤器。

2. 忽略启动成本：SeqScan加排序的启动成本实际上远高于IndexScan，因为后者不需要额外的排序步骤。这与LIMIT查询的处理方式不同，LIMIT查询会考虑这种启动成本差异。

3. 压缩数据场景：在压缩数据上，这种成本差异更为明显，因为解压和排序操作会带来显著的性能开销。

技术分析

SkipScan本质上是一系列LIMIT 1查询的组合，每个唯一值执行一次。当前的实现没有充分考虑到：

• 对于每个唯一值，IndexScan可以快速定位到第一个匹配项
• 而SeqScan需要扫描、解压并排序整个相关时间范围内的数据才能找到第一个匹配项
• 这种启动成本的差异在获取少量高度筛选的唯一值时尤为关键

解决方案

我们建议对SkipScan的成本模型进行以下改进：

1. 引入启动成本因子：像LIMIT查询一样，在比较IndexScan和SeqScan时考虑启动成本。

2. 调整压缩数据成本计算：特别针对压缩数据场景，增加解压和排序操作的成本权重。

3. 优化SkipScan启发式：当查询条件高度筛选时，优先考虑SkipScan计划。

实现影响

这一优化将带来以下好处：

1. 查询性能提升：对于获取最新时间点唯一值这类常见查询，响应时间将显著改善。

2. 资源利用率优化：减少不必要的数据解压和排序操作，降低CPU和内存消耗。

3. 更一致的优化决策：使SkipScan的选择逻辑与LIMIT查询保持一致。

测试验证

我们建议将这类场景加入TSBench的SkipScan基准测试中，包括：

1. 不同时间范围的唯一值查询
2. 不同压缩率的数据集
3. 不同基数(唯一值数量)的场景

总结

TimescaleDB中SkipScan的成本模型优化是一个典型的查询优化器改进案例，它展示了在实际应用中如何平衡不同执行路径的成本考量。这一改进特别有利于时间序列分析中常见的"获取最新数据"模式，使系统能够更智能地选择最优查询计划，提升整体性能表现。

对于使用TimescaleDB处理压缩时间序列数据的用户，这一优化将直接改善他们获取最新数据或特定时间点数据的查询效率，特别是在监控仪表盘、实时分析等应用场景中效果显著。