.png)
Observe.AI 如何利用 MongoDB 重分片扩展其 AI 平台
内容提要
Observe.AI 的 AI 平台以 MongoDB Atlas 为数据层，存储对话与模型配置，支撑超100个集群、50TB数据。随着数据增长，原两分片集群容量吃紧。团队与 MongoDB 合作，通过在线 resharding 将约50TB生产数据重新分布到新增分片，而非仅依赖均衡器迁移。迁移期间读写基本不中断，仅提交阶段短暂阻塞写入，最终扩展了容量、降低了风险，并为持续增长留出空间。
延伸解读
为何选择重分片而非均衡器迁移
文章指出，默认的均衡器迁移适合日常增量平衡，但面对约50TB的大规模数据重分布，仅靠chunk迁移会拉长窗口，并让原分片持续承压。团队还面临范围删除带来的后台负载和WiredTiger缓存压力，因此选择在线重分片作为更快、更可控的初始迁移手段，均衡器则继续负责后续微调。
迁移期间对生产流量的影响
根据文章，重分片在克隆和追赶阶段，生产读写基本不中断，只有最终提交阶段需要短暂阻塞写入。团队还通过禁用范围删除、禁止关键集合的chunk迁移，避免重分片与均衡器、范围删除器争抢IOPS。这说明在线重分片并非完全无感，但可将影响控制在有限窗口内。
分片扩容后的容量与运维收益
迁移后，集群从磁盘余量紧张转为拥有数月容量空间，多TB大集合被重新分布到更多分片，原分片压力下降。文章强调，这为后续数据摄入增长、维护和运维灵活性留出空间，均衡器也回归日常增量平衡角色。重分片由此被视为主动容量管理工具，而非一次性应急操作。
对采用MongoDB分片架构的启示
文章认为，不应把分片视为最后手段而拖延，否则单副本集过大、运维风险和后续平衡成本会更高。借助MongoDB 8.0起提供的重分片能力，可以从小规模起步、随业务增长逐步扩容，并在需要时以可预测的方式重新分布数据。Observe.AI的案例表明，水平扩展与重分片结合可用于生产关键型AI平台。
Q&A
Observe.AI 为什么需要对 MongoDB 集群进行重分片？
原集群只有两个数据分片，每个分片约13TB压缩数据（总计约50TB未压缩），磁盘限制约14TB，剩余空间有限。每日约50GB的持续写入使得容量吃紧，可能引发性能问题或服务降级，因此需要扩展分片以增加容量和降低风险。
Observe.AI 的重分片方案具体包含哪些步骤？
方案分四步：1) 增加多个新分片以扩展集群容量；2) 准备集群：确保无进行中的迁移或重分片任务，固定配置服务器，禁用范围删除并禁止关键集合的块迁移；3) 对最大的几个集合依次执行 reshardCollection，保持分片键不变但改变数据分布；4) 清理：移除旧空分片和临时区域配置，重新启用均衡和范围删除。
为什么 Observe.AI 不只用 MongoDB 的均衡器来迁移数据？
均衡器适合持续的增量平衡，但本次需要迁移的数据量很大，仅靠块迁移会延长迁移窗口，使原分片长时间承受高压。此外，范围删除会带来额外后台负载，且原分片已存在 WiredTiger 缓存压力。因此团队选择更快速、可控的重分片机制来处理大规模数据移动。
重分片过程中对生产读写有什么影响？
在克隆和追赶阶段，生产读写持续进行，基本不中断；仅在最后的提交阶段需要短暂阻塞写入。整个迁移对客户几乎无感知。
重分片后集群获得了哪些好处？
集群从磁盘空间受限变为拥有数月的容量余量；大型多TB集合被重新分布到更多分片，减轻了原分片的持续压力；为未来数据增长、维护和运营灵活性留出空间；均衡器回归增量平衡角色，重分片则用于大规模数据移动。
MongoDB 的重分片功能从哪个版本开始可用？
重分片功能自 MongoDB 8.0 版本（2024年发布）开始提供。
