关于 Cosmos DB 物理和逻辑分区的一些问题
Some questions about Cosmos DB Physical and Logical Partitions
我正在尝试了解 Physical/Logical 分区与 Azure Cosmos DB 中的吞吐量可用性之间的关系，并有几个问题。
参考文档：https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview.
根据文档，这是我的理解：
- 每个物理分区可以容纳 50GB 数据，而每个逻辑分区可以容纳 20GB。
- 预配的总吞吐量均匀分布在所有物理分区中。
- 每个物理分区最多可以有 10000 个RU/s。
- Cosmos DB 引擎会在需要时自动创建物理分区并相应地移动逻辑分区。
现在我的问题是：
- 创建额外的物理分区背后的逻辑是什么？
是根据逻辑分区占用的space，还是根据一个物理分区中所有逻辑分区消耗的吞吐量，或者完全是别的什么。例如，
- 如果我提供 20000 的吞吐量 RU/s（无论我是否使用它），Cosmos DB 引擎是否会自动创建 2 个物理分区？
- Cosmos DB 引擎会首先创建一个物理分区吗（我刚刚创建了一个容器，里面没有数据，并且配置的吞吐量小于 10000 RU/s）？
- 如果预配的总吞吐量小于 10000，Cosmos DB 引擎是否会自动删除物理分区RU/sand/or逻辑分区的总大小低于 50 GB。
任何对此的见解将不胜感激。
更新
根据评论，我将原始问题分为两部分。问题的第二部分可以在这里找到：.
一些答案。
如果您为新容器提供 20K RU/s，Cosmos 实际上会创建 3 个分区。但是，如果您从更少的空间开始，比如 5K RU，然后向上扩展，它将创建 1 个分区，然后增加到 2 个分区。造成差异的原因是我们尝试减少分区拆分的初始数量，因为用户倾向于在初始配置期间摄取数据，通常伴随着吞吐量的额外增加。为了减少分区拆分的数量，我们提供了一个大约 60% 的 10K RU/s 的物理分区。但是，我们并不普遍应用这 60%，因为它很浪费。这只是我们在初始配置期间根据观察到的用户模式进行的优化。这也是您应该 不 关心物理分区而应关注逻辑分区键的众多原因之一。这里的 60% 是一个实现细节，可以随时更改。
是。
还没有，但即将到来。没有预计到达时间。
吞吐量始终均匀分布，所以是的，18K 分布在 3 个分区中，每个分区将获得 6K RU/s。
Is it based on the space occupied by logical partitions or based on the throughput consumed by all logical partitions
物理分区的拆分是根据配置的吞吐量以及单个分区上消耗的存储空间进行的。
Cosmos 何时创建新物理分区的示例
- 如果您提供 6000RU/s 数据库并摄取 60GB 的数据。
- 您配置了一个 15000RU/s 数据库并摄取了 10GB 的数据。
您可以将物理分区想象成一台最多可以处理 50GB 存储空间和 10K RU/s 的计算机。任何超出此范围的事情都会导致分裂。
数据库吞吐量在物理分区之间平均分配，而不是逻辑分区。
From the documentation it seems the size or utilization of a logical partition does not really matter and I could have some logical partitions getting more requests than others but as long as I am not exceeding the available throughput of the physical partition, I should be fine. Is this correct?
这是真的。逻辑分区大小很重要，这意味着它不能超过 20GB。利用率也限制在 10K RU/s。我们无法控制逻辑分区如何拆分为物理分区，因此您无法真正知道您的逻辑分区位于哪个物理分区。同样，也无法确保您不超过 10K物理分区的吞吐量。这就是为什么 MS 建议您选择分区键以便适当平衡利用率的原因。
我正在尝试了解 Physical/Logical 分区与 Azure Cosmos DB 中的吞吐量可用性之间的关系，并有几个问题。
参考文档：https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview.
根据文档，这是我的理解：
- 每个物理分区可以容纳 50GB 数据，而每个逻辑分区可以容纳 20GB。
- 预配的总吞吐量均匀分布在所有物理分区中。
- 每个物理分区最多可以有 10000 个RU/s。
- Cosmos DB 引擎会在需要时自动创建物理分区并相应地移动逻辑分区。
现在我的问题是：
- 创建额外的物理分区背后的逻辑是什么？
是根据逻辑分区占用的space，还是根据一个物理分区中所有逻辑分区消耗的吞吐量，或者完全是别的什么。例如，
- 如果我提供 20000 的吞吐量 RU/s（无论我是否使用它），Cosmos DB 引擎是否会自动创建 2 个物理分区？
- Cosmos DB 引擎会首先创建一个物理分区吗（我刚刚创建了一个容器，里面没有数据，并且配置的吞吐量小于 10000 RU/s）？
- 如果预配的总吞吐量小于 10000，Cosmos DB 引擎是否会自动删除物理分区RU/sand/or逻辑分区的总大小低于 50 GB。
任何对此的见解将不胜感激。
更新
根据评论，我将原始问题分为两部分。问题的第二部分可以在这里找到：
一些答案。
如果您为新容器提供 20K RU/s，Cosmos 实际上会创建 3 个分区。但是，如果您从更少的空间开始，比如 5K RU，然后向上扩展，它将创建 1 个分区，然后增加到 2 个分区。造成差异的原因是我们尝试减少分区拆分的初始数量，因为用户倾向于在初始配置期间摄取数据，通常伴随着吞吐量的额外增加。为了减少分区拆分的数量，我们提供了一个大约 60% 的 10K RU/s 的物理分区。但是，我们并不普遍应用这 60%，因为它很浪费。这只是我们在初始配置期间根据观察到的用户模式进行的优化。这也是您应该 不 关心物理分区而应关注逻辑分区键的众多原因之一。这里的 60% 是一个实现细节，可以随时更改。
是。
还没有，但即将到来。没有预计到达时间。
吞吐量始终均匀分布，所以是的，18K 分布在 3 个分区中，每个分区将获得 6K RU/s。
Is it based on the space occupied by logical partitions or based on the throughput consumed by all logical partitions
物理分区的拆分是根据配置的吞吐量以及单个分区上消耗的存储空间进行的。 Cosmos 何时创建新物理分区的示例
- 如果您提供 6000RU/s 数据库并摄取 60GB 的数据。
- 您配置了一个 15000RU/s 数据库并摄取了 10GB 的数据。 您可以将物理分区想象成一台最多可以处理 50GB 存储空间和 10K RU/s 的计算机。任何超出此范围的事情都会导致分裂。 数据库吞吐量在物理分区之间平均分配，而不是逻辑分区。
From the documentation it seems the size or utilization of a logical partition does not really matter and I could have some logical partitions getting more requests than others but as long as I am not exceeding the available throughput of the physical partition, I should be fine. Is this correct?
这是真的。逻辑分区大小很重要，这意味着它不能超过 20GB。利用率也限制在 10K RU/s。我们无法控制逻辑分区如何拆分为物理分区，因此您无法真正知道您的逻辑分区位于哪个物理分区。同样，也无法确保您不超过 10K物理分区的吞吐量。这就是为什么 MS 建议您选择分区键以便适当平衡利用率的原因。