Hot Partition Detector
Cosmos 需要 partition key。糟糕的选择 = 一个分区承担 60% 的文档 + 90% 的 RU = 峰值时 throttle。今天 DBA 在应用宕机时才发现。Hot Partition Detector 按 partition key 运行 $group,测量每个分区的文档数 + 估计 RU,绘制为彩色 heatmap(cool blue → hot red),并在 top partition 占总量 > 40% 时触发告警。
它在应用中的位置: Tools → Cosmos DB → Hot Partition Detector
它做什么
- 针对所选 collection 的 $group + $bsonSize aggregation。
- 按文档数的渐进色(cool → hot)可视化 heatmap。
- Top-20 partitions,带 share % + 估计的 RU/day。
- Skew 告警:severe(>40%)/ moderate(>20%)/ ok(<20%)。
- 基于基数 + 均匀性的替代 partition key 的文本建议。
分步
- 1
打开 detector 并选择 collection
Tools → Cosmos DB → Hot Partition Detector。输入 namespace(例如 `app.orders`)和 partition key path(例如 `tenantId`)。
- 2
扫描
根据大小在 ~5-30s 内运行 agg。Limit 200 partitions;对于非常大的 collections,按 sub-range 重复。
- 3
阅读 heatmap
每个单元格 = 一个 partition key value。颜色 = 相对文档数。Hover 显示确切值。
- 4
决定
如果检测到严重的 skew,考虑:(a)复合 partition key(`tenantId+region`),(b)合成 hash key(`hash(naturalKey) mod N`),(c)collection 的逻辑拆分。先用 WHAT-IF Lab 模拟变更。
真实用例
企业客户主导
B2B SaaS 发现客户 "ACME Corp" 持有 `events` collection 73% 的文档。迁移到 composite `tenantId+eventBucket`(bucket = hash(eventId) mod 10)。最终分布:最大 partition 4.2%。
Timestamp 作为 partition key(反模式)
团队使用 `date` 作为 partition key。Heatmap 显示最后一天承担 90% 的吞吐量。迁移到 `tenantId` + query 中按 date 排序。p99 -45%。
FAQ
对 > 10M 文档的 collections 不起作用吗?
可以工作,但 $group 变得昂贵。考虑针对 $sample(10k 文档)运行以快速估计。
在更改 partition key 之前我可以测试吗?
可以 — WHAT-IF Lab 有 mutation kind `change-partition-key`,可以模拟对真实 workload 的影响。