基于Node.js参考MongoDB时间序列博客方案更新数据库表结构

基于MongoDB官方针对时间序列数据的Schema设计最佳实践，我给你整理了适配内存使用监控场景的文档结构，顺便拆解下每个字段的作用，方便你快速落地：

字段功能拆解 #

• _id: MongoDB默认生成的ObjectId主键，确保每一条文档的唯一性，不用手动维护
• mapped_id: 关联的实体标识（比如服务器ID、设备ID），用来标记这条时间序列数据属于哪个监控对象，方便后续按维度筛选
• timestamp_hour: 这条聚合数据对应的整点时间戳，是整个时间序列的时间锚点——按照官方思路，把一小时内的细粒度数据聚合到同一个文档下，能大幅减少文档总数，提升查询效率
• type: 数据类型标记，这里固定为memory_used，如果后续要扩展CPU、磁盘等其他监控指标，直接通过这个字段区分即可
• values: 嵌套式的聚合存储结构：外层键是小时内的分钟数（0到59），内层键是分钟内的15秒间隔点（0、15、30、45），对应的值就是该时间点的内存使用量，完美匹配你需要的时间粒度

示例文档 #

{ 
  "_id" : ObjectId("5aab763d455a20153c05f024"), 
  "mapped_id" : "5aaa21bdbf3dce44c41f1ba9", 
  "timestamp_hour": ISODate("2018-03-29T11:00:00.000Z"), 
  "type": "memory_used", 
  "values": { 
    "0": { "0": 123, "15": 213, "30": 563, "45": 784}, 
    "1": { "0": 134, "15": 632, "30": 489, "45": 893}, 
    // ... 省略2到57分钟的中间数据
    "58": { "0": 301, "15": 278, "30": 342, "45": 299} 
  }
}

额外实用建议 #

• 索引优化：给mapped_id + timestamp_hour + type创建复合索引，能极大提升按设备、时间范围、指标类型组合查询的速度
• 写入逻辑：写入数据时先判断对应timestamp_hour的文档是否存在，存在则用$set更新对应分钟、秒数的数值，不存在再插入新文档，避免重复创建
• 数据清理：可以给timestamp_hour添加TTL索引，设置自动过期时间，让MongoDB自动清理老旧的监控数据，节省存储空间

内容的提问来源于stack exchange，提问作者Yash Chapaneri