唯一 ID 的 Cosmos DB 分區鍵注意事項

Question

根據 URL 下面的 Azure cosmos DB 文檔，每個分區鍵都會創建邏輯分區。

https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview

假設我有以下數據

{
    
    "firstname": "Phil",
    "LastName": "Dixon",
    "age": 28,
    "org": "Fin",
    "Level": 3,
    "region": "India",
    "id": "123",
    "which-city": "Bangalore",

},

{
 "userID": 1,
 "Name": "Bob",
 "Hobbies": "Dancing",
 "Region": "USA"
},
{
    "userID": 2,
    "Name": "Anna",
    "Hobbies": "Dancing",
    "Region": "USA"
   },
{
    "userID": 3,
    "Name": "Phil",
    "Hobbies": "Dancing",
    "Region": "USA"
   },
   {
    "userID": 4,
    "Name": "Jog",
    "Hobbies": "Dancing",
    "Region": "India"
   },
   {
    "userID": 5,
    "Name": "Maxi",
    "Hobbies": "Playing",
    "Region": "India"
   },
   {
    "userID": 6,
    "Name": "Capi",
    "Hobbies": "Playing",
    "Region": "Japan"
   },

如果我選擇 userID 作為分區鍵，它會為每個項目創建單獨的邏輯分區，它會降低我的性能嗎？

根據文檔，我了解區域可能是我用例的正確分區鍵。 但我想了解，如果我選擇 userid 作為分區鍵，在性能方面選擇 region 作為分區鍵，會發生什么。

更多信息：在 userID 是分區鍵期間，我對 userID 屬性進行查詢 在 region 是分區鍵期間，我對 region 屬性進行查詢

API：SQL

Answer 1

您擁有的邏輯分區越多越好，尤其是當您根據分區鍵過濾查詢時。

邏輯分區的增加不會對性能產生負面影響。 但是，只有當它變得非常大時，您才會看到顯着的收益。 同樣擁有大量邏輯分區並不意味着擁有相同數量的物理分區。

Answer 2

如果我選擇 userID 作為分區鍵，它會為每個項目創建單獨的邏輯分區，它會降低我的性能嗎？

不，擁有更多邏輯分區不會（通常）降低您的性能。

更准確地說，只要您的查詢是按分區鍵過濾的，它肯定不會降低您的性能。 通常，您應該擁有盡可能小的分區，同時避免有太多的跨分區查詢。 這實際上取決於您打算執行哪些查詢以及執行頻率。 把它們寫出來，看看哪些是跨分區的。

跨分區查詢可能會變得更慢且成本更高，但只有當您的數據集增長到許多物理分區（= 10++ GB）時，它才開始變得尤為重要。 請注意，跨分區查詢通常是可以的，只要它們具有良好的選擇性謂詞並被索引。

還要考慮寫場景。 寫入場景將受益於在任何給定時間分布在許多分區上的寫入。 不過，僅當您在許多物理分區上進行大量爆發時才重要。 一次寫 100 個文檔不是什么大不了的事。

還要考慮最大分區大小。 一個好的分區應該在某個地方有一個增長的邏輯限制。 想象一下你最糟糕的分區，並計划在相當長的時間內實現最嚴重的增長。

還要考慮您希望存儲在同一容器中的其他文檔（將來）。 例如，用戶偏好、公司、次區域等。 他們將有自己需要的查詢和分區鍵選擇對他們來說也很重要。

如果我在性能方面選擇 userid 作為分區鍵並選擇 region 作為分區鍵會發生什么。

這取決於您的查詢、增長模式和許多其他方面，但是...

Region似乎有風險：

• 似乎有發展成為巨大的潛力。
• 當吞吐量在 >>physical<< 分區之間共享時，可能會有熱分區並受到限制。 同一地區最有可能同時生產/消費數據。
• 分區將非常不均勻，因為區域的大小和使用情況非常不同。 它們將變得更加不平衡。
• 您的樣本中有region和Region ，這不是一回事

另一方面， UserId是：

• 小（= 在分區內查詢中掃描的文檔更少）
• 將很好地擴展，大概任何大的增長將更多地由新用戶引起，而不是相同的用戶無休止地增加他們的分區大小。
• 大概不會有熱分區，因為任何給定時間的活動用戶將在物理分區之間大致均勻地共享。
• 單個用戶不太可能達到分區大小上限（與區域相比）

概括：

計划您的“文檔類型”，最常執行的查詢，估計分區和索引上的數據分布，並考慮預期的增長模式。

從遠處看，按 UserId 進行分區並僅在區域上編制索引似乎更好。 如果有疑問，生成一些數據並測量不同查詢的 RU。