共用方式為


調整佈建輸送量 (RU/秒) 的最佳做法

適用於:NoSQL MongoDB Cassandra Gremlin 桌子

本文說明縮放資料庫或容器 (集合、資料表或圖表) 輸送量 (RU/秒) 的最佳做法和策略。 這些概念適用於針對任何 Azure Cosmos DB API 任何資源,提高佈建手動 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 圖表計算標準化 RU 使用量中的不同 PartitionKeyRangeId 數目

注意

圖表最多會顯示 50 個 PartitionKeyRangeId。 如果資源數超過 50,您可以使用 Azure Cosmos DB REST API 來計算分割區總數。

每個 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/秒 = 50,000 RU/秒。 同樣地,如果某個容器具有 30,000 RU/秒的自動調整最大 RU/秒 (可在 3000-30,000 RU/秒之間擴縮),我們就可以立即將最大 RU/秒提高至 50,000 RU/秒 (可在 5000-50,000 RU/秒之間擴縮)。

提示

如果您要擴大 RU/秒以回應要求率太大的例外狀況 (429),建議您先將 RU/秒提高到目前實體分割區配置所支援的最高 RU/秒,並評估新的 RU/秒是否足夠,之後再進一步提高。

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

背景

當您將 RU/秒提高到超過目前的實體分割區數目 * 10,000 RU/秒時,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 個實體分割區。

注意

應用程式一律可以在分割期間內嵌或查詢資料。 Azure Cosmos DB 用戶端 SDK 和服務會自動處理此案例,並確保將要求路由傳送至正確的實體分割區,所以不需要額外的使用者動作。

如果工作負載的儲存和要求量非常平均分散 (通常是由 /id 這類高基數欄位來分割),建議您在擴大時將 RU/秒設定為可讓所有分割區平均分割。

為了解原因,讓我們來看一個範例,假設某個容器具有 2 個實體分割區、20,000 RU/秒和 80 GB 的資料。

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

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

兩個 PartitionKeyRangeIds,每個索引鍵空間各有 10,000 RU/秒、40 GB 和 50% 的總索引鍵空間

現在,假設我們想將 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) 的要求。

分割後會有 3 個 PartitionKeyRangeIds,每個都有 10,000 RU/秒。不過其中一個 PartitionKeyRangeIds 擁有總索引鍵空間 (40 GB) 的 50%,而 PartitionKeyRangeIds 中有 25% 的總索引鍵空間 (20 GB)

若要維持儲存量平均分配,我們可以先擴大 RU/秒,以確保每個分割區都能分割。 然後,我們可以將 RU/秒縮小回預期的狀態。

因此,如果我們一開始是使用兩個實體分割區,為了保證分割區在分割之後仍保持平均,我們必須將 RU/秒設定為最後能有四個實體分割區。 為了達到此目的,我們會先為每個分割區設定 RU/秒 = 4 * 10,000 RU/秒 = 40,000 RU/秒。 然後,在分割完成之後,我們即可將 RU/秒降低為 30,000 RU/秒。

如此一來,即為下圖所示,每個實體分割區取得 30,000 RU/秒/4 = 7500 RU/秒來服務 20 GB 資料的要求。 整體來說,我們會維持各分割區的儲存和要求量平均分配。

分割完成且 RU/秒從 40,000 RU/秒降低至 30,000 RU/秒之後,每個索引鍵空間有 4 個 PartitionKeyRangeIds,每個索引鍵空間 7500 RU/秒,佔總索引鍵空間的 25% (20 GB)

一般公式

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

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

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

注意

當您提高資料庫或容器的 RU/秒時,可能會影響您未來可降低的 RU/秒下限。 通常,最小 RU/秒為 MAX(400 RU/秒,目前的儲存體 (GB) * 1 RU/秒,曾佈建的最高 RU/秒/100)。 例如,如果您已調整的最高 RU/秒為 100,000 RU/秒,則未來可以設定的最低 RU/秒是 1000 RU/秒。 深入了解最小 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/秒,然後再降低至 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)。 您應該選擇哪種 Target data per physical partition in 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/秒 (使用自動調整或共用輸送量資料庫時)
  • Initial throughput per physical partition = 每個實體分割區 6,000 RU/秒 (使用手動輸送量時)

範例

假設我們打算內嵌 1 TB (1000 GB) 資料,並想要使用手動輸送量。 Azure Cosmos DB 中的每個實體分割區都有 50 GB 的容量。 假設我們的目標是讓分割區佔用 80% 容量 (40 GB),保留空間以供未來成長之用。

這表示,針對 1 TB 的資料,我們需要 1000 GB/40 GB = 25 個實體分割區。 為了確保得到 25 個實體分割區,如果我們使用手動輸送量,我們要先佈建 25 * 6000 RU/秒 = 150,000 RU/秒。 然後,在建立容器之後,為了讓內嵌速度更快,我們會先將 RU/秒提高到 250,000 RU/秒,再開始內嵌 (因為我們已經有 25 個實體分割區,所以內嵌會立即進行)。 這可讓每個分割區取得最多 10,000 RU/秒。

如果我們使用自動調整輸送量或共用輸送量資料庫,為了取得 25 個實體分割區,我們要先佈建 25 * 10,000 RU/秒 = 250,000 RU/秒。 由於我們已經達到可支援 25 個實體分割區的最高 RU/秒,因此不用在內嵌之前提高佈建的 RU/秒。

理論上,使用 250,000 RU/秒和 1 TB 的資料時,假設有 1 KB 文件和 10 RU 需要寫入,內嵌完成時間為:1000 GB * (1,000,000 KB/1 GB) * (1 個文件/1 KB) * (10 RU/文件) * (1 秒/250,000 RU) * (1 小時/3600 秒) = 11.1 小時。

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

完成移轉之後,我們即可降低 RU/秒,或視需要啟用自動調整。

下一步