Question

大多数情况下，我们需要在模型结构如下的当前系统中搜索PublisherId和PlanId：-

发布者模型：发布者编号发布者名称 …..

计划模型：计划编号计划名称发布者编号 …..

发布者与计划模型之间的关系是1：M。

方案：我们不能将发布者ID或计划ID作为分区键，因为我们有3-5个发布者，他们曾经用来提交可能很快超过10 GB限制的批量数据。

Answer 1

从给出的结果看来，发布者ID确实是分区键的不错选择，但还不够。

我建议与另一个值组合以创建分区以分散数据。一年可能效果很好。即创建一个ID，该ID将发布者ID与相关文档的创建年份结合起来，例如<PublisherId>.2019（如果您每个发布者每年都有大量文档，则可以包含月份）。

这可以很容易地及时存档较早的内容，并且可以为查询带来好处，尽管这取决于您的系统。

您注意到，您将需要查看数据的分布并选择一个在扩展时将起作用的分区。

Answer 2

逻辑分区上有10 GB的限制，如果选择足够宽的partitionKey，则不必担心。

我假设您的文档看起来像这样，并创建了一个新的合成分区键-PublisherIdentifier。

{
  "publisherIdentifier": "1.Content.USA",
  "publisherId": "1",
  "publisherName": "A",
  "publisherType": "Content",
  "publisherCountry": "USA",
  "plans": [{"planId": "P1"},{"planId": "P2"},{"planId": "P3"}]
}

然后您可以根据计划查询发布者

SELECT VALUE publisher.publisherName
FROM publisher
JOIN plans IN publisher.plans
where plans.planId = "P1"

Azure Cosmos数据库分区键

2 个答案: