調整預留輸送量的最佳做法

本文說明調整資料庫或容器輸送量的最佳做法和策略（集合、數據表或圖表）。 當您針對任何 Azure Cosmos DB API 增加布建的手動要求單位數（RU/秒）或任何資源的自動調整最大 RU/秒時，適用這些概念。

必要條件

• 如果您不熟悉 Azure Cosmos DB 中的數據分割和調整，請參閱 Azure Cosmos DB 中的數據分割和水平調整。
• 如果您計劃因 429 個例外狀況而調整 RU/秒，請檢閱 診斷和疑難解答「要求率太大」（429） 例外狀況中的指引。 提高 RU/秒之前，請先找出問題的根本原因，並確認提高 RU/秒是否為適當的解決方案。

縮放 RU/秒的背景

當您傳送要求來增加資料庫或容器的 RU/秒時，視您所要求的 RU/秒和目前的實體分割區配置而定，相應增加作業會立即或異步完成（通常是 4-6 小時）。

• 立即相應增加：

  • 當目前的實體分割區配置可支援您所要求的 RU/秒時，Azure Cosmos DB 即不需要分割或新增分割區。
  • 因此，此作業會立即完成，RU/秒也可供使用。

• 異步相應增加：

  • 當要求的 RU/秒高於實體分割區配置所支援的內容時，Azure Cosmos DB 會分割現有的實體分割區。 這項作業會持續進行，直到資源具備的最低分割區數目可支援所要求的 RU/秒為止。
  • 因此，可能需要一些時間才能完成作業，通常是 4-6 小時。 每個實體分割區最多可支援 10,000 RU/秒 (適用於所有 API) 的輸送量和 50 GB 的儲存體 (適用於所有 API，但 Cassandra 除外，其儲存體為 30 GB)。

  注意

  如果您在異步相應增加作業進行時執行 變更寫入區域作業 或 新增/移除新區域 ，輸送量相應增加作業會暫停。 當故障轉移或新增/移除區域作業完成時，它會自動繼續。

• 立即相應減少：

  • 針對相應減少作業，Azure Cosmos DB 不需要分割或新增分割區。
  • 因此，此作業會立即完成，RU/秒也可供使用。
  • 此作業的主要結果是減少每個實體分割區的 RU。

如何在不變更分割區配置的情況下擴大 RU/秒

步驟 1：尋找目前實體分割區數目

瀏覽至 [見解]>[輸送量]>[Normalized RU Consumption (%) By PartitionKeyRangeID] \(依 PartitionKeyRangeID 排序的標準化 RU 使用量 (%)\)。 計算相異的 PartitionKeyRangeId 數目。

每個 PartitionKeyRangeId 會對應至一個實體分割區，並指派來保存某範圍可能雜湊值的資料。

Azure Cosmos DB 會根據您的分割區索引鍵，將資料分散到邏輯和實體分割區，以啟用水平縮放。 寫入資料時，Azure Cosmos DB 會使用分割區索引鍵值的雜湊，來判斷資料位於哪個邏輯和實體分割區。

步驟 2：計算預設最大輸送量

Current number of physical partitions * 10,000 RU/s 是可以擴縮的最高 RU/秒，此範圍內都不會觸發 Azure Cosmos DB 將分割區分割。

您可以從 Azure Cosmos DB 資源提供者取得此值。 在資料庫或容器輸送量設定物件上執行 GET 要求，然後擷取 instantMaximumThroughput 屬性。 此值也可在入口網站中資料庫或容器的 [ 調整和設定 ] 頁面中取得。

範例

假設您現有的容器具有五個實體分割區和 30,000 RU/秒的手動布建輸送量。 您可以立即增加 RU/秒 5 * 10,000 RU/s = 50,000 RU/s 。 同樣地，如果某個容器具有 30,000 RU/秒的自動調整最大 RU/秒 (可在 3000-30,000 RU/秒之間擴縮)，我們就可以立即將最大 RU/秒提高至 50,000 RU/秒 (可在 5000-50,000 RU/秒之間擴縮)。

如何確保非同步擴縮期間資料能平均散發

