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」部分，您可以找到選擇分區鍵和幾個真實世界場景的兩個關鍵考慮因素，有關詳細信息，請檢查鏈接。