MongoDB 7.0支撑PB级车联网数据必须用{"vehicle_id":1,"ts":1}组合片键、显式预分片（如numInitialChunks:512）、全链路经mongos路由，否则单调ts片键引发写入热点、chunk过少导致balancer卡死、直连mongod使分片失效。
直接上结论：在 MongoDB 7.0 中支撑车联网 PB 级遥测数据，不能靠“加机器”或“随便选片键”，必须用 { "vehicle_id": 1, "ts": 1 } 组合片键 + 显式预分片 + mongos 全链路路由，否则写入热点、查询慢、balancer 卡死是必然结果。
为什么不能用 ts 单字段做片键
单调递增的时间戳（如 ISODate("2026-09-07T15:58:00Z")）会导致所有新上报数据持续写入同一个 chunk 所在的 shard，该节点 CPU 和磁盘 I/O 很快飙到 95%+，而其他 shard 几乎空闲。这不是负载不均，是架构级缺陷——MongoDB 7.0 不会自动“打散”单调值。
- 现象：
sh.status()显示某 shard 的 chunk 数远低于其他节点，但该 shard 的inserts指标持续暴涨 - 后果：写入延迟从几毫秒升至秒级，
moveChunk频繁失败并报NotMaster - 替代方案：必须引入高基数维度（如
vehicle_id）打散写入目标，再用ts保证单辆车内时间局部性
sh.shardCollection() 必须带 numInitialChunks
MongoDB 7.0 默认只创建 2 个初始 chunk，对日增千万文档的车联网场景完全不够用。chunk 过少 → 单个 chunk 过大 → 分裂压力集中 → balancer 长期处于高负载迁移状态。
- 正确做法：预估车辆总数（如长城汽车 700 万辆）和日均上报频次，按 256～1024 设置
numInitialChunks - 示例命令：
sh.shardCollection("fleet.telemetry", { "vehicle_id": 1, "ts": 1 }, { numInitialChunks: 512 }) - 注意：该参数仅在首次分片时生效，后续无法修改；若漏设，只能导出重建集合
所有读写必须走 mongos，绕过就等于没分片
很多团队在副本集上执行了 sh.addShard() 就以为分片完成，结果应用仍直连 mongod 地址（如 mongodb://shard1:27018），导致数据完全不分布、聚合查询失效、sh.status() 显示为空或报错 sharding not enabled。
- 验证方式：连接目标地址后执行
db.runCommand({isMaster:1})，返回中必须含"msg": "isdbgrid" - 连接字符串必须形如：
mongodb://mongos1:27017,mongos2:27017/?replicaSet=rs0 -
mongos实例本身无状态，可按读写压力横向扩容，不要卡在“只部署 1 个”
聚合查询必须适配分片规则，否则性能归零
在分片集群中，$group、$sort、$lookup 等操作若未包含片键前缀，MongoDB 7.0 会强制将所有相关 chunk 拉到一个 mongos 上合并处理，网络和内存开销剧增，10 亿文档聚合可能耗时数小时。
- 安全写法：所有聚合管道起始阶段必须有
{$match: {"vehicle_id": ...}}或完整片键匹配 - 避免全表扫描：不要用
{$match: {"ts": {$gte: ...}}}单独过滤，必须带上vehicle_id - 复杂分析需求（如跨车轨迹聚类）建议前置物化视图，用定期 job 写入汇总集合，而非实时聚合原始 telemetry
真正难的不是分片命令怎么敲，而是片键设计要同时扛住写入倾斜、满足业务查询路径、预留未来扩展余量——vehicle_id 和 ts 的顺序、方向（1 还是 -1）、是否加哈希等细节，在 PB 级规模下都会放大成运维事故。
