关于Cosmos DB物理和逻辑分区的几个问题

Question

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

参考文档：https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning-overview。

根据这些文档，我的理解是：

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

现在我的问题是：

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

它是基于逻辑分区占用的空间，还是基于物理分区或其他所有逻辑分区所消耗的吞吐量。例如,

1. 如果我提供20000 RU/s的吞吐量(不管我是否使用它)，宇宙数据库引擎会自动创建2个物理分区吗？
2. 宇宙数据库引擎是否会首先创建一个单一的物理分区(我刚刚创建了一个容器，其中没有数据，所提供的吞吐量小于10000 RU/s)？
3. 宇宙数据库引擎将自动删除物理分区，以防总吞吐量小于10000 RU/s和/或逻辑分区的总大小降至50 GB以下。

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

更新

根据这些评论，我把原来的问题分成两部分。问题的第二部分可以在这里找到：在Cosmos DB中，物理分区如何在其逻辑分区中被分割？。

Answer 1

一些答案。

1. Cosmos实际上将创建3个分区，如果您提供一个新的容器的20K RU/s。但是，如果您以较少的，比如说5K RU，然后放大它将创建1个分区，然后增加到2个分区。造成这种差异的原因是，我们试图减少分区划分的初始数量，因为用户在初始配置期间倾向于摄入数据，通常伴随着吞吐量的增加。为了减少分区分割的数量，我们提供了一个物理分区，大约是10K RU/s的60%。但是，我们没有普遍地应用这个60%，因为它是浪费的。这只是我们在初始配置过程中根据观察到的用户模式进行的优化。这也是为什么您应该而不是关心物理分区，而是关注您的逻辑分区键的原因之一。这里的60%是一个实现细节，可以随时更改。
2. 是。
3. 还没有，但马上就要来了。没有紧急援助。(更新:这是预览版，可以在这里学到更多，合并预览

吞吐量总是平均分布的，所以是的，18K分布在3个分区上，每个分区将得到6K RU/s。

Answer 2

它是基于逻辑分区占用的空间，还是基于所有逻辑分区消耗的吞吐量？

对物理分区的分割基于提供的吞吐量以及单个分区上消耗的存储。宇宙何时将创建新的物理分区的示例

1. 如果您提供一个6000 of /s，并摄入60 DB的数据。
2. 您提供了15000 of /s，并摄入了10 DB的数据。你可以把一个物理分区想象成一台能最大处理50 as存储空间和10K RU/s的计算机。DB吞吐量在物理分区之间平均分配，而不是逻辑分区。

从文档中看，逻辑分区的大小或使用似乎并不重要，我可以让一些逻辑分区获得比其他分区更多的请求，但只要我不超过物理分区的可用吞吐量，我就应该没事。这是正确的吗？

这是真的。逻辑分区大小确实很重要，这意味着它不能超过20 be。利用率也仅限于10K RU/s，我们无法控制逻辑分区是如何划分成物理分区的，因此您无法真正知道逻辑分区位于哪个物理分区中。同样，也没有办法确保不超过物理分区的10K吞吐量。这就是为什么MS建议您选择分区键，以便适当地平衡使用。