Azure cosmosdb CosmosDB请求单位消耗不匹配

我在CosmosDb遇到了RU消耗的问题。Azure Insights中的标准化RU消费视图让我感到困惑。我希望有人能帮助澄清

我们的应用程序创建8kb大小的文档。CosmosDb返回每个创建14个请求单元的请求使用情况。有些请求稍微轻一些，所以平均RU实际上更低

此创建操作每分钟执行280次，约为每秒5个请求。 这意味着该进程每秒将消耗5 x 14=70个请求单元。 目前没有其他正在运行的查询

总请求单位图表显示每5分钟12.5K RU。多少与计算的使用量相对应：12500/5min/60sec=每秒41.6个请求单位

如果我为那个容器提供5000 RU/s，我实际上每秒提供5000个请求单位，对吗？（RU/s是每秒请求的单位？） 这意味着，当前设置每秒将消耗5000个单元中的70个，即70/5000*100=已配置容量的1.4%

现在，如果我查看Azure portal中CosmosDb下的Insights屏幕，它会显示一个图表“标准化RU消耗（最大）”。该图表表明我使用的是5000 RU/s配置的40%-50%。如果我将手动配置的吞吐量降低到2000，则限制计数开始高于0。因此很明显，我们在这方面存在一些障碍

a）计算/请求图表和b）消耗图表之间的差异几乎是35倍

更多信息：

• azure中的total requests（请求总数）图表显示没有更多的请求被删除 表演
• 分区键是合成的yyyy dd-
• TTL为7天
• 我们有1个物理分区和20个逻辑分区
• 分区键是均匀分布的
• 单一区域
• 总数据使用量为10GB（数据+索引）
• 该应用程序使用RESTAPI创建文档

有人能解释一下吗？或者有办法解决这个问题吗

附言：

更新一：RESTAPI的使用 更新二： 我使用@NoahStahl建议的日志文件进行了研究。对cosmosdb的每个请求都记录在执行实际HTTP请求的客户端对象中。我没有找到隐藏的请求单元数。我找到的是以下数字：

• 它在两个实例上运行。每分钟这些实例一起处理251个请求
• 一分钟内充电RU的总数为：2693（值介于9.71、10.48、12.95…）
• 如果我们将其除以60（秒），它对应于每秒消耗的44.8833个请求单位

因此，它实际上确认了前面所述的差异。它并没有接近每秒提供的5000RU的40%-50%

作为测试，我还从这个应用程序中完全删除了日志记录。Azure中已消耗的RU图表下降到0。因此我认为可以安全地假设所有请求都来自该应用程序

更新三：

更新四

---

以绝对数表示的请求单位也与我在日志中看到的相对应。此图表中的时间轴为4小时。因此每个点为5分钟。5分钟内+/-12K RU的值对应于每秒40 RU。

为了明确此问题已得到解决，我将注释中的片段放在此处以澄清解决方案：

@noahstahl补充道：

---

考虑到预期吞吐量和节流之间的巨大差异，您似乎有一些操作比您想象的更昂贵，或者更容易中断。我会尝试在应用程序代码中实现更细粒度的日志记录，例如在本例中youtu.be/thtrv5qpj0？t=2964

“bursty”注释是指向解决方案的指针。每分钟的平均值都正常，因此预期使用率与所需容量配置之间似乎存在很大差距。但是如果您查看每秒（通过使用日志），很明显，一些秒没有任何流量，而其他秒看到的流量比RU的流量高得多。通过修复这些突发，一切都回到了“预期”

---

作为旁注，@noahstahl的视频观看起来很有趣。感谢分享！

您的RU/秒假设正确。请记住，容器的可用RU被划分为多个物理分区。您是否有多个物理分区？您提到了20个分区？这些分区是跨多个物理分区的吗？如果是，这可能是一个问题i don’我不能解释你看到了什么。如果你的一个分区是热分区，这会更加明显。你好，大卫。谢谢你的想法。它仍然只使用一个物理分区（我会更新这个问题）…实际存储的数据小于10gb。至于热分区，我想这不可能，因为合成pk包含一个介于0和20.m之间的随机生成数，所以它随机选取20个lp中的一个。它应该均匀分布。每个创建一个随机pk都是定义的。但也许我应该进一步研究这一点…但是n、 一个热分区怎么能使消耗的请求单位成倍增加呢？考虑到预期吞吐量和节流之间的巨大差异，似乎您有一些比您想象的更昂贵的操作，或者更突发的操作。我会尝试在应用程序代码中实现更细粒度的日志记录，例如在本例中，Hello Noah，Th在视频中，我观看了您链接的部分，我将按照该建议返回。根据您的建议，我推断您也认为设置4000 RU/s实际上意味着应用程序每秒应该能够花费（或消耗）4000 RU，对吧，那么每小时x 3600？如果它每秒消耗少于100 RU（我将进一步调查）它还不应该接近所提供的金额？很抱歉询问这一确认，但我感到困惑，并开始怀疑这是否真的是正确的推理。@NoahSta

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