azure - 关于 Cosmos DB 物理分区和逻辑分区的一些问题

Question

我试图了解 Azure Cosmos DB 中物理/逻辑分区与吞吐量可用性之间的关系，但有几个问题。

引用文档:https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning-overview .

根据文档，这是我的理解:

1. 每个物理分区可容纳 50GB 数据，每个逻辑分区可容纳 20GB。
2. 总预配置吞吐量均匀分布在所有物理分区中。
3. 每个物理分区的最大吞吐量为 10000 RU/s。
4. Cosmos DB 引擎会在需要时自动创建物理分区，并相应地移动逻辑分区。

现在我的问题是:

• 创建额外物理分区背后的逻辑是什么？

是基于逻辑分区占用的空间还是基于物理分区中所有逻辑分区消耗的吞吐量或者完全是其他什么。例如，

1. 如果我配置 20000 RU/s 的吞吐量(无论我是否使用)，Cosmos DB 引擎是否会自动创建 2 个物理分区？
2. Cosmos DB 引擎是否会首先创建单个物理分区(我刚刚创建了一个内部没有数据的容器，并且预配置的吞吐量小于 10000 RU/s)？
3. 如果总预配置吞吐量低于 10000 RU/s 和/或逻辑分区的总大小低于 50 GB，Cosmos DB 引擎是否会自动删除物理分区。

对此的任何见解都将受到高度赞赏。

更新

根据评论，我将原始问题分为两部分。问题的第二部分可以在这里找到:How is the throughput available for a physical partition split amongst its logical partition in Cosmos DB? .

Answer 1

一些答案​​。

1. 如果您配置一个具有 20K RU/s 的新容器，Cosmos 实际上会创建 3 个分区。但是，如果您从较少的资源(例如 5K RU)开始，然后扩大规模，它将创建 1 个分区，然后增加到 2 个分区。造成差异的原因是我们尝试减少初始分区拆分数量，因为用户倾向于在初始配置期间摄取数据，通常伴随着吞吐量的额外增加。为了减少分区拆分的数量，我们以 10K RU/s 的大约 60% 的速度配置物理分区。然而，我们并没有普遍应用这 60%，因为它很浪费。这只是我们在初始配置期间根据观察到的用户模式进行的优化。这也是您应该不关心物理分区而应该关注逻辑分区键的众多原因之一。这里的 60% 是一个实现细节，可以随时更改。

2. 是的。

3. 还没有，但即将到来。没有预计到达时间。 (更新:现在处于预览状态，可以在此处了解更多信息，Merge Preview

吞吐量始终是均匀分布的，所以是的，18K 分布在 3 个分区上，每个分区将获得 6K RU/s。