Cosmos中的物理分区是否会导致逻辑分区的RU降低

我们拥有大量写入数据，以至于我们不断地在COSMOS（mongo API）的应用程序上遇到RATE LIMIT，并且我们无法跟上必须插入的数据的速率，因此我们正在使用COSMOS看到一个插入。

首先，我们已经有“自动缩放启用”功能，当前将RU设置为55000，我们可能将其更改为无服务器，但是在我需要了解COSMOS物理分区和逻辑分区的理解方式以及分区键选择是否正确之前，

所以Cosmos声明

Maximum RUs per (logical) partition 10000

我们按小时费率示例对数据进行分区（之所以这样做，是因为我们计划针对读取请求按日期进行过滤）

2020-09-17 00:00:00  -> 1 logical parition
2020-09-17 01:00:00  -> 2 logical partition
2020-09-17 02:00:00  -> 3 logical partition

以此类推。

现在在CosmosDB中提到了这一点。

如果我们提供每秒18,000个请求单位的吞吐量（RU / s），那么三个物理分区中的每个分区都可以使用1/3的预配置的总吞吐量。在选定的物理范围内分区，逻辑分区键牛肉产品，蔬菜和蔬菜产品，汤，酱汁和酱汁可以一起使用，利用物理分区的6,000个预配置RU / s。

物理分区是上述场景中给定的COSMOS DB内部的东西，但这（上面提到的）使我感到困惑

所以我的问题是？

如果我们的脚本正在为共享密钥插入记录

2020-09-18 00:00:00

听起来，您每小时的分区键所发生的一切就是每小时将所有写入旋转到新的热（瓶颈）分区。如您所述，由于一个分区限制为10K RU，因此这将是系统在任何给定时间的有效写吞吐量。

将需要一种不同的分区策略来分配写入内容，如synthetic partition key文档中讨论的那样。如果您还有其他候选分区值（即使是随机后缀）要添加或替换时间跨度值，则将允许多个并行写分区，从而提高吞吐量。

对日期/时间进行分区可能是写繁重的工作负载时可以选择的最差的分区键之一，因为在当前时间您将始终有一个热分区。

10K RU / s是物理分区的限制，而不是逻辑分区的限制。

我强烈建议您使用新的分区键，以更好地在更宽的分区键范围内分配写操作。如果您可以使用相同的分区键值或至少一个值范围（以某种方式限制而不是完整的扇出查询）来查询数据，则状态会好得多。

基于我们最近的项目经验，我们在CosmosDB中遇到了类似的情况，并且与MSFT的cosmos团队进行了对话

2020-09-18 00:00:00逻辑分区将获得COSMOS所述的完整51000 RU或10000 RU。

RU的分配基于物理分区的数量进行，如果您的预配置吞吐量为55000 RU，则Cosmos将在内部创建6个分区（因为1个物理分区最多可配置10000 RU）并且将为每个分区提供相同数量的RU。因此，2020-09-18 00:00:00逻辑分区将获得与所驻留的一个物理分区相同的RU。

如果我们有100个物理分区，即使另一个物理分区不提供任何RU服务，RU也会在所有100个分区之间平均（严格）共享。

是的，即使其他物理分区不为任何RU服务，RU也会在所有100个分区之间平均（严格地）共享

找到了this个MS doc，内容与此有关。