背景

當您將 RU/秒增加到目前的 數目 physical partitions * 10,000 RU/s之後，Azure Cosmos DB 會分割現有的分割區，直到新的分割區數目 = ROUNDUP(requested RU/s / 10,000 RU/s)為止。 在分割期間，系統會將父分割區分割成兩個子分割區。

例如，假設您有一個容器，其中包含三個實體分割區和 30,000 RU/秒的手動布建輸送量。 如果您將輸送量增加到 45,000 RU/秒，Azure Cosmos DB 會分割兩個現有的實體分割區，因此總共會有 ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 physical partitions。

如果您有與記憶體和要求磁碟區平均分散的工作負載，通常是透過像 這樣的 /id高基數位段進行分割來完成，建議您設定 RU/秒，讓所有分割區在相應增加時平均分割。

若要查看原因，讓我們以您現有的容器為例，其中包含兩個實體分割區、20,000 RU/秒和 80 GB 的數據。

由於選擇具有高基數的良好分割區索引鍵，因此資料大致平均分散在兩個實體分割區中。 每個實體分割區大約會指派 50% 的 keyspace ，其定義為可能雜湊值的總範圍。

此外，Azure Cosmos DB 會將 RU/秒平均分散給所有實體分割區。 因此，每個實體分割區都有 10,000 RU/秒和 50% (40 GB) 的總資料量。 下圖顯示我們目前的狀態。

現在，假設您想要將 RU/秒從 20,000 RU/秒增加到 30,000 RU/秒。

如果您只是將 RU/秒增加至 30,000 RU/秒，則只會分割其中一個分割區。 分割之後，您有：

• 包含 50 個資料% 的數據分割（此分割區未分割）。
• 每個分割區包含 25 個% 的數據分割（這些是分割父系所產生的子分割區）。

由於 Azure Cosmos DB 會平均散發 RU/秒到所有實體分割區，因此每個實體分割區仍會取得 10,000 RU/秒。 不過，您現在在記憶體和要求散發中有扭曲。

在下圖中，分割區 3 和 4（分割區 2 的子數據分割）各有 10,000 RU/秒，以處理 20 GB 數據的要求，而分割區 1 有 10,000 RU/秒，以提供數據量兩倍的要求（40 GB）。

若要維護偶數記憶體散發，您可以先相應增加 RU/秒，以確保每個分割區分割。 然後，您可以將 RU/秒降低到所需的狀態。

因此，如果您從兩個實體分割開始，若要保證分割區甚至是分割后，您需要設定 RU/秒，讓最終會有四個實體分割區。 若要達成此目的，請先設定 RU/s = 4 * 10,000 RU/s per partition = 40,000 RU/s。 然後，在分割完成之後，將 RU/秒降低至 30,000 RU/秒。

因此，每個實體分割區都會取得 30,000 RU/s / 4 = 7500 RU/s 20 GB 數據的要求。 整體而言，您甚至會維護跨分割區的儲存和要求散發。

一般公式

步驟 1：提高您的 RU/秒，以確保所有分割區平均分割

一般來說，如果您的實體分割區起始數目是 P，而且想要設定所需的 RU/秒為 S：

將 RU/秒提高到：10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P))))。 這可提供最接近所需值的 RU/秒，以確保所有分割區平均分割。

步驟 2：將 RU/秒降低為所需的 RU/秒

舉例來說，假設我們有五個實體分割區，50,000 RU/秒，而且想要調整至 150,000 RU/秒。 我們應該先設定： 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200,000 RU/s，然後降低至 150,000 RU/秒。

當我們擴大至 200,000 RU/秒時，未來可以設定的最低手動 RU/秒就是 2000 RU/秒。 我們可以設定的最低自動調整 RU/秒上限為 20,000 RU/秒 (可在 2000 - 20,000 RU/秒之間擴縮)。 由於我們的目標 RU/秒為 150,000 RU/秒，因此不會受到最小 RU/秒的影響。

如何最佳化 RU/秒以進行大型資料內嵌

