MongoDB分片键选择失误：数据倾斜的救火经历
问题发现
用户行为数据写入MongoDB集群，某个分片磁盘使用率达到95%，其他分片仅30%，数据分布严重不均。
根因分析
1. 分片键选择问题
// 错误的分片键设计
sh.shardCollection("user_behavior.events", { user_id: "hashed" })
使用用户ID哈希分片，但忽略了数据访问模式。
2. 数据特征分析
- 少数头部用户产生大量行为数据（20%用户占据80%存储空间）
- 时间序列特征明显，新数据集中在少数分片
- 热点用户集中在特定时间段活跃
3. 分布不均状况
- 分片A：800GB（95%使用率）
- 分片B：300GB（35%使用率）
- 分片C：320GB（38%使用率）
4. 热点集中问题
单个chunk过大无法分裂，导致数据持续写入同一分片。
应急处理
1. 临时扩容
# 给热点分片增加存储
mongo --eval "sh.addShardTag('shard0000', 'hotspot')"
mongo --eval "sh.addTagRange('user_behavior.events', {user_id: MinKey}, {user_id: MaxKey}, 'hotspot')"
2. 数据迁移
// 手动迁移部分chunk到其他分片
db.adminCommand({moveChunk: "user_behavior.events", find: {user_id: "hot_user_001"}, to: "shard0001"})
3. 查询优化
// 避免全分片扫描
db.events.createIndex({user_id: 1, timestamp: -1})
根本解决
1. 重新设计分片键
// 复合分片键：用户ID + 时间戳
sh.shardCollection("user_behavior.events", {
user_id: 1,
timestamp: 1
})
2. 数据重分布
// 通过mongos重新平衡集群
db.runCommand({reshardCollection: "user_behavior.events", key: {user_id: 1, timestamp: 1}})
3. 预分裂chunk
// 提前创建足够多的chunk
for(let i = 0; i < 1000; i++) {
sh.splitAt("user_behavior.events", {user_id: ObjectId(), timestamp: new Date()})
}
4. 监控告警设置
// 设置数据分布不均匀阈值
var ops = db.currentOp({"balancer.active": true});
if(ops.inprog.length > 0) {
print("Balancer is running");
}
经验总结
设计原则
- 分片键设计要考虑数据访问模式
- 避免单调递增的分片键值
- 考虑数据生命周期和热冷分离
预防措施
- 定期监控各分片数据分布情况
- 设置自动均衡阈值
- 建立数据倾斜预警机制
最佳实践
- 预分片设计：上线前充分评估数据特征
- 渐进式扩容：避免一次性大规模重分片
- 备份恢复策略：确保数据安全
效果验证
- 数据分布均匀性：95% → 45%（标准差）
- 写入性能稳定性：提升60%
- 查询响应时间：降低40%
- 运维工作量：减少80%
生产建议
- 上线前测试：使用生产数据进行分片测试
- 监控体系：建立分片状态监控面板
- 应急预案：准备数据重分布应急方案
- 定期评估：每季度评估分片策略有效性
