关于Cosmos DB物理和逻辑分区的几个问题 [英] Some questions about Cosmos DB Physical and Logical Partitions
问题描述
我正在尝试了解Azure Cosmos DB中物理/逻辑分区和吞吐量可用性之间的关系，并有几个问题。
参考文档：https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview。
根据文档，我的理解是：
- 每个物理分区可以容纳50 GB数据，而每个逻辑分区可以容纳20 GB数据。
- 所有物理分区平均分配设置的总吞吐量。
- 每个物理分区最多可以有10000 RU/s。
- Cosmos DB引擎在需要时自动创建物理分区，并相应地移动逻辑分区。
现在我的问题是：
- 创建其他物理分区背后的逻辑是什么？
它是基于逻辑分区占用的空间，还是完全基于物理分区中所有逻辑分区所消耗的吞吐量等。例如，
- 如果我提供20000 RU/s的吞吐量(不管我是否使用)，Cosmos DB引擎是否会自动创建2个物理分区？
- Cosmos DB引擎是否会首先创建单个物理分区(我刚刚创建了一个没有数据的容器，配置的吞吐量低于10000 RU/s)？
- 如果设置的总吞吐量小于10000 RU/s和/或逻辑分区的总大小低于50 GB，Cosmos DB引擎是否会自动删除物理分区。
我们非常感谢您对此有任何见解。
更新
根据评论，我将原来的问题分成两部分。问题的第二部分可以在这里找到：How is the throughput available for a physical partition split amongst its logical partition in Cosmos DB?。
推荐答案
一些答案。
如果您提供一个20K RU/s的新容器，Cosmos实际上会创建3个分区。但是，如果您从更少的容器开始，比如说5K RU，然后扩容，会创建1个分区，然后增加到2个分区。差异的原因是我们试图减少初始分区拆分的数量，因为用户倾向于在初始配置期间摄取数据，这通常伴随着吞吐量的额外增加。为了减少分区拆分的数量，我们将物理分区配置为10K RU/s的大约60%。但是，我们并没有普遍应用这个60%，因为这是浪费。这只是我们在初始配置期间根据观察到的用户模式进行的优化。这也是为什么您不应该关心物理分区，而应该关注您的逻辑分区键的众多原因之一。此处的60%是实施详细信息，可以随时更改。
是。
还没有，但是马上就要来了。无预计到达时间。
吞吐量始终平均分配，因此，是的，18K分布在3个分区中，每个分区将获得6K RU/s。
这篇关于关于Cosmos DB物理和逻辑分区的几个问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
