Azure Cosmos DB 中的資料分割和水平調整

適用於： NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB 會使用資料分割來調整資料庫中的個別容器以符合您應用程式效能需求。 容器中的項目分割成不同子集，稱為邏輯分割區。 邏輯分割區是根據與容器中每個項目相關聯的分割區索引鍵值而形成的。 邏輯分割區中的所有項目都有相同的分割區索引鍵值。

例如，容器會保存項目。 每個項目針對 UserID 屬性都會有唯一的值。 如果 UserID 用來作為容器中項目的分割區索引鍵，而且有 1,000 個唯一的 UserID 值，則系統會為該容器建立 1,000 個邏輯分割區。

除了決定項目邏輯分割區的分割區索引鍵之外，容器中的每個項目都會有項目識別碼 (其在邏輯分割區內是唯一的)。 透過結合分割區索引鍵和項目識別碼，會建立項目的索引，其能唯一識別該項目。 選擇分割區索引鍵 是影響應用程式效能的重要決策。

本文說明邏輯與實體分割區之間的關聯性。 其也會討論資料分割的最佳做法，並深入檢視水平縮放在 Azure Cosmos DB 中的運作方式。 您不需要瞭解這些內部詳細資料來選取分割區索引鍵，但我們已涵蓋它們，因此您清楚瞭解 Azure Cosmos DB 的運作方式。

邏輯分割區

邏輯分割區是由一組具有相同分割區索引鍵的項目所組成。 例如，在包含食物營養相關資料的容器中，所有項目都會包含一個 foodGroup 屬性。 您可以使用 foodGroup 作為容器的分割區索引鍵。 針對 foodGroup 具有特定值的項目群組，例如 Beef Products、Baked Products 和 Sausages and Luncheon Meats，會形成不同的邏輯分割區。

邏輯分割區也會定義資料庫交易的範圍。 您可以使用含有快照集隔離的交易來更新邏輯分割區內的項目。 將新專案新增至容器時，系統會以透明方式建立新的邏輯分割區。 刪除底層資料時，您不需要擔心會刪除邏輯分割區。

容器中的邏輯分割區數目沒有限制。 每個邏輯分割區最多可以儲存 20 GB 的資料。 良好的分割區索引鍵選項有各式各樣的可能值。 例如，在所有項目都包含 foodGroup 屬性的容器中，Beef Products 邏輯分割區內的資料最多可成長至 20 GB。 選取具有各種可能值的分割區索引鍵可確保容器能夠調整規模。

您可以使用 Azure 監視器警示來監視邏輯分割區的大小是否已接近 20 GB。

實體分割區

容器的調整方式是在實體分割區之間分配資料和輸送量。 就內部而言，會有一或多個邏輯分割區對應至單一實體分割區。 通常較小的容器具有許多邏輯分割區，但其只需要單一實體分割區。 不同于邏輯分割區，實體分割區是系統的內部實作，而 Azure Cosmos DB 會完全管理實體分割區。

容器中的實體分割區數目取決於下列特性：

• 所佈建的輸送量數目 (每個個別的實體分割區可以提供每秒最多 10,000 個要求單位的輸送量)。 實體分割區每秒 10,000 RU 的限制，表示邏輯分割區也會有每秒 10,000 RU 的限制，因為每個邏輯分割區只對應到一個實體分割區。

• 每個個別實體分割區的資料儲存體 (最多可以儲存 50 GB 的資料) 。

注意

實體分割區是系統的內部實作，而且完全由 Azure Cosmos DB 管理。 開發解決方案時，請勿專注於實體分割區，因為您無法加以控制。 相反地，請將焦點放在您的分割區索引鍵上。 如果您選擇會將輸送量耗用量平均分配給邏輯分割區的分割區索引鍵，您將可確保跨實體分割區的輸送量耗用量是平衡的。

容器中的實體分割區總數沒有限制。 隨著布建的輸送量或資料大小成長，Azure Cosmos DB 會藉由分割現有的資料分割來自動建立新的實體分割區。 實體分割區分割不會影響應用程式的可用性。 分割實體分割區之後，單一邏輯分割區內的所有資料仍會儲存在相同的實體分割區上。 實體分割區分割只會在邏輯分割區與實體分割區之間建立新對應。

