高性能查询指定时间段内等间隔时序采样数据的最优方法

场景前提 #

• 时序文档集合单条记录包含timestamp（秒级时间戳）、value两个字段，总数据规模可达千万级，常规写入频率为每秒1条
• 高频查询需求：拉取指定时间窗口内固定间隔的采样点，比如过去1小时取5分钟间隔共12个点、1分钟间隔共60个点
• 现有基础：timestamp、value字段已建索引，单时间范围过滤（如timestamp > {一小时前时间戳}）在20万条数据规模下执行速度良好

方案选型（性能从高到低排序，优先选靠前的方案） #

• 预聚合分桶（性能天花板，无任何方案能超越）
  高频查询场景下绝对不要每次请求都实时扫原始明细计算，提前做分桶预计算：

  1. 先梳理业务常用的采样粒度，最小粒度一般设为1分钟，按粒度把时间线切成固定时间桶，比如1分钟桶的区间就是[floor(时间戳/60)*60, floor(时间戳/60)*60 + 60)
  2. 数据写入时同步更新对应桶的结果：如果采样要取桶内第一条/最后一条/平均值/最大值，直接在写入链路把结果更新到独立的预聚合集合，集合主键直接用「分桶粒度+桶起始时间戳」
  3. 查询时直接按时间范围、采样粒度从预聚合集合按主键范围捞数据就行，全程不需要扫原始明细表，查询耗时是常数级，哪怕总数据量到亿级也不会有性能波动。
     如果业务存在多种不固定的采样间隔，只需要预聚合最小粒度（比如1分钟）的桶，查更大间隔（比如5分钟）时直接从1分钟桶做二次聚合，扫描的数据量只有原始明细的1/60，性能依然远高于直接查明细。

• 索引精准点查（无预聚合时的最优选择，适合采样点时间固定对齐的场景）
  很多人第一反应是先把整个时间窗口的所有数据全捞到内存再挑采样点，这完全是没必要的性能浪费。如果你的采样间隔是和时间对齐的（比如5分钟间隔就是整0分、5分、10分这类时间点），直接在代码里生成所有采样点的目标时间戳，用timestamp IN [t1, t2...tn]的语句走timestamp索引精准匹配就行——要12个点就只查12条索引，根本不需要碰剩下的上千条明细，性能比全量扫窗口高几个数量级。

  如果存在时间戳不对齐、写入有毫秒级偏移或者延迟的情况，给每个目标采样点加一个极小的时间范围（比如目标时间戳前后2秒），每个范围只取最接近目标时间的1条记录即可，依然是走索引范围扫描，扫描的数据量可以忽略不计。

• 数据库原生分桶聚合（适合无预聚合、采样间隔灵活的场景）
  如果采样间隔不固定，没法提前生成所有采样点做精准点查，直接用数据库自带的时序聚合语法做分桶计算，不要自己在应用层捞全量数据再处理：原生聚合逻辑会在存储引擎层直接做索引裁剪，不需要把全量明细加载到内存，比自己写应用层处理逻辑性能高30%以上。
  通用的分桶聚合逻辑参考（以5分钟间隔取每个桶第一条数据为例）：

  db.collection.aggregate([
    // 第一步必须先走timestamp索引过滤时间窗口，把无关数据全部裁掉
    { $match: { timestamp: { $gte: 起始时间戳, $lte: 结束时间戳 } } },
    // 按采样间隔做时间分桶，不要在match阶段对timestamp做函数运算，否则会导致索引失效
    { $group: {
        _id: { $subtract: [ "$timestamp", { $mod: [ "$timestamp", 300 ] } ] }, // 300秒=5分钟
        sampled_value: { $first: "$value" },
        sampled_timestamp: { $first: "$timestamp" }
      }
    },
    // 按时间正序返回结果
    { $sort: { _id: 1 } }
  ])
  

  这种方案的性能瓶颈只在第一步时间过滤出的窗口总数据量，比如查1小时窗口只会扫描3600条记录，哪怕整个集合有几千万数据，因为有timestamp索引，过滤速度会非常快，完全能支撑高频查询。

避坑提醒 #

• 绝对不要把整个时间窗口的所有明细全部查到应用层内存再做采样：一旦时间窗口变大（比如查7天数据就是60多万条），网络IO、序列化的开销会指数级上升，高频查询下很容易把服务打挂。
• 不要在时间过滤的匹配阶段对timestamp字段做函数运算，比如写floor(timestamp/300) = 目标值，这种写法会导致数据库无法命中timestamp索引，触发全集合扫描，性能会暴跌几个数量级。
• 如果业务存在写入延迟、数据乱序的情况，预聚合逻辑要补一个定时校准机制，避免采样点数据不准。

内容的提问来源于stack exchange，提问作者Adam K Dean