當您打算將大量資料移轉或內嵌至 Azure Cosmos DB 時，建議您設定容器的 RU/秒，讓 Azure Cosmos DB 預先佈建所需的實體分割區，以儲存您打算預先內嵌的資料總量。 否則，在擷取期間，Azure Cosmos DB 可能必須分割分割區，這會增加數據擷取的時間。

我們可以利用這項事實：在建立容器時，Azure Cosmos DB 會使用起點 RU/秒的啟發式公式，來計算一開始使用的實體分割區數目。

步驟 1：檢閱分割區索引鍵的選擇

請遵循選擇分割區索引鍵的 最佳做法 ，以確保您甚至可以在移轉後散發要求磁碟區和記憶體。

步驟 2：計算您需要的實體分割區數目

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

每個實體分割區最多可保存 50 GB 的儲存體 (30 GB 用於 Cassandra API)。 您應該針對 GB 中每個實體分割 區的目標數據選擇值取決於實體分割區的完整封裝程度，以及移轉後記憶體預期會成長多少。

例如，如果您預期記憶體會繼續成長，您可以選擇將值設定為 30 GB。 假設您選擇一個平均分散記憶體的良好分割區索引鍵，則每個分割區都是 ~60% 完整（50 GB 的 30 GB）。 在寫入未來的資料時，系統可以將資料儲存在現有的實體分割區，而不需要讓服務立即新增更多實體分割區。

相反地，如果您認為記憶體不會在移轉后大幅成長，您可以選擇設定較高的值，例如 45 GB。 這表示每個分割區都是 ~90% 完整（50 GB 的 45 GB）。 如此可將資料分散到的實體分割區數目降至最低，也表示每個實體分割區可取得絕大多數的總佈建 RU/秒。

步驟 3：計算所有分割區一開始使用的 RU/秒數目

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition

請從具有每個實體分割區的任意目標 RU/秒數目的範例開始。

• Initial throughput per physical partition = 10,000 RU/s per physical partition 使用自動調整或共用輸送量資料庫時
• Initial throughput per physical partition = 6000 RU/s per physical partition 使用手動輸送量時

範例

假設您有 1 TB（1,000 GB）的數據要內嵌，而您想要使用手動輸送量。 Azure Cosmos DB 中的每個實體分割區都有 50 GB 的容量。 假設您的目標是將分割區封裝為80% 完整 （40 GB），為未來的成長留出空間。

這表示針對 1 TB 的數據，您需要 1000 GB / 40 GB = 25 實體分割區。 若要確保您取得 25 個實體分割區，請使用手動輸送量，先佈建 25 * 6000 RU/s = 150,000 RU/s。 然後，建立容器之後，為了協助擷取更快，請在擷取開始之前，將 RU/秒增加到 250,000 RU/秒（因為您已經有 25 個實體分割區而立即發生）。 這可讓每個分割區取得最多 10,000 RU/秒。

如果您使用自動調整輸送量或共用輸送量資料庫，若要取得 25 個實體分割區，您必須先布建 25 * 10,000 RU/s = 250,000 RU/s。 由於您已處於 25 個實體分割區可支援的最高 RU/秒，因此在擷取之前，您不會進一步增加我們布建的 RU/秒。

理論上，如果我們假設需要 1 kb 檔和 10 個 RU 才能寫入，則擷取在理論上可以完成： 1000 GB * (1,000,000 kb / 1 GB) * (1 document / 1 kb) * (10 RU / document) * (1 sec / 250,000 RU) * (1 hour / 3600 seconds) = 11.1 hours。

這項計算是假設執行內嵌的用戶端可以完全佔滿輸送量，並將寫入分散到所有實體分割區的估計值。 最佳做法是建議 在用戶端上隨機顯示 您的數據。 如此可確保用戶端每秒都會寫入許多不同邏輯 (也就是實體) 分割區。

移轉完成後，您可以降低 RU/秒，或視需要啟用自動調整。

下一步

• 如何監視 Azure Cosmos DB 容器或帳戶的標準化 RU/秒
• 診斷和疑難解答「要求率太大」（429） 例外狀況
• 使用自動調整輸送量來建立 Azure Cosmos DB 容器和資料庫