DBA 手册 — Cosmos Optimizer 分步

§2 每个 pane 的演练

每个 pane 一个章节。每个都有:截图(可用时)、它显示什么、分步测试、繁忙生产 cluster 上的预期结果,以及常见问题的 troubleshooting 注释。

您的 Cosmos 账户消耗的 RU/s 与您设置的 budget 的实时视图。24h Holt-Winters 预测。比较 manual / autoscale / serverless / reserved 的 Recommendation card。

测试步骤

1. 将 RU/s budget 设置为您账户的 provisioned 吞吐量(例如 database-level 5k RU/s provisioning 设为 5000)。
2. 点击 Refresh。
3. 观察 Consumed(avg):在活动 cluster 上应非零。与您在 Azure Portal 的 Metrics → NormalizedRUConsumption 中看到的值进行比较。
4. 检查 Utilisation 徽章颜色:绿色 = 低于 65%、黄色 = 65-85%、红色 = 高于 85%。红色意味着紧急考虑 scale-up。
5. 阅读 Recommendation card。常见输出:steady workloads → RESERVED-3Y、spiky → AUTOSCALE、low-volume bursts → SERVERLESS。
6. 滚动到 Per collection(preview)。仅使用 Azure Monitor 时,您看到单个实例行汇总所有内容 — per namespace 需要 Log Analytics(PAID tier)。

捕获您通过 NoSqlStudio 运行的每个 query 的 x-ms-request-charge 响应头。零 Azure API 调用 — 纯客户端检测,始终可用。

测试步骤

1. 针对 Cosmos collection 打开 Shell 或 Query tab。
2. 运行繁重 query,例如 db.Deals.find({ status: 'closed' }).limit(100) 或 db.Deals.aggregate([{$match:{}}, {$group:{_id:'$status', n:{$sum:1}}}])。
3. 返回 Query Cost tab。Top query shapes 应填充 shape、总 RU、平均 RU、p95、max 和 count。
4. 运行相同的 shape 5+ 次以正确填充 count 和 p95。
5. 使用右上角的 filter 输入框缩小到 ns 或 shape 子串。

主动探测,按您的 partition key 对文档分组,并按文档数对结果分区进行排名。在它变成 429 throttle 风暴之前发现 skew(一个分区持有 40%+ 的文档)。

测试步骤

1. 填写 Namespace:db.coll 格式,例如 catalog.products。
2. 填写 Partition key path:创建 collection 时您用作 shardKey 的字段名,例如 tenantId。
3. 点击 Scan。这在 Cosmos 上运行 $group aggregation — 消耗的 RU 与 collection 大小成正比。在 200 GB collection 上预计 100-500 RU。
4. 阅读右上角的 spread 徽章:绿色 = 均匀分布、黄色 = 适度 skew、红色 = 严重 skew(top partition > 40% 的文档)。
5. 使用 heatmap 发现特定的热分区。在任意单元格上 hover 以获取确切的键值 + 文档数。

Cosmos 默认索引每个属性 — 每个 write 为每个索引属性消耗 1 RU。排除从不查询的 paths 可以在 document-heavy collections 上减少 30-70% 的 write RU 消耗。

测试步骤

1. 填写 Namespace,例如 catalog.products。
2. 点击 Sample schema。NoSqlStudio 读取 100 个文档并构建所有 field paths 的树。
3. 取消选择从不出现在 WHERE / filter 子句中的任何字段 — 想想 imageBase64、fullText、metadata.audit.* 等。
4. 点击 Save draft。JSON 预览更新为提议的 indexingPolicy。
5. 复制 JSON,通过 shell 应用:db.runCommand({collMod: 'products', indexingPolicy: <paste>})。

从最近 15 分钟的指标对您的 workload 进行分类(STEADY / SPIKY / CYCLIC / RAMP),然后并排模拟 5 个 Cosmos 计费模式的月度账单。底部 Reserved Capacity quote。

测试步骤

1. 点击右上角的 Refresh。
2. 阅读 Workload classification card。常见输出:STEADY(低方差,CV < 0.4)、SPIKY(CV > 0.8,推荐 autoscale)、CYCLIC(可预测的每日峰值,推荐带 scheduled scale 的 reserved)。
3. 比较 5 个 Monthly bill cards。带 RECOMMENDED 徽章的最便宜的是算法的选择。
4. 在 manual card 上查找红色 THROTTLED banner:表示您当前的 p95 超过模拟的 tier 并会导致 429s。
5. 滚动到 Reserved capacity quote:要承诺的具体 RU/s 数字 + 与 manual 相比的月度节省。

通过 Azure Monitor 计数最近 window 中的 429(rate-limited)响应,然后将每个 burst 与 Query Cost ring buffer 中捕获的 queries 关联。Surface 出 429 window 期间累积 RU 最高的 query shape — 可能的元凶。

