轨迹点直存集合必然碎片化，因小文档（
地理空间轨迹数据（如 GPS 点流）极易引发 WiredTiger 存储碎片——每秒写入一条 {loc: {type:"Point", coordinates:[121.47,31.23]}, timestamp: ISODate(...), speed: 45.2}，文档极小但数量巨大，_id 若无序或更新频繁，会直接触发大量文档移动和页分裂。
为什么轨迹点直存集合必然碎片化
单条轨迹点文档通常不足 200 字节，WiredTiger 默认按幂级大小（power-of-2）分配空间（如 256B → 512B），但小文档实际占用远低于分配量；更关键的是，若你用业务 ID、UUID 或逆序时间戳作 _id，新点无法追加到 B-tree 末尾，而是在中间反复插入 → 节点分裂 + 空间重用失败 → storageSize / dataSize 比值快速跌破 0.4。实测 50 万点后，db.collection.stats() 中 moves 字段每秒超 200，写入吞吐下降 40% 以上。
用轨迹桶（Track Bucket）替代单点文档
核心是把“按设备+时间段”聚合为一个文档，用数组存原始点，而非每点一文档。例如：一个设备每 5 分钟生成一个桶文档：
{
_id: ObjectId("6b1a2f..."),
device_id: "dev-8821",
bucket_start: ISODate("2026-09-07T12:00:00Z"),
bucket_end: ISODate("2026-09-07T12:05:00Z"),
points: [
{ loc: { type: "Point", coordinates: [121.47, 31.23] }, timestamp: ISODate("2026-09-07T12:00:01Z"), speed: 42.1 },
{ loc: { type: "Point", coordinates: [121.471, 31.232] }, timestamp: ISODate("2026-09-07T12:00:03Z"), speed: 43.5 }
],
metadata: { point_count: 120, max_speed: 89.7, bbox: [121.46, 31.22, 121.48, 31.24] }
}
- 桶时间粒度选 5–30 分钟：太短（如 1 分钟）仍会产生大量小文档；太长（如 1 小时）导致单文档过大、更新困难
-
_id必须用有序 ObjectId：可基于bucket_start生成，例如ObjectId(bucket_start.getTime().toString(16) + "0000000000000000")，确保写入局部性 - 给
points数组预设合理上限（如 500 点），并在插入前用$push+$each+$slice控制长度，避免无限增长 - 必须建复合索引：
{device_id: 1, bucket_start: 1}支撑按设备查时段；若需地理范围查询，再加 2dsphere 索引在metadata.bbox或整个points.loc（注意：对数组字段建 2dsphere 索引会产生多键索引开销）
避免桶文档更新引发移动
桶文档不是只读的——可能需要追加新点、修正坐标或补充元信息。但 $push 到 points 数组会改变文档大小，极易触发移动。解决方法只有两个：
- 首次插入桶时，就用完整结构 + 占位数据预填充：比如预期最多 500 点，就先插入含 500 个空对象的数组
points: [{}, {}, ...]，再用$set覆盖具体字段。空对象本身不占空间，但 BSON 序列化后能预留基础长度 - 更可靠的做法：用固定长度字段代替变长字段。例如将
speed存为Int32（非 double），timestamp用毫秒整数（非ISODate），coordinates存为[Double, Double]而非嵌套对象——所有字段字节长度可控，$set更新不会改变总长度 - 绝对不要在桶文档中用
$addToSet或$pull：它们会重排数组，破坏长度稳定性
分片键与 TTL 配合控制生命周期
轨迹数据天然有时效性，不能只靠文档设计，还要配合存储策略：
- 分片键必须包含
device_id和时间维度，推荐{device_id: "hashed", bucket_start: 1}：避免热点（全写一个分片），又保证同一设备的桶尽量共置，提升范围查询效率 - 务必建 TTL 索引在
bucket_end字段：db.tracks.createIndex({bucket_end: 1}, {expireAfterSeconds: 0})，MongoDB 会在bucket_end过期后自动删除整个桶文档，比应用层定时清理更可靠、更低开销 - 注意：TTL 删除不立即释放磁盘空间，需后续
compact或迁移；但对分片集群（MongoDB ≥ 7.0），后台自动合并数据段已大幅降低手动干预需求
真正容易被忽略的是：桶文档的 metadata.bbox 必须由应用层实时维护——它不仅是查询加速器，更是避免全桶扫描的底线。一旦漏算或延迟更新，地理围栏类查询就会退化成遍历整个 points 数组，所有文档设计优化都归零。
