Azure Cosmos DB 分區鍵 - 主鍵是否可以接受？

Question

我們的 Azure Cosmos DB 集合已經足夠大，需要一個分區鍵。 在閱讀有關此內容時，我的印象是最好的分區鍵是提供均勻分布和更高基數的鍵。 Microsoft 的這篇文章對此進行了討論。

使用主鍵作為分區鍵提供了均勻分布，但基數僅為 1。如果這是我唯一的選擇，這是一件壞事嗎？ 前面提到的文章給出了幾個例子，似乎表明在這些情況下應該將主鍵用作分區鍵。 對於 Azure Cosmos DB，分區是邏輯的，而不是物理的。 所以它不會導致每個文檔都在自己的磁盤上，但它似乎可能導致索引膨脹。

使用主鍵作為分區鍵是一種常見做法嗎？ 它有什么缺點嗎？

Answer 1

其實，分區鍵的選擇是一個值得反復權衡的問題。 由於選擇主鍵作為分區鍵是您唯一的選擇，我只討論一些可能的負面事情作為您的參考。

在性能方面，如果你查詢的字段不是partition key，你的查詢肯定會因為跨分區而降低查詢性能。 可以說，如果數據量很小，它不會有太大的影響。

成本方面，cosmos db主要是按存儲空間和RUs消耗來收費的。如你所說，選擇主鍵作為分區鍵會導致更多的索引存儲。 如果大多數查詢是跨分區的，也會導致更多的 RU 消耗。

在使用存儲過程、觸發器或UDF方面，不能通過存儲過程和觸發器使用跨分區事務。 因為 then 是分區的，所以在使用它們時需要指定分區鍵（基數僅為 1）。

請注意，如果創建了分區鍵，則以后無法刪除或修改它。 因此，在選擇之前請考慮一下並確保進行數據備份。

更多細節，還是參考官方文檔。

Answer 2

不，它沒有缺點。 爭取擁有高基數的分區鍵。 不要擔心索引或物理分區等。

您可以擁有數百萬個分區鍵和 10 個物理分區。 物理分區由 CosmosDB 在后台創建。 您永遠不應該擔心物理分區。

Answer 3

您可以說主鍵是分區鍵最安全、可能也是最合適的選擇。

它保證值的唯一性，這是實現唯一鍵以外的唯一方法。 分布將是均勻的，因為主鍵將是您的分區鍵，您將能夠使用它來通過讀取而不是查詢來檢索文檔，從而降低了操作速度和成本。

Answer 4

我認為 MS 在描述如何最好地確定 Cosmos DB 的分區鍵方面做得並不好 - 特別是如果人們通常建議使用數據庫的主鍵作為分區鍵（有時這可能是完全可以接受的，但是我看不出這是正常的）。

在最近的一個項目中，這就是我們決定為系統中的對象識別分區鍵和項目 ID 的方式。 我認為這適用於許多在其對象上具有自然復合主鍵候選的系統。

在我們的系統中，每個對象都限於一個狀態 (StateCode) 和供應商 (VendorId)。 從那里，我們有多個實體，如銷售訂單、客戶、小部件……在我們的 SQL Server 實現中，每個表都有一個明顯的自然復合主鍵 StateCode、VendorId、EntityId。 在 Cosmos DB 場景中，我們選擇 Partition Key 為 StateCode-Vendor-EntityType，Item Id 為 EntityId。 這允許在分區內查詢特定類型的所有實體（節省 RU），同時仍然允許在該分區內進行非常簡單的查詢（例如，同類實體）。 您最終以這種方式使用了復合自然鍵的所有部分，但允許對實體進行實際分區。

在更復雜的場景中，我們想要跨實體查詢給定供應商，我們可以從分區鍵中刪除 EntityType 並將其移動到項目 id 中或使用它來過濾正在搜索的對象。 這允許在分區內進行跨實體查詢，但由於異構實體，查詢本身稍微復雜一些。

如果實體的整個 ID 都在分區鍵中，那么您幾乎必須始終單獨查找項目或在不按 ID 查找時搜索每個分區 - 在這一點上，誰會關心您的數據在分區之間的分布是否均勻，如果無論如何你都必須搜索它們。

也許 OP 可以更多地描述實體——它們是否有自然的復合鍵候選（無論它們是否在 SQL 實現中使用）？ 如果不是，那么當前的持久層在通過某些 id 識別系統中的項目方面是什么樣子的？