Azure Cosmos DB - 了解分区键

Question

我正在设置我们的第一个Azure Cosmos数据库 - 我将导入第一个集合，即我们的一个SQL Server数据库中的表中的数据。在设置集合时，我无法理解分区键的含义和要求，我在设置此初始集合时必须特别指出。

我在这里阅读了文档：（https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-partition-data）并且仍然不确定如何继续使用此分区键的命名约定。

有人可以帮我理解我应该如何考虑命名这个分区键吗？请参阅下面的屏幕截图，了解我要填写的字段。

如果有帮助，我导入的表包含7列，包括唯一的主键，非结构化文本列，URL列和该记录URL的其他几个辅助标识符。不确定是否有任何信息与我如何命名我的分区密钥有关。

编辑：根据@Porschiey的要求，我已经从我正在导入的表格中添加了几张记录的屏幕截图。

Answer 1

老实说，video here *是理解CosmosDb中分区的主要帮助。

但是，简而言之： PartitionKey是一个将存在的属性，最适合用于将类似对象组合在一起的每个对象。

好的例子包括位置（如城市），客户ID，团队等。当然，它很大程度上取决于你的解决方案;所以，如果您要发布您的对象的样子，我们可以推荐一个好的分区键。

编辑：应注意，10GB以下的集合不需要PartitionKey。 （感谢David Makogon）

* The video以前住在this MS docs page上标题为“Azure Cosmos DB中的分区和水平扩展”，但此后已被删除。上面提供了直接链接。

Answer 2

CosmosDB可用于存储任何数据限制。后端如何使用分区键。它与主键相同吗？ - 没有

主键：唯一标识数据 分区键有助于分片数据（例如，当城市是分区键时，纽约市的一个分区）。

分区的限制为10GB，我们越好地跨分区传播数据，我们就越能使用它。虽然最终需要更多连接才能从所有分区获取数据。示例：从查询中获取相同分区中的数据总是比从多个分区获取数据更快。

Answer 3

分区键用于分片，它充当数据的逻辑分区，并为Cosmos DB提供跨分区分发数据的自然边界。

您可以在此处详细了解：https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data

Answer 4

表上的每个分区最多可以存储10GB（单个表可以存储任意数量的文档模式类型）。您必须选择分区密钥，以便针对该密钥存储的所有文档（因此属于该分区）都低于该10GB限制。

我现在也在考虑这个问题 - 分区键是否应该是某种类型的日期范围？在这种情况下，它实际上取决于在一段时间内存储的数据量。

Answer 5

我在这里Azure Cosmos DB. Partitioning整理了一篇详细的文章。

什么是逻辑分区？

Cosmos DB 旨在基于物理分区 (PP)（将其视为可单独部署的底层自给自足节点）和逻辑分区之间的数据分布进行水平扩展 - 具有相同特征的文档桶 （分区键) 应该完全存储在同一个 PP 上。所以LP不能有PP1上的部分数据和PP2上的另一部分数据。

物理分区有两个主要限制：

• 最大吞吐量：10k RUs
• 最大数据大小（此 PP 中存储的所有 LP 的大小总和）：50GB

逻辑分区的大小限制为 1 - 20GB。

<块引用>

注意：由于 Cosmos DB 大小限制的初始版本增加，我不会对很快大小限制可能会增加感到惊讶。

---

如何为我的容器选择正确的分区键？

根据 Microsoft 对可维护数据增长的建议，您应该选择基数最高的分区键（如文档的 Id 或复合字段）。对于main reason：

<块引用>

在所有逻辑分区中均匀分布请求单元 (RU) 消耗和数据存储。这可确保在您的物理分区中均匀分配 RU 消耗和存储空间。

在考虑正确的分区键时，分析应用程序数据消费模式至关重要。在非常罕见的情况下，更大的分区可能会工作，但同时此类解决方案应该实施数据归档以从一开始就维护数据库大小（请参见下面的示例解释原因）。否则，您应该准备好增加运营成本，只是为了保持相同的数据库性能和潜在的 PP 数据倾斜、意外的“拆分”和“热”分区。

具有非常细粒度的小分区策略将导致消耗分布在多个物理分区 (PP) 之间的数据的 RU 开销（绝对不是 RU 的乘法，而是每个请求耦合额外的 RU），但与当数据开始增长超过 50-、100-、150GB 时出现的问题。

---

为什么大分区在大多数情况下是一个糟糕的选择，尽管文档说“选择最适合你的”

主要原因是 Cosmos DB 旨在横向扩展，并且每个 PP 的预配置吞吐量仅限于 [total provisioned per container (or DB)] / [number of PP]。

一旦由于超过 50GB 大小而发生 PP 拆分，您现有 PP 以及两个新创建的 PP 的最大吞吐量将低于拆分前。

请想象以下场景（将天数视为两次操作之间的时间间隔）：

1. 您已经创建了具有 10k RU 和 CustomerId 分区键（将生成一个底层 PP1）的容器。 每个 PP 的最大吞吐量为 10k/1 = 10k RUs
2. 逐渐将数据添加到容器中，您最终会拥有 3 个大客户，其中包含 C1[10GB]、C2[20GB] 和 C3[10GB] 的发票
3. 当另一个客户使用 C4[15GB] 的数据加入系统时，Cosmos DB 必须将 PP1 数据拆分为两个新创建的 PP2 (30GB) 和 PP3 (25GB)。 每个 PP 的最大吞吐量为 10k/2 = 5k RUs
4. 另外两个客户 C5[10GB] C6[15GB] 被添加到系统中，并且都以 PP2 结束，这导致了另一个分裂 -> PP4 (20GB) 和 PP5 (35GB)。 每个 PP 的最大吞吐量现在为 10k/3 = 3.333k RUs

<块引用>

重要事项：因此，查询了 [Day 2] C1 条数据，最多 10k RU 但是在 [Day 4] 上，only 最大到 3.333k RU，这直接影响查询的执行时间

这是在当前版本的 Cosmos DB (12.03.21) 中设计分区键时要记住的主要事情。

---

Answer 6

分区键充当逻辑分区。

现在，您可能会问什么是逻辑分区？逻辑分区可能会根据您的要求而有所不同。假设您具有可以根据客户进行分类的数据，因为该客户“ Id”将用作逻辑分区，并且将根据其客户ID放置用户的信息。

这对查询有什么影响？

在查询时，您会将分区键作为供稿选项，并且不会将其包含在过滤器中。

例如：如果您的查询是

SELECT * FROM T WHERE T.CustomerId= 'CustomerId';

现在是现在

var options = new FeedOptions{ PartitionKey = new PartitionKey(CustomerId)};

var query = _client.CreateDocumentQuery(CollectionUri,$"SELECT * FROM T",options).AsDocumentQuery(); 

Answer 7

选择分区密钥是在设计数据库和集合时利用Cosmos DB弹性 flexibility 的重要决定。创建收藏集后，就无法更改 Partition 。

分区是不同区域（全局数据中心）之间的物理容器。分区键是 logic separator ，用于逻辑上划分文档数据并将其存储在分区中。 Cosmos dB在内部使用此分区键自动将数据存储到任何物理分区中，而无需任何其他配置（或）编码。

这里有一些很棒的资源，可以帮助您了解分区键以及如何选择正确的分区键。

How to partition your data in Azure Cosmos DB | Azure Friday

Understanding Partitioning in Azure Cosmos DB

Partitioning and horizontal scaling in Azure Cosmos DB