MongoDB冷热数据分离的Tag-Aware Sharding实现

首先明确结论：MongoDB 的标签感知分片（Tag-Aware Sharding）确实是实现冷热数据物理分离最直接的方式，但许多人在实际落地时遇到了问题。本文将详细拆解几个关键的技术约束，特别是文档中提及但容易被忽略的细节。

Tag-Aware Sharding 必须配合分片集群，副本集打 tags 没用

在副本集中为节点添加 tags 只能影响读请求的路由策略（通过 readPreferenceTags），对写入毫无作用。要实现冷热数据的物理隔离——例如将冷数据存储在低速廉价磁盘上，热数据存储在高性能 SSD 上——必须使用分片集群，并配合 tag-aware sharding。否则，所谓的“分离”只是在读取时绕开了冷节点，写入操作仍然打到主节点并同步到从节点，冷节点的磁盘依然承受复制流量，既无法降低成本，也无法达到隔离效果。

几个关键判断点：

• 如果还在使用副本集，不要试图通过 tags 来控制写入路径，架构层面不支持
• 如果已经使用了分片集群，但未开启 balancer 或未设置 tag range，那么单独调用 sh.addShardTag() 只是在元数据层面打标，数据不会自动移动
• 确认环境：sh.status() 输出中必须能看到 shards 和 balancer 的状态信息
• 冷热标签是打在 shard 上的，而不是 mongod 进程或某个副本集成员
• 标签值只能是字符串，例如 "tier": "cold"，不能使用数字或布尔值

sh.addTagRange() 的范围必须覆盖全生命周期数据，不能只标“过去”

一个常见的错误做法是只给历史数据添加 tag range。例如只写一段：sh.addTagRange("db.col", { createdAt: MinKey }, { createdAt: ISODate("2023-01-01") }, "cold")。这样会导致新产生的数据（createdAt > 2023-01-01）没有对应的标签路由规则，它们会按照默认的 chunk 分配路径走，很可能全部压到同一个 shard 上，冷热边界瞬间被打破。

正确的做法是，用两段互斥的 range 把整个键空间全覆盖：

sh.addTagRange("db.col", { createdAt: MinKey }, { createdAt: ISODate("2023-01-01") }, "cold")sh.addTagRange("db.col", { createdAt: ISODate("2023-01-01") }, { createdAt: MaxKey }, "hot")

这里有几个容易出错的细节：

• MinKey 和 MaxKey 是 MongoDB 的内置常量，不是字符串，不要加引号
• 两个 range 必须首尾相接，中间不留空隙，也不能重叠——类似于为书签卡格子，边界要精确衔接
• 分片键必须是 createdAt 字段或以它为前缀，否则 range 定义不会生效

chunk 迁移不会立刻发生，得等 balancer 触发 moveChunk

执行完 sh.addShardTag() 和 sh.addTagRange() 后，数据不会立即飞到目标 shard 上。MongoDB 的 balancer 按周期检查 chunk 分布，发现不合规的才触发 moveChunk。因此：

• 刚设置完 tag range 时，sh.status() 中看到的 chunk 可能还在原 shard 上，这是正常的
• 如果 balancer 关闭了（调用了 sh.setBalancerState(false)），迁移永远不会发生
• 迁移过程会消耗网络和 I/O，大 chunk（默认64MB）在迁移期间可能对查询延迟产生影响
• 可以手动触发一次均衡：sh.startBalancer()（如果之前关闭了），等几分钟再查看 sh.status() 以确认分布情况

验证效果时，不能只看元数据配置，要看实际 chunk 分布。例如运行这条命令：db.getSiblingDB("config").chunks.find({ "min.createdAt": { $lt: ISODate("2023-01-01") } }).count()，然后与 cold shard 上的 chunk 数量做对比，看是否匹配。

热数据写入变慢？检查 shard key 是否导致写热点

如果使用时间字段（如 createdAt）作为分片键并采用范围分片，一个经典问题就是写热点：所有新数据都落在同一个 chunk 的末尾，该 chunk 所在的 shard 成为写入瓶颈。这与 tag 策略无关，而是分片键设计本身的缺陷。

缓解办法都有取舍：

• 换用哈希分片：{ createdAt: "hashed" }，代价是失去按时间范围直接查询的能力
• 使用组合分片键：例如 { region: 1, createdAt: 1 }，将地域维度前置，分散写入压力
• 预分片：上线前用 sh.splitAt() 主动切分 chunk，避免所有新数据一开始就挤在一个 shard 上

这里不再展开，但需要记住一点：tag-aware sharding 解决的是“数据应该存到哪”的问题，解决不了“数据怎么写进去”的性能瓶颈。写性能的根源在于分片键设计。标签只是后续路由的一层过滤规则。