我们有太多的写重数据，以至于我们在COSMOS(mongo API)的应用程序上不断遇到RATE LIMIT，我们无法跟上我们必须插入的数据的速度，然后是我们使用COSMOS看到的插入速度。
首先，我们已经有了Auto Scale Enable，RU当前设置为55000，我们可能会将其更改为无服务器，但在我需要了解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
等等
现在在宇宙数据库中提到了这一点。
如果我们提供每秒18000个请求单元的吞吐量(RU/s)，则三个物理分区中的每一个可以利用提供的总吞吐量。在选定的物理分区，逻辑分区键牛肉制品，蔬菜和蔬菜产品和汤、酱汁和肉汁可以统称为，利用物理分区的6000个规定的RU/s。
物理分区是上面场景中给出的COSMOS DB内部的东西，但这(上面提到的)让我很困惑
所以我的问题是？
如果我们的脚本正在插入共享密钥的记录
2020-09-18 00:00:00
如COSMOS所述，
2020-09-18 00:00:00逻辑分区将获得完整的51000 RU或10000 RU。如果我们有100个物理分区，那么即使另一个物理分区没有为任何RU提供服务，RU也会在所有100个分区之间平等(严格)共享。
听起来，每小时分区键所发生的一切都是每小时将所有写入旋转到一个新的热(瓶颈)分区。正如您所注意到的，由于一个分区被限制为10KRU，这将是您的系统在任何给定时间的有效写吞吐量。
需要一种不同的分区策略来分发写入，就像在合成分区键文档中讨论的那样。如果您有一个其他候选分区值(即使是随机后缀)来添加或替换时间跨度值，这将允许多个并行写分区，从而提高吞吐量。
对于写繁重的工作负载，按日期/时间进行分区可能是最糟糕的分区键之一，因为当前时间总是有一个热分区。
10K RU/s是物理分区的限制，而不是逻辑分区。
我强烈建议使用一个新的分区键，它可以更好地在更宽的分区键范围内分配写入。如果您可以使用相同的分区键值或至少一系列值来查询数据，使其以某种方式有界，而不是一个完整的扇出查询，那么您的状态会好得多。
根据我们最近的项目经验，我们在CosmosDB中遇到了类似的情况，以及我们与MSFT的宇宙团队的对话
- 如COSMOS所述，
2020-09-18 00:00:00逻辑分区将获得完整的51000 RU或10000 RU
RU的分布是根据物理分区的数量进行的，如果您提供的吞吐量为55000 RU，那么Cosmos将在内部创建6个分区(因为一个物理分区最多可以提供10000 RU)，并且每个分区将提供相同数量的RU。因此，2020-09-18 00:00:00逻辑分区将获得与为驻留的一个物理分区提供的RU相等的RU。
- 如果我们有100个物理分区，那么即使其他物理分区没有为任何RU提供服务，RU也会在所有100个分区之间平等(严格)共享
是的，即使其他物理分区不为任何RU 提供服务，RU也在所有100个分区之间平等(严格)共享
找到了一位MS医生，他也谈到了这一点。
Will 2020-09-18 00:00:00逻辑分区将获得COSMOS提到的全部51000 RU或10000 RU。
每个物理分区都有10k RU的限制，因此每个逻辑分区也将最多接收10k RU。
如果我们有100个物理分区，那么即使其他物理分区没有为任何RU提供服务，RU是否在所有100个分区之间平等(严格)共享。
无论其他物理分区是否为查询提供服务，throughput在所有物理分区之间严格平等共享。
参考：https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning-overview