為容器佈建的輸送量會在實體分割區之間平均分配。 未平均分散要求的分割區索引鍵設計，可能會導致系統將太多要求導向一小部分的分割區，使其變成「經常性存取」。經常性存取分割區會使所佈建輸送量的使用效率不佳，這可能會導致速率限制和更高的成本。

您可以在 Azure 入口網站 [計量] 刀鋒視窗的 [儲存體] 區段中，看到容器的實體分割區：

例如，請考慮具有指定為分割區索引鍵之路徑 /foodGroup 的容器。 容器可以有任意數目的實體分割區，但在此範例中，我們假設它有三個。 單一實體分割區可能包含多個分割區索引鍵。 例如，最大的實體分割區可能包含前三大最大大小的邏輯分割區： Beef Products 、 Vegetable and Vegetable Products 和 Soups, Sauces, and Gravies 。

如果您指派每秒 18,000 個要求單位的輸送量， (RU/秒) ，則這三個實體分割區中的每一個都可以利用總布建輸送量的 1/3。 在選取的實體分割區內，邏輯分割區索引鍵 Beef Products、Vegetable and Vegetable Products 和 Soups, Sauces, and Gravies 合起來可以利用實體分割區佈建的 6,000 RU/S。 因為布建的輸送量會平均分割到容器的實體分割區，所以請務必選擇平均分散輸送量耗用量的資料分割索引鍵。 如需詳細資訊，請參閱 選擇正確的邏輯分割區索引鍵。

管理邏輯分割區

Azure Cosmos DB 會以透明的方式自動管理在實體分割區上的邏輯分割區放置，以便有效率地滿足容器的可擴縮性和效能需求。 當應用程式的輸送量和儲存體需求增加時，Azure Cosmos DB 就會移動邏輯分割區，以自動將負載分散到更多實體分割區上。 您可以深入了解實體分割區。

Azure Cosmos DB 會使用雜湊型資料分割，來將邏輯分割區分散到實體分割區上。 Azure Cosmos DB 會對項目的分割區索引鍵值進行雜湊處理。 雜湊的結果會決定實體分割區。 Azure Cosmos DB 會在實體分割區上平均配置分割區索引鍵雜湊的索引鍵空間。

僅允許針對單一邏輯分割區中的項目進行交易 (在預存程序或觸發程序中)。

複本集

每個實體分割區都是由一組複本所組成，其也稱為複本集。 每個複本都會裝載資料庫引擎的執行個體。 複本集可讓資料存放區位於實體分割區持久、高可用性且一致。 組成實體分割區的每個複本都會繼承分割區的儲存體配額。 實體分割區的所有複本會集體支援配置給實體分割區的輸送量。 Azure Cosmos DB 會自動管理複本集。

一般而言，較小的容器只需要單一實體分割區，但它們仍然至少有四個複本。

下圖顯示如何將邏輯分割區對應至全域散發的實體分割區。 映像中的分割集指的是跨多個區域管理相同邏輯分割區索引鍵的一組實體分割區：

選擇分割區索引鍵

分割區索引鍵有兩個元件：分割區索引鍵路徑和分割區索引鍵值。 例如，假設有一個項目 { "userId" : "Andrew", "worksFor": "Microsoft" } 如果您選擇 "userId" 作為分割區索引鍵，則下列為兩個分割區索引鍵元件：

• 分割區索引鍵路徑 (例如："/userId")。 分割區索引鍵路徑接受英數位元和底線 (_) 字元。 您也可以使用標準路徑標記法 (/) 來使用巢狀物件。

• 分割區索引鍵值 (例如："Andrew")。 分割區索引鍵值可以是字串或數值類型。

若要了解輸送量、儲存體和分割區索引鍵長度的限制，請參閱 Azure Cosmos DB 服務配額一文。

選取分割區索引鍵是 Azure Cosmos DB 中簡單但重要的設計選擇。 選取分割區索引鍵之後，就無法就地變更它。 如果您需要變更分割區索引鍵，則應該將您的資料移至具有所需新分割區索引鍵的新容器。 (容器複製工作可協助進行此程序。)

對於所有容器而言，您的分割區索引鍵應該：

• 為具有值的屬性，不會變更。 如果屬性是分割區索引鍵，您便無法更新該屬性的值。

