MongoDB时间序列集合处理IoT数据查询慢于普通集合的原因排查

我分别在MongoDB普通集合和时间序列集合中存储了IoT数据，使用的MongoDB版本为6.0.4。

普通集合Schema #

const TcpDataSchema = new mongoose.Schema({
  src_ip: String,
  dst_ip: String,
  dst_mac: String,
  src_mac: String,
  dst_port: String,
  src_port: String,
  packet_size: String,
  protocols: Array,
  timestamp: {type: Number, required: true},
}, {
  autoIndex: false,
})

时间序列集合Schema #

const TimeTcpDataSchema = new mongoose.Schema({
  timestamp: Date,
  metadata: {
    src_ip: String,
    dst_ip: String,
    dst_mac: String,
    src_mac: String,
    dst_port: String,
    src_port: String,
    protocols: Array,
  },
  packet_size: String,
}, {
  timeseries: {
    timeField: 'timestamp',
    metaField: 'metadata',
  },
})

两个集合均在timestamp字段上创建了索引，执行的查询语句如下：

{
    $match:
      {
        timestamp: {
          $gte: <start>,
          $lte: <end>,
        },
      },
  }

查询结果显示时间序列集合的耗时更长，请问这是什么原因？

出现这种情况可能有以下几个原因：

• 数据类型不匹配导致索引失效：普通集合的timestamp是Number类型（通常存储时间戳数值），而时间序列集合的timestamp是Date类型。如果查询参数<start>和<end>是数值型时间戳，MongoDB会进行隐式类型转换，这会导致无法有效利用timestamp上的索引，触发全集合扫描，大幅增加查询耗时。

• 时间序列集合的分桶存储特性：MongoDB时间序列集合按时间窗口自动分桶存储，每个桶包含一段时间范围内的文档。当查询时间范围跨多个桶时，数据库需要遍历多个桶并从中提取符合条件的文档，这个过程相比普通集合直接通过索引定位文档会产生额外开销，若查询覆盖大量分桶，开销会更明显。

• 索引统计信息过时：如果时间序列集合的索引统计信息未及时更新，MongoDB查询优化器可能选择低效的查询计划。可以执行db.<timeSeriesCollectionName>.validate({full: true})或analyze命令更新统计信息后重新测试。

• 数据量与分布差异：两个集合的数据量、时间戳密度等分布情况不一致也会影响性能。比如时间序列集合的单桶数据量过大，或时间分布不均匀，都会拖慢查询效率。

建议先检查查询参数类型是否与时间序列集合的timestamp字段匹配，将参数转换为Date类型后再执行查询验证性能变化。同时可以通过explain("executionStats")分析两个集合的查询执行计划，对比索引使用情况、扫描文档数等指标，进一步定位问题。

内容的提问来源于stack exchange，提问作者xiyuan tu