Cygnus版本升级导致STH-Comet查询日志差异的问题排查

问题场景 #

• 测试环境：Orion 3.7.0 + Cygnus（2.20.0/3.2.0）+ STH-Comet 2.10.0 + MongoDB 4.4
• 核心现象：
  • 使用Cygnus 2.20.0写入的数据，STH-Comet查询时count操作采用COUNT_SCAN计划，性能稳定
  • 升级到Cygnus 3.2.0后，相同查询的count操作变为COLLSCAN，数据量越大查询越慢
  • 手动添加与旧版本一致的cyg_raw_opt索引（entityId, entityType, attrName, recvTime）后，问题仍未解决

可能原因及排查方向 #

1. MongoDB查询计划缓存未更新 #

MongoDB的查询优化器会缓存执行计划，即使新增了匹配的索引，旧的COLLSCAN计划可能仍被优先使用。

• 排查操作：
  执行命令清除目标集合的查询计划缓存：

  db.runCommand({ planCacheClear: "<目标集合名称>" })
  

  清除后重新调用STH-Comet接口，查看MongoDB查询日志中的执行计划是否切换为COUNT_SCAN。

2. 索引或数据结构不匹配 #

Cygnus 3.2.0可能修改了数据存储格式或索引字段的类型，导致手动添加的索引无法匹配查询条件：

• 排查操作：
  1. 对比新旧版本的文档结构：

     // 查看Cygnus 2.20.0写入的文档
     db.<2.20版本集合>.findOne()
     // 查看Cygnus 3.2.0写入的文档
     db.<3.2版本集合>.findOne()
     

     确认entityId、entityType、attrName、recvTime等字段的名称、类型、嵌套层级是否一致。
  2. 检查手动添加的索引细节：

     db.<3.2版本集合>.getIndexes()
     

     确认cyg_raw_opt索引的字段顺序、类型完全匹配旧版本的索引定义。

3. Cygnus 3.2.0的默认配置变更 #

Cygnus 3.x版本可能调整了MongoDB sink的索引生成规则，默认索引结构的变更导致与STH-Comet的查询逻辑不兼容：

• 排查操作：
  查看Cygnus 3.2.0的MongoDB sink配置项（如mongodb_index_raw），确认是否可以通过配置参数恢复旧版的索引结构。修改配置后重启Cygnus，重新写入数据并测试查询性能。

4. STH-Comet与Cygnus 3.2.0的兼容性问题 #

STH-Comet 2.10.0发布时间早于Cygnus 3.2.0，可能未适配新版本的数据格式或索引逻辑，导致查询时无法正确识别索引：

• 排查操作：
  在MongoDB中直接执行STH-Comet实际调用的查询语句，查看执行计划：

  db.<目标集合>.explain("executionStats").find({
      entityId: "Car1",
      entityType: "<你的实体类型>",
      attrName: "<你的属性名称>"
  }).count()
  

  分析winningPlan字段，确认是否有匹配的索引被使用。

结论方向 #

• 若清除查询计划缓存后问题解决，属于临时缓存导致的配置类问题
• 若数据结构或索引配置存在变更，属于Cygnus版本升级的默认行为变更，需调整Cygnus索引配置或升级STH-Comet至适配版本
• 若确认是组件间兼容性不匹配，不属于bug，属于版本迭代带来的兼容性适配问题

内容的提问来源于stack exchange，提问作者ctc-watanabe