• 如果根據IEEE 754 binary64，應該只包含 String 值 - 或數位應該最好轉換成 String ，否則它們可能超出雙精確度數位的界限。 Json 規格會指出為什麼使用此界限外數字通常會因為可能的互通性問題，而不是理想做法。 這些考慮特別與分割區索引鍵資料行相關，因為它不可變，而且需要資料移轉才能稍後進行變更。

• 具有較高的基數。 換句話說，屬性應該有各種可能的值。

• 將要求單位 (RU) 使用量和資料儲存體平均分散至所有邏輯分割區。 分配可確保 RU 使用量與儲存體平均分配在實體分割區。

• 具有通常不超過 2048 個位元組的值，如果未啟用大型資料分割索引鍵，則為 101 個位元組。 如需詳細資訊，請參閱 大型分割區索引鍵

如果您需要 Azure Cosmos DB 中的 多專案 ACID 交易 ，則必須使用 預存程式或觸發程式。 所有 JavaScript 型的預存程序和觸發程序的範圍都是單一邏輯分割區。

注意

如果您只有一個實體分割區，分割區索引鍵的值可能不重要，因為所有查詢都會以相同的實體分割區為目標。

大量讀取容器的分割區索引鍵

對於大部分的容器，在挑選分割區索引鍵時，您只需要考慮上述準則。 不過，對於大型的大量讀取容器而言，建議您選擇經常在查詢中顯示為篩選的分割區索引鍵。 藉由在篩選述詞中包括分割區索引鍵，可以有效率地將查詢路由傳送至相關的實體分割區。

如果大部分工作負載的要求都是查詢，而且大部分的查詢在相同屬性上具有相等篩選，則此屬性可以是良好的分割區索引鍵選擇。 例如，如果您經常執行會篩選 UserID 的查詢，則選取 UserID 作為分割區索引鍵將能減少跨分割區查詢的數目。

不過，如果您的容器很小，您可能沒有足夠的實體分割區需要擔心跨分割區查詢的效能。 Azure Cosmos DB 中最小的容器只需要一或兩個實體分割區。

如果您的容器可能會成長為具備多個實體分割區，則您應該挑選能將跨分割區查詢最小化的分割區索引鍵。 當下列任一項成立時，您的容器需要多個實體分割區：

• 您的容器已布建超過 30,000 個 RU

• 您的容器會儲存超過 100 GB 的資料

使用項目識別碼作為分割區索引鍵

注意

本節主要適用于 NoSQL 的 API。 其他 API，例如 Gremlin 的 API，不支援唯一識別碼作為分割區索引鍵。

如果您的容器具有具有各種可能值的屬性，則可能是絕佳的分割區索引鍵選擇。 這類屬性的其中一個可能範例是項目識別碼。 對於任何大小的小型大量讀取容器或大量寫入容器， 專案 識別碼 () /id 自然是分割區索引鍵的絕佳選擇。

容器中的每個項目都有系統屬性項目識別碼。 您可能有其他屬性以表示項目的邏輯識別碼。 在許多情況下，這些識別碼也是絕佳的分割區索引鍵選擇，原因與 專案識別碼相同。

項目識別碼是絕佳的分割區索引鍵選擇，原因如下：

• 有各種可能的值 (每個項目有一個唯一項目識別碼)。
• 因為每個專案都有唯一 的專案識別碼 ， 所以專案識別碼 會在平均平衡 RU 耗用量和資料儲存體時執行絕佳的工作。
• 您可以輕鬆地執行有效率的點讀取，因為如果您知道專案識別碼，一律知道 專案的分割區索引鍵。

選取項目識別碼作為分割區索引鍵時，需要考慮的某些事項包括：

• 如果 專案識別碼 是分割區索引鍵，它會在整個容器中變成唯一識別碼。 您無法建立具有重複 專案識別碼的專案。
• 如果您有具有許多 實體分割區的大量讀取容器，如果查詢具有 專案識別碼的相等篩選，則查詢會更有效率。
• 您無法執行以多個邏輯分割區為目標的預存程式或觸發程式。

後續步驟

• 了解 Azure Cosmos DB 中佈建的輸送量。
• 了解 Azure Cosmos DB 中的全域分散。
• 請參閱關於如何在 Azure Cosmos DB 中建立資料模型和分割的訓練課程模組。