应使用timeSeries集合，但需满足字段统一且有明确timeField；动态字段或需复合查询时退化为普通集合+TTL索引，并分离报警与轨迹存储以适配不同读写模式。
时序集合要不要用 timeSeries？
MongoDB 5.0+ 提供的 timeSeries 集合专为高频写入、按时间范围查询的场景优化，车联网轨迹点完全符合：每辆车每秒可能上报 1–10 条 GPS 记录，写入量大、查询常带 timestamp 范围（如“过去 2 小时轨迹”）。但直接建 timeSeries 集合有硬性前提：必须有一个明确的 timeField（如 ts），且数据结构高度统一——所有文档字段名、类型、嵌套层级要基本一致。
- 如果车辆上报字段动态变化（比如某些车加装了胎压传感器，某些没有），
timeSeries会拒绝写入或丢失字段，此时得退回到普通集合 + TTL 索引 -
timeSeries不支持二级索引以外的复合索引，若你常按vehicleId+alarmType查报警，就得额外建一个普通集合存报警摘要 - 写入吞吐提升明显（实测单节点写入 5k+/s 更稳），但聚合管道里不能用
$lookup关联其他集合，做“轨迹+车主信息”联合分析得靠应用层拼接
轨迹点怎么避免重复写入和时钟漂移？
车载终端网络不稳定，常出现重传、乱序、本地时钟不准（快/慢几秒甚至几分钟）。直接按设备上报的 timestamp 入库会导致轨迹跳变、速度计算错误。
- 在写入前，服务端统一用 NTP 校准时间，并生成一个单调递增的逻辑时间戳
ingestTs（比如用Date.now()+ 微秒级序列号），作为主时间字段；原始deviceTs仅作保留字段用于审计 - 对同一
vehicleId+deviceTs组合加唯一索引：{ vehicleId: 1, deviceTs: 1 }，防止重传覆盖 - 查询轨迹时，优先用
ingestTs排序和过滤；计算瞬时速度时，用相邻两帧的deviceTs差值（反映真实上报间隔），而非ingestTs差值（含网络延迟）
报警事件该不该和轨迹存在一起？
别这么做。轨迹是高密度、低价值密度的流式数据；报警是稀疏、高业务语义的事件，二者读写模式、生命周期、权限控制都不同。
- 报警单独建集合，用
alarmId（UUID）、vehicleId、alarmType（如"overspeed"、"geofence_exit"）、triggerTs（触发时刻）、context（JSON，含当时速度、位置、附近 3 个轨迹点）等字段 - 为支持“查某车最近 5 次急刹”这类查询，建复合索引：
{ vehicleId: 1, alarmType: 1, triggerTs: -1 } - 不在报警文档里嵌入完整轨迹数组——MongoDB 单文档 16MB 上限容易突破，且更新轨迹需全量重写报警文档；真要关联，查报警后按
triggerTs±5 秒去轨迹集合查附近点即可
如何支撑“实时超速预警+离线轨迹回放”混合负载？
一台 MongoDB 很难同时扛住每秒万级写入（轨迹）和毫秒级随机查询（回放某车某天任意 5 分钟轨迹）。得拆：
- 主写入库用分片集群，按
vehicleId哈希分片（保证单辆车数据不跨片，批量查轨迹快） - 实时预警走 Change Stream：监听轨迹集合插入，用
db.collection.watch([ { $match: { "fullDocument.vehicleId": { $exists: true } } } ])捕获新点，在内存里维护每车最近 N 个点（滑动窗口），满足超速、加速度突变等规则就立刻发告警 - 离线回放走归档库：每天凌晨把前一天轨迹按
vehicleId+date拆成独立集合（如track_20240520_vh123），用 TTL 索引自动过期；查历史轨迹时，先算出日期范围，再并行查多个集合，比在大集合里扫快得多
真正卡住落地的，往往不是模型多漂亮，而是车载时钟不准带来的数据错序、网络重传引发的重复写入、以及报警与轨迹耦合导致的查询僵化——这些细节没对齐，再好的时序设计也撑不过两周真实路测。
