分桶建模是秒级/分钟级物联网数据的刚性设计约束，必须按时间窗口+业务实体组合键定义桶，如“2026072108:sensor_8844”，并用upsert+$push+$inc原子写入，避免索引爆炸与数据污染。
分桶建模的核心判断：每分钟一条数据，必须用桶
直接说结论：如果你的物联网设备（比如传感器、飞机ADS-B、车载终端）以秒级或分钟级持续上报，且单设备年数据量超百万条，不使用分桶建模就是自找麻烦。它不是“可选优化”，而是避免索引爆炸、磁盘耗尽、查询变慢的刚性设计约束。
怎么定义一个合理的桶？看时间粒度和业务语义
桶的本质是时间窗口 + 业务实体的组合键。不能拍脑袋定“1小时”，得结合三点：
- 查询最常按什么范围查？——如果是运维看板查“过去24小时每小时平均温度”，那桶就该按
hour切；如果是做故障回溯查“某次飞行全程轨迹”，桶就得按flight_id+date聚合 - 单桶内数据量是否可控？——MongoDB单文档上限16MB，按每条记录约100字节算，1小时60条才6KB，安全；但若设备上报频率升到每秒1条，1小时3600条≈360KB，仍远低于上限，可接受
- 是否需要预聚合？——如果业务总要算桶内均值、最大值、采样点数，就在桶文档里加
sum_temp、max_temp、count字段，写入时一并更新，避免查时$unwind再$group
典型桶 ID 设计："2026072108:SENSOR_8844"（YYYYMMDDHH + 设备ID），确保唯一、可排序、无特殊字符。
写入逻辑必须原子化：用upsert + $push + $inc
不能先查再插，否则并发写会丢数据。正确姿势是用一条原子操作完成“新增桶”或“追加数据”：
db.sensor_readings.updateOne(
{ _id: "2026072108:SENSOR_8844" },
{
$push: {
measurements: {
timestamp: ISODate("2026-07-21T08:15:22Z"),
temp: 23.4,
humidity: 65
}
},
$inc: { count: 1, sum_temp: 23.4 },
$setOnInsert: {
sensor_id: "SENSOR_8844",
start_time: ISODate("2026-07-21T08:00:00Z"),
end_time: ISODate("2026-07-21T08:59:59Z")
}
},
{ upsert: true }
)
注意：$setOnInsert只在新建文档时生效，避免覆盖已有元信息；$inc保证预聚合字段强一致；measurements数组天然支持追加，不触发重写整个文档。
容易踩的坑：TTL索引和分片键别乱配
分桶后文档变少、变大，但两个地方极易翻车：
-
TTL索引必须建在桶文档的end_time（不是数组里每条记录的timestamp），否则删不掉整桶——MongoDB TTL 只检查根级字段 - 如果后续要分片，
shard key首选_id（即桶 ID），不要用sensor_id单独做分片键：前者自带时间局部性，能保证同一设备的桶大概率落在同个 shard，减少跨分片查询；后者会导致单设备数据被打散，查一小时数据要扫全部分片 - 数组字段
measurements上建索引意义极小——除非你真要按某条子记录的temp > 40精确查询，但这种需求几乎不存在；索引应集中在_id、sensor_id、start_time等根级字段
真正难的不是建桶，而是让所有写入服务（可能是几十个微服务或边缘网关）严格遵守同一套桶命名规则和更新逻辑。一旦某个环节漏掉$inc或错用$set覆盖了count，预聚合数据就不可信了——这种错误不会报错，只会悄悄污染分析结果。
