documentDB 的分区键或无分区键

Question

在 DocumentDb 中，我应该如何对它进行分区？我应该使用分区键吗？我不认为我可以做“/地址/状态”，因为它的集合......或者我可以吗？ 我应该使用“/Id”还是“/name”？这是一个好主意，因为 id 是由 documentDB 生成的 Guid 并且 name 几乎总是唯一的。那么我应该使用哪一个？我想我可以按名称查询，但我认为 partitionkey 应该是可以分组的文档，例如州、城市或 parentId。

我不应该使用 partitionKey 吗？这适用于我在 documentDb 中的 AspNetuser 模式用户表。我应该为 partitionKey 使用哪个属性？

public class Business
{
    [JsonProperty(PropertyName = "id")]
    public string Id { get; set; }

    [JsonProperty(PropertyName = "name")]
    public string Name { get; set; } 

    [JsonProperty(PropertyName = "description")]
    public string Description{ get; set; } 

    [JsonProperty(PropertyName = "addresses")]
    public List<Address> Addresses{ get; set; } 

   //more columns...
}


public class Address
{  
    [JsonProperty(PropertyName = "street")]
    public string Street{ get; set; } 

    [JsonProperty(PropertyName = "city")]
    public string City{ get; set; }  

    [JsonProperty(PropertyName = "state")]
    public string State{ get; set; }  
}

Answer 1

我应该使用分区键吗？

为了决定是否应该对集合进行分区，以下是需要考虑的一些关键点：

单分区集合：具有较低的价格选项以及执行查询和跨所有集合数据执行交易的能力。它们具有单个分区的可扩展性和存储限制（10GB 和 10,000 RU/s）。您不必为这些集合指定分区键。对于不需要大量存储或吞吐量的场景，单分区集合非常适合。

分区集合：可以跨越多个分区并支持非常大的存储量和吞吐量。您必须为这些集合指定一个分区键。

我不认为我可以做“/address/state”，因为它被收集了......或者我可以吗？

partition key 可以是文档中的属性或路径。

我应该使用“/Id”还是“/name”？这是一个好主意，因为 id 是由 documentDB 生成的 Guid 并且 name 几乎总是唯一的。那么我应该使用哪一个呢？

理想的分区键是在您的查询中经常作为过滤器出现并且具有足够的基数以确保您的解决方案具有可扩展性的分区键。在“Designing for partitioning”部分，您可以找到选择分区键的两个关键注意事项和一些实际场景，有关详细信息，请查看链接。