documentDB的分区键或无分区键

Question

在DocumentDb中，我应该如何对它进行分区？我应该使用partitionkey吗？我认为自收集之后我无法做到“/ address/state”......或者我能吗？ 我应该使用“/ Id”还是“/ name”？是因为id是由documentDB生成的Guid，并且名称几乎总是唯一的，所以这些主要是独一无二的。那么我应该使用哪一个？我想我可能会按名称查询，但我认为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

我应该使用partitionkey与否？

为了决定是否应该划分您的收藏，这里有一些关键点考虑：

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

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

我不认为我可以做“/地址/状态”，因为它的集合...或者我可以吗？

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

我应该使用“/ Id”还是“/ name”？是因为id是由documentDB生成的Guid，并且名称几乎总是唯一的，所以这些主要是独一无二的。那么我应该使用哪一个？

一个理想的分区键是一个频繁出现在查询中的过滤器，它具有足够的基数以确保您的解决方案具有可伸缩性。在“Designing for partitioning”部分，您可以找到选择分区键和几个真实世界场景的两个关键考虑因素，有关详细信息，请检查链接。