Question

我们为各种集合每秒保留了各种数量的RU。我正在尝试优化以节省成本。对于Cosmos的每个响应，我们都将请求费用属性记录到Application Insights。我有一个分析查询，它返回每秒平均请求单位数，而一个返回最大值。

let start = datetime(2019-01-24 11:00:00);
let end = datetime(2019-01-24 21:00:00);
customMetrics
| where name == 'RequestCharge' and start < timestamp and timestamp < end
| project timestamp, value, Database=tostring(customDimensions['Database']), Collection=tostring(customDimensions['Collection'])
| make-series sum(value) default=0 on timestamp in range(start, end, 1s) by Database, Collection
| mvexpand sum_value to typeof(double), timestamp limit 36000
| summarize avg(sum_value) by Database, Collection
| order by Database asc, Collection asc

let start = datetime(2019-01-24 11:00:00);
let end = datetime(2019-01-24 21:00:00);
customMetrics
| where name == 'RequestCharge' and start <= timestamp and timestamp <= end
| project timestamp, value, Database=tostring(customDimensions['Database']), Collection=tostring(customDimensions['Collection'])
| summarize sum(value) by Database, Collection, bin(timestamp, 1s)
| summarize arg_max(sum_value, *) by Database, Collection 
| order by Database asc, Collection asc

平均值很低，但在某些情况下最大值却高得令人难以置信。一个极端的例子是具有1,000个预留量的集合，平均使用量为15,59，最大使用量为63,341 RU / s。

我的问题是：怎么可能？我的查询错了吗？节流不起作用吗？还是节流只能在比一秒钟更长的时间内工作？我已经在Azure Cosmos DB概述仪表盘上检查了请求限制（响应代码429），但是没有。

Answer 1

我必须回答自己。我发现了两个问题：

Application Insights记录了不正确的时间戳记。我添加了一个时间戳作为自定义维度，并且在一分钟之内，我的自定义时间戳获得了不同的秒数，但是对于许多此类时间戳而言，内置时间戳比分钟要晚一秒。这就是为什么我在请求费用上达到（错误）峰值的原因。
我们确实节流了。当门户网站观看请求限制，我必须选择一个特定的数据库。如果我尝试查看所有数据库的请求限制，那么似乎没有任何限制。

如何使用Azure Cosmos DB消耗超过保留数量的请求单元？

1 个答案: