Cosmos DB 请求单位消耗不匹配
CosmosDB RequestUnit Consumption Mismatch
我 运行 遇到了 CosmosDb 中 RU 消耗的问题。 Azure Insights 中的 Normalized RU Consumption 视图让我感到困惑。希望有人能帮忙解惑一下。
我们的应用程序创建大小为 8kb 的文档。 CosmosDb returns 每次创建 14 个请求单元的请求使用情况。有些请求有点轻，所以平均 RU 实际上较低。
这个创建动作每分钟执行280次，也就是每秒5个请求左右。
这意味着此过程每秒将消耗 5 x 14 = 70 个请求单元。
目前没有其他查询 运行ning.
总请求单位图表显示每 5 分钟 12.5K RU。这或多或少对应于计算出的使用量：12500/5min/60sec=41.6 Request Units per second。
如果我为那个容器提供 5000 RU/s，我实际上每秒提供 5000 个请求单位，对吧？ （RU/s 是每秒请求单位数？）
这意味着，当前设置每秒将消耗 5000 个单位中的 70 个，即配置容量的 70/5000*100=1.4%。
现在，如果我在 CosmosDb 下查看 Azure 门户中的 Insights 屏幕，它会显示一个图表“标准化 RU 消耗（最大）”。该图表表明我使用了 5000 [的 40%-50% RU/s 已配置。如果我将手动配置的吞吐量降低到 2000，则受限计数开始高于 0。所以很明显我们在那里遇到了一些障碍。
a) calculation/requests 图表和 b) 消费图表之间的差异几乎相差 35 倍。
一些进一步的信息：
- 天蓝色的总请求图表显示没有更多请求
执行。
- 分区键是合成的 yyyy-dd-
。
- TTL 为 7 天。
- 我们有 1 个物理分区和 20 个逻辑分区。
- 分区键均匀分布
- 单个区域。
- 总数据使用量为 10GB（数据 + 索引）。
- 该应用程序使用 REST API 创建文档。
谁能解释一下？或者知道如何解决这个问题？
ps:
Partitionkey distribution in 5 minutes:
0 2021-05-06 75
1 2021-05-07 57
2 2021-05-05 50
3 2021-05-19 56
4 2021-05-08 64
5 2021-05-11 71
6 2021-05-09 56
7 2021-05-12 70
8 2021-05-01 61
9 2021-05-10 55
10 2021-05-17 55
11 2021-05-03 65
12 2021-05-02 60
13 2021-05-18 52
14 2021-05-15 54
15 2021-05-04 71
16 2021-05-14 65
17 2021-05-16 61
18 2021-05-13 45
Items checked: 1143. Partitionkeys encountered: 19
更新一：REST 的使用API
更新二：
我已经按照@NoahStahl 的建议使用日志文件完成了研究。对 cosmosdb 的每个请求都记录在执行实际 HTTP 请求的客户端对象中。我没有找到隐藏的请求单元数。我确实找到了以下数字：
- 它 运行 有两个实例。每分钟这些实例一起处理 251 个请求。
- 一分钟内充电的 RU 总数为：2693（值介于 9.71、10.48、12.95 ... 之间）。
- 如果我们将其除以 60（秒），则对应于每秒消耗 44.8833 个请求单位。
所以它实际上证实了之前描述的差异。它没有接近每秒配置的 5000RU 的 40%-50%。
作为测试，我还从此应用程序中完全删除了日志记录。 Azure 中的 Consumed RU 图表降至 0。因此我认为可以安全地假设所有请求都来自该应用程序。
更新三：
更新四
请求单位的绝对数量也与我在日志中看到的一致。此图表中的时间轴为 4 小时。所以每一分都是5分钟。 5 分钟内 +/- 12K RU 的值，相当于每秒 40 RU。
为了说明这个问题已经解决，我把评论中的片段放在这里以阐明解决方案：
@noahstahl 添加了此评论：
鉴于您的预期吞吐量与目睹的节流之间的巨大差异，您似乎有一些操作比您想象的更昂贵，或者更突发。我会尝试在应用程序代码中实现更精细的日志记录，例如在这个例子 youtu.be/Tht_RV5QPJ0?t=2964
'bursty' 评论是指向解决方案的指针。每分钟的平均数都还可以，因此预期使用情况与所需的容量配置之间似乎存在很大差距。但是，如果您每秒查看一次（通过使用日志），很明显有些秒没有任何流量，而其他秒看到的流量就 RU 而言要高得多。通过修复这些爆发，一切都回到了 'as expected'。
附带说明一下，@noahstahl 的视频看起来很有趣。感谢分享！
我 运行 遇到了 CosmosDb 中 RU 消耗的问题。 Azure Insights 中的 Normalized RU Consumption 视图让我感到困惑。希望有人能帮忙解惑一下。
我们的应用程序创建大小为 8kb 的文档。 CosmosDb returns 每次创建 14 个请求单元的请求使用情况。有些请求有点轻，所以平均 RU 实际上较低。
这个创建动作每分钟执行280次，也就是每秒5个请求左右。 这意味着此过程每秒将消耗 5 x 14 = 70 个请求单元。 目前没有其他查询 运行ning.
总请求单位图表显示每 5 分钟 12.5K RU。这或多或少对应于计算出的使用量：12500/5min/60sec=41.6 Request Units per second。
如果我为那个容器提供 5000 RU/s，我实际上每秒提供 5000 个请求单位，对吧？ （RU/s 是每秒请求单位数？） 这意味着，当前设置每秒将消耗 5000 个单位中的 70 个，即配置容量的 70/5000*100=1.4%。
现在，如果我在 CosmosDb 下查看 Azure 门户中的 Insights 屏幕，它会显示一个图表“标准化 RU 消耗（最大）”。该图表表明我使用了 5000 [的 40%-50% RU/s 已配置。如果我将手动配置的吞吐量降低到 2000，则受限计数开始高于 0。所以很明显我们在那里遇到了一些障碍。
a) calculation/requests 图表和 b) 消费图表之间的差异几乎相差 35 倍。
一些进一步的信息：
- 天蓝色的总请求图表显示没有更多请求 执行。
- 分区键是合成的 yyyy-dd-
。 - TTL 为 7 天。
- 我们有 1 个物理分区和 20 个逻辑分区。
- 分区键均匀分布
- 单个区域。
- 总数据使用量为 10GB（数据 + 索引）。
- 该应用程序使用 REST API 创建文档。
谁能解释一下？或者知道如何解决这个问题？
ps:
Partitionkey distribution in 5 minutes:
0 2021-05-06 75
1 2021-05-07 57
2 2021-05-05 50
3 2021-05-19 56
4 2021-05-08 64
5 2021-05-11 71
6 2021-05-09 56
7 2021-05-12 70
8 2021-05-01 61
9 2021-05-10 55
10 2021-05-17 55
11 2021-05-03 65
12 2021-05-02 60
13 2021-05-18 52
14 2021-05-15 54
15 2021-05-04 71
16 2021-05-14 65
17 2021-05-16 61
18 2021-05-13 45
Items checked: 1143. Partitionkeys encountered: 19
更新一：REST 的使用API 更新二： 我已经按照@NoahStahl 的建议使用日志文件完成了研究。对 cosmosdb 的每个请求都记录在执行实际 HTTP 请求的客户端对象中。我没有找到隐藏的请求单元数。我确实找到了以下数字：
- 它 运行 有两个实例。每分钟这些实例一起处理 251 个请求。
- 一分钟内充电的 RU 总数为：2693（值介于 9.71、10.48、12.95 ... 之间）。
- 如果我们将其除以 60（秒），则对应于每秒消耗 44.8833 个请求单位。
所以它实际上证实了之前描述的差异。它没有接近每秒配置的 5000RU 的 40%-50%。
作为测试，我还从此应用程序中完全删除了日志记录。 Azure 中的 Consumed RU 图表降至 0。因此我认为可以安全地假设所有请求都来自该应用程序。
更新三：
更新四
请求单位的绝对数量也与我在日志中看到的一致。此图表中的时间轴为 4 小时。所以每一分都是5分钟。 5 分钟内 +/- 12K RU 的值，相当于每秒 40 RU。
为了说明这个问题已经解决，我把评论中的片段放在这里以阐明解决方案：
@noahstahl 添加了此评论： 鉴于您的预期吞吐量与目睹的节流之间的巨大差异，您似乎有一些操作比您想象的更昂贵，或者更突发。我会尝试在应用程序代码中实现更精细的日志记录，例如在这个例子 youtu.be/Tht_RV5QPJ0?t=2964
'bursty' 评论是指向解决方案的指针。每分钟的平均数都还可以，因此预期使用情况与所需的容量配置之间似乎存在很大差距。但是，如果您每秒查看一次（通过使用日志），很明显有些秒没有任何流量，而其他秒看到的流量就 RU 而言要高得多。通过修复这些爆发，一切都回到了 'as expected'。
附带说明一下，@noahstahl 的视频看起来很有趣。感谢分享！