测试步骤

1. 点击 Refresh。阅读 Total 429s、429 events 和 Peak / interval。
2. 设置 Window ± minutes 输入(默认 5)。降低以获得更紧密的关联,如果没有 query 落在 window 中则提高。
3. 滚动到 Suspect queries。每行 = 一个 429 burst,带在 burst 的 ± window 分钟内运行的最昂贵 query shape,带置信度得分(0-1)。
4. 如果为空:打开 Query Cost Inspector tab 并运行流量。没有 query captures,RCA 无法关联任何内容。

针对您 Log Analytics workspace 中的 Cosmos Diagnostic Logs 的 10 个即用 Kusto queries。需要 PAID tier(Diagnostic Settings 已启用,Log Analytics workspace ID 已配置)。

测试步骤

1. 验证 AZURE MONITOR banner 显示 upgrade available: Log Analytics。如果您未插入 workspace ID,此 pane 显示 NO SOURCE,Run in app 按钮被禁用。
2. 点击任意 template card(例如 Slow queries — last 1 hour)将其 KQL 加载到编辑器中。
3. 点击 Edit 内联调整 KQL(例如将 ago(1h) 改为 ago(24h))。
4. 点击 Run in app。结果表在 2-5 秒内在下方渲染。
5. 对于长篇分析,点击 Open in portal 将 query 深度链接到 Azure Portal KQL 编辑器。

观察 Query Cost ring buffer,识别触及 2+ 字段但缺少相应 composite index 的 query shapes,预测约 60% 的 RU 节省,发出可粘贴到 Cosmos indexingPolicy 的 JSON 片段。

测试步骤

1. 设置 Min queries to consider = 5(默认)。考虑某 shape 值得推荐的阈值。
2. 通过 NoSqlStudio 运行代表性 queries ~5 分钟。多字段 filter 示例:{tenantId: X, status: Y}、{userId: A, createdAt: {$gte: ...}}。
3. 返回这里。Recommendations 列表填充 shape + 预计 RU 节省 + JSON 片段。
4. 点击任意推荐上的 Copy JSON,通过 collMod 粘贴到您的 Cosmos collection 的 indexingPolicy 中。

灾难恢复 wizard。在 Cosmos continuous-backup window 中选取一个点(根据配置的策略 7 或 30 天),生成 az cosmosdb restore CLI 命令,可选地通过 host shell 执行。

测试步骤

1. 填写 Account(Cosmos 账户名称)。
2. 通过 slider 或 ISO-8601 输入设置 Restore timestamp。默认:现在减 1 小时。
3. 填写 Target account name(必须是新的 — 不能覆盖 source)和 Region。
4. 点击 Validate plan。NoSqlStudio 运行 az cosmosdb show-backup-information 确认该 timestamp 存在备份。返回绿色 check 或红色 error。
5. 准备就绪后点击 Run via host shell(az-cli)。Restore 对于典型 collections 需要 30-90 分钟。

双向 migration 助手。选择 source + target(Atlas → Cosmos 或 Cosmos → Atlas),显示 translation matrix(变为不支持的 features),预测目标上的月度账单,生成 mongosh script。

测试步骤

1. 选择 Source 和 Target:Atlas → Cosmos 或反之。
2. 阅读 Translation matrix:迁移后不保留的 features(例如 Atlas Search → Cosmos:通过 NoSqlStudio 多 DB 引擎本地工作,而非原生;Cosmos PITR → Atlas:由 Atlas cluster snapshots 替代)。
3. 检查 Bill projection:基于您当前 workload 的目标上的估计月度成本。
4. 点击 Generate script。输出是一个带 insertMany 批次和进度报告的 mongosh script。
5. 对于真实迁移,先在测试 collection 上 dry-run(Cosmos 在迁移期间对 inserts 收取 write RU!)。

用于决定哪些数据源为每个其他 pane 提供数据的控制面板。三个层级:TIER C local(始终开启)、TIER B Azure Monitor(FREE)、TIER A Log Analytics(PAID)。

测试步骤

1. 确认如果您保存了凭据,TIER B card 显示 CONFIGURED 徽章。
2. 敏感字段(Resource ID、Tenant ID、Client ID、Client Secret、Workspace ID)显示为带 Edit 按钮的 •••••••XXXX 掩码。点击 Edit 显示 + 更改,然后 Mask 再次隐藏。
3. Save 后:每个指标 pane 上的 source-mode banner 在 < 100 ms 内翻转为 AZURE MONITOR(通过内部事件),或最多 15 s(通过 poll 回退)。
4. Clear 按钮(红色)从磁盘擦除此连接的凭据 + 移除 bridge — 一切恢复为 NO SOURCE / Local samples。