選擇分割區索引鍵

  • 8 分鐘

請記住，JSON 文件中的資料會儲存在容器內的 Azure Cosmos DB 資料庫中，這些容器接著會分散到實體分割區，而其中資料會根據分割區索引鍵的值路由傳送至適當的實體分割區。

Diagram that illustrates the physical partitions in Azure Cosmos DB.

分割區索引鍵是必要的文件屬性，可確保分割區索引鍵值相同的文件會路由傳送至特定實體分割區並儲存在其中。 實體分割區支援固定最大的儲存體和輸送量 (RU/秒)。 Azure Cosmos DB 會再次使用該分割區索引鍵值，以可預測的方式自動將邏輯分割區分散到可用的實體分割區。

在此單元中，您將深入了解邏輯分割區，以及如何避免經常性分割區。 此資訊可協助我們在案例中為客戶資料選擇適當的分割區索引鍵。

在 Azure Cosmos DB 中，您可以增加實體分割區來存取和儲存資料，以增加儲存體並提升輸送量。 實體分割區的儲存體大小上限為 50 GB，而最大輸送量為 10,000 RU/秒。

Azure Cosmos DB 中的邏輯分割區

分割區索引鍵可確保分割區索引鍵值相同的文件會視為屬於相同邏輯分割區，並路由傳送至特定實體分割區並儲存在其中。 邏輯分割區的概念可讓您將分割區索引鍵值相同的文件分成一組。 多個邏輯分割區可以儲存在單一實體分割區內，而且容器可以具有不限數量的邏輯分割區。 隨著容器成長，個別邏輯分割區會移至新的實體分割區，成為一個單位。 將邏輯分割區當作一個單位移動，可確保其中所有文件都位於相同的實體分割區上。 邏輯分割區的大小上限為 20 GB。 使用具有高基數的分割區索引鍵，可將資料散佈到大量邏輯分割區，以避免此 20 GB 的限制。

Diagram that shows the relationship between the physical and logical partitions.

分割區索引鍵提供一 種路由傳送邏輯分割區資料的方式。 其是一種屬性，存在於您容器中的每份文件中，可路由傳送您的資料。 容器是另一個抽象概念，而且適用於所有以相同分割區索引鍵儲存的資料。 建立容器時，即會定義分割區索引鍵。

在下列範例中，容器具有分割區索引鍵 /username。

Diagram that shows an example where the partition key is username.

避免經常性存取層資料分割

將 Azure Cosmos DB 的資料模型化時，您所選擇的分割區索引鍵會導致資料及要求平均分散至容器中的實體分割區，這一點至關重要。 當容器變大且實體分割區數目增加時，尤其如此。

如果您未在開發期間測試負載下資料庫的設計，則在應用程式進入生產階段並已寫入大量資料之前，可能不會體驗到分割區索引鍵選擇不佳的影響。

當資料未正確分割時，可能會導致「熱分割區」。 經常性存取分割區會阻止應用程式工作負載調整規模，而且可能會出現在儲存體和輸送量上。

儲存體經常性分割區

分割區索引鍵導致極不對稱的儲存模式時，儲存體上就會出現經常性存取分割區。 舉例來說，假設有某個多租用戶的應用程式使用 TenantId 做為分割區索引鍵，搭配六個租用戶:A 至 F。租用戶 B、C、E 和 F 非常小，租用戶 D 稍微有更多資料。 不過，租用戶 A 很龐大，而且快速達到其分割區的 20 GB 限制。 在此案例中，我們需要選取不同的分割區索引鍵，將儲存作業散佈到更多的邏輯分割區。

Diagram that shows a storage distribution skew.

輸送量經常性分割區

當大部分或所有的要求都移至相同的邏輯分割區時，輸送量可能會受到熱分割區的影響。

請務必了解您應用程式的存取模式，以確保要求儘可能平均地散佈至分割區索引鍵值。 針對 Azure Cosmos DB 中的容器佈建輸送量時，輸送量會平均配置在容器內所有實體分割區之間。

舉例而言，如果您的容器為 30,000 RU/秒，則此工作負載會散佈至稍早所述相同六個租用戶的三個實體分割區。 因此，每個實體分割區為 10,000 RU/秒。 如果租用戶 D 將其所有 10,000 RU/秒配額用盡，則會受到速率限制，因為無法取用配置給其他分割區的輸送量。 這會導致租用戶 C 和 D 的效能不佳，並將未使用的計算容量留在其他實體分割區和剩餘的租用戶中。 最終，此分割區索引鍵造成的資料庫設計，將使應用程式無法調整工作負載規模。

Diagram that shows a throughput hot partition.

當資料和要求平均散佈時，資料庫可能會以完全利用儲存體和輸送量的方式增長。 進而實現最佳效能與效率。 簡而言之，此資料庫的設計有助規模調整。

Diagram that shows the data and requests spread evenly across partitions.

考慮讀取與寫入

選擇分割區索引鍵時，您也必須考量資料會大量讀取還是大量寫入。 建議使用高基數分割區索引鍵，盡可能散佈大量寫入要求。

針對大量讀取工作負載，請確保查詢是由一個或有限數目的實體分割區來處理，方法是納入 WHERE 子句，並在查詢中對分割區索引鍵設置等號篩選條件，或對分割區索引鍵值子集設置 IN 運算子。

若應用程式工作負載會進行大量寫入和大量讀取，則有一個解決方案。 我們將在下個課程模組中探討該解決方案。

下圖顯示依使用者名稱分割的容器。 此查詢只會叫用單一邏輯分割區，因此效能始終良好。

Diagram that shows a partition query for username.

篩選不同屬性 (例如 favoriteColor) 的查詢會「展開傳送」至容器中的所有分割區。 這也稱為跨分割區查詢。 當容器很小且只佔用單一分割區時，這類查詢將如預期般執行。 不過，當容器成長且實體分割區數目增加時，此查詢會變慢且更昂貴，因為需要檢查每個分割區，以取得實體分割區容器資料是否與查詢相關的結果。

Diagram that shows a cross-partition query for favorite color.

為客戶選擇分割區索引鍵

了解 Azure Cosmos DB 中的資料分割後，我們就可以決定客戶資料的分割區索引鍵。 如先前所討論，我們會對客戶執行三項作業：建立客戶、更新客戶，以及擷取客戶。 在此情況下，我們會依其識別碼擷取客戶。由於該作業的呼叫最頻繁，因此將客戶識別碼作為容器的分割區索引鍵相當合理。

Diagram that shows the customer partition key as ID.

在這裡您可能會擔心，使識別碼成為分割區索引鍵，表示我們會有與客戶一樣多的邏輯分割區，而每個邏輯分割區只包含單一文件。 數百萬個客戶會產生數百萬個邏輯分割區。

但這完全沒問題！ 邏輯分割區是一種虛擬概念，而且您可以擁有的邏輯分割區數目沒有限制。 Azure Cosmos DB 將在相同的實體分割區上共置多個邏輯分割區。 邏輯分割區的數目或大小增加時，Cosmos DB 會在需要時將其移至新的實體分割區。