azure - 为什么 RU 消耗高于预配置吞吐量与自动缩放最大吞吐量的比率？

Question

为什么 RU 消耗高于预配置吞吐量与自动缩放最大吞吐量的比率？

我所看到的:

• 自动缩放最大吞吐量为 220k
• 预配置吞吐量仅为 153k
• 但是 RU 消耗是 100%!

当预配置吞吐量远不及自动缩放最大吞吐量时，RU 消耗为何为 100%？即使在自动缩放模式下，RU 消耗是否也基于预配置吞吐量？如果是这样的话，那么是不是意味着不能使用 RU 消耗来确定数据库/容器的自动缩放最大吞吐量是否设置得太低或太高？

在自动缩放模式下，如何确定配置是否过多或不足？

Answer 1

100% 的标准化 RU 消耗指标仅意味着至少一个物理分区在至少一秒内使用了其整个 RU 预算(220k/物理分区数量)。

仅当几秒的滑动窗口内的平均标准化 RU 消耗足以保证时，自动缩放才会提高预配置吞吐量。具体the documentation states...

Azure Cosmos DB only scales the RU/s to the maximum throughput whenthe normalized RU consumption is 100% for a sustained, continuousperiod of time in a 5-second interval

由于自动缩放的计费基于任何一小时内达到的峰值配置 RU，直接使用标准化 RU 消耗指标可能会对该小时的计费产生相当可怕的乘数影响(单个繁忙分区在非典型的一秒内)然后将产生乘以集合中的分区数 * 一小时内的秒数 * 帐户地理复制到的区域数的效果)

关于您是否过度配置或配置不足，您的图表上确实有一些平坦的线，您已经达到了自动缩放最小值 - 并且您在所覆盖的时间段内从未达到自动缩放最大值(尽管在5 月 8 日)因此，在此基础上，您的配置可能有些过度 - 这实际上取决于您愿意支付多少溢价来降低出现限制的风险。

我认为标准化 RU 消耗本身并不是一个非常有用的指标，因为它无助于区分执行周期性昂贵操作的集合和持续压力下的集合。例如。如果您有一个 40,000 RU 的集合和 80 个物理分区，则“每秒每个分区”预算为 500 RU。如果文档很大并且您有通配符索引，则单个插入可能可以做到这一点，因此一致的插入可以使集合在该指标上永久显示为最大(不过，您可以按物理分区拆分该指标并验证是否您只是获得特定分区的峰值，而其他分区则更加空闲，以及它是否始终是相同的“热”分区 - 正如“经典”指标中的热图所示)。

另一种查看方式是每秒的最大吞吐量为 220k。所以理论上可以维持每分钟13,200,000 RU。您可以查看所使用的请求单位的指标，并查看您的峰值分钟数，以了解您与该理论最大值的接近程度。如果您从未接近此目标(只要您的工作均匀分布在各个分区上)，您可能会得出结论，存在缩小的范围 - 并且只需重试任何受限制的请求，因为任何峰值都可能非常短暂。