在 Azure Cosmos DB 中最佳化要求成本

發行項
03/25/2024

適用於：NoSQL MongoDB Cassandra Gremlin Table

本文說明如何將讀取和寫入要求轉譯為要求單位，以及如何最佳化這些要求的成本。讀取作業包括點讀取和查詢。寫入作業包括插入、取代、刪除和更新插入項目。

Azure Cosmos DB 提供一組豐富的資料庫作業，可操作容器內的項目。與上述各項作業相關聯的成本，會因為完成作業所需的 CPU、IO 和記憶體而不同。您可將要求單位 (RU) 視為因應要求而執行各種資料庫作業時所需資源的單一量值，而無須考慮及管理硬體資源。

測量要求的 RU 費用

您必須測量要求的 RU 費用，以了解其實際成本，並評估最佳化的有效性。您可使用 Azure 入口網站來擷取這項成本，或檢查透過其中一個 SDK 從 Azure Cosmos DB 傳回的回應。如需如何達成此目標的詳細指示，請參閱尋找 Azure Cosmos DB 中的要求單位費用。

讀取資料：點讀取和查詢

Azure Cosmos DB 中的讀取作業通常依 RU 使用量來排序，從最快/效率最高到較慢/效率較低，如下所示：

點讀取 (單一項目識別碼和分割區索引鍵的索引鍵/值查閱)。
單一分割區索引鍵內具有篩選子句的查詢。
任何屬性上不具等號比較或範圍篩選子句的查詢。
不含篩選的查詢。

一致性層級的角色

使用強式或限定過期一致性層級時，任何讀取作業 (點讀取或查詢) 的 RU 成本皆為雙倍。

點讀取

除了使用的一致性層級以外，影響點讀取 RU 費用的唯一因素是所擷取項目的大小。下表顯示大小為 1 KB 與 100 KB 的項目點讀取 RU 成本。

項目大小	單點讀取的成本
1 KB	1 RU
100 KB	10 RU

由於點讀取 (該項目識別碼和分割區索引鍵的索引鍵/值查閱) 是最有效率的讀取類型，因此應確定項目識別碼使用有意義的值，以便在適用時透過點讀取 (而非查詢) 來擷取項目。

注意

在適用於 NoSQL 的 API 中，只能使用 REST API 或 SDK 進行點讀取。篩選專案識別碼和資料分割區索引鍵的查詢不會被視為點讀取。若要查看使用 .NET SDK 的範例，請參閱讀取 Azure Cosmos DB for NoSQL 中的項目。

查詢

查詢的要求單位取決於許多因素。例如，載入/傳回的 Azure Cosmos DB 項目數、索引查閱次數，以及查詢編譯時間等詳細資料。 Azure Cosmos DB 保證在相同資料上執行時，相同的查詢將一律使用相同數量的要求單位，即使重複執行也是如此。使用查詢執行計量的查詢設定檔，可讓您清楚了解要求單位的使用情況。

在某些情況下，您可能會在分頁式查詢執行中看到一連串的 200 和 429 回應以及變數的要求單位，這是因為查詢會根據可用的 RU 盡快執行。您可能會看到查詢執行分成伺服器和用戶端之間的多個頁面/來回行程。例如，10,000 個項目可能會以多個頁面傳回，每個頁面根據該頁面上執行的計算來收費。當您加總這些頁面時，您應該取得與整個查詢相同的 RU 數。

用於疑難排解查詢的計量

查詢 (含使用者定義的函式) 所耗用的效能和輸送量主要取決於函式主體。若要找出 UDF 中查詢執行所耗的時間和 RU 數目，最簡單的方式即是啟用查詢計量。若您使用 .NET SDK，以下為 SDK 所傳回的查詢計量範例：

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs

最佳化查詢成本的最佳做法

在最佳化查詢成本時，請考慮下列最佳做法：

共置多個實體類型

嘗試在單一或更少數量的容器內共置多個實體類型。此方法不僅可以從定價的觀點獲益，還可以從查詢執行和交易中獲益。查詢範圍侷限於單一容器；透過預存程序/觸發程序將多個記錄上不可部分完成交易設定為單一容器內的資料分割索引鍵。在相同容器中共置實體可以減少網路來回行程次數，以解析記錄之間的關聯性。因此，它可以提高端對端效能、為較大的資料集啟用多個記錄的不可部分完成交易，從而降低成本。如果在您的案例中，難以在單一或更少數量的容器中共置多個實體類型，通常是因為您正在移轉現有的應用程式，且您不希望進行任何程式碼變更 - 則您應該考慮佈建資料庫層級的輸送量。
測量和調整較低的要求單位/秒使用量

查詢的複雜性會影響針對作業所耗用的要求單位 (RU) 數量。述詞數目、述詞性質、UDF 數目，以及來源資料集的大小。所有這些因素都會影響查詢作業的成本。

Azure Cosmos DB 採用已佈建的輸送量模型，在輸送量和延遲方面提供可預測的效能。佈建的輸送量以每秒要求單位或 RU/每秒表示。要求單位 (RU) 是對執行要求所需之運算資源 (例如 CPU、記憶體、IO 等) 的邏輯抽象概念。佈建的輸送量 (RU) 被預留並專用於您的容器或資料庫，以提供可預測的輸送量和延遲。佈建的輸送量使 Azure Cosmos DB 能夠以任何規模提供可預測且一致的效能、保證低延遲，以及高可用性。要求單位代表標準化的貨幣，可簡化應用程式所需之資源的數量推論。

要求標頭中傳回的要求費用表示給定查詢的成本。例如，如果查詢傳回 1000 個 1 KB 項目，則作業成本會是 1000。因此在一秒內，伺服器在對後續要求進行速率限制前，只會接受兩個這類要求。如需詳細資訊，請參閱要求單位一文和要求單位計算機。

寫入資料

寫入項目的 RU 成本取決於：

項目大小。
索引編製原則所涵蓋且須編製索引的屬性數目。

插入編製索引成本約為 5.5 RU 以下的 1 KB 項目。取代項目成本為插入相同項目所需成本的兩倍。

最佳化寫入

讓寫入作業 RU 成本最佳化的最佳做法，即是將項目及要編製索引的屬性數目設為適當規模。

在 Azure Cosmos DB 中儲存非常大型的項目會導致 RU 費用高昂，且可視為反面模式。尤其是，請勿儲存不需要查詢的二進位內容或大型文字區塊。最佳做法是將這類資料置於 Azure Blob 儲存體，並在寫入 Azure Cosmos DB 的項目中儲存 Blob 的參考 (或連結)。
若最佳化您的索引編製原則，僅為查詢所篩選的屬性編製索引，寫入作業所耗用的 RU 便可有顯著差異。建立新容器時，預設的索引編製原則會為項目中所找到的各屬性編製索引。雖然此為開發作業適用的預設值，但當您進入生產環境或工作負載開始收到大量流量時，強烈建議重新評估並自訂索引編製原則。

執行大量資料擷取時，也建議您使用 Azure Cosmos DB 大量執行工具程式庫，因為該工具專門用於最佳化這類作業的 RU 耗用量。您也可選用相同程式庫中建立的 Azure Data Factory。

下一步

接下來，您可以利用下列文章繼續深入了解 Azure Cosmos DB 中有關成本最佳化的詳細資訊：

深入了解最佳化開發與測試
深入了解 Azure Cosmos DB 帳單
深入了解最佳化輸送量成本
深入了解最佳化儲存體成本
深入了解將多重區域 Azure Cosmos DB 帳戶的成本最佳化
深入了解 Azure Cosmos DB 保留容量
正在嘗試為遷移至 Azure Cosmos DB 進行容量規劃嗎？您可以使用現有資料庫叢集的相關資訊進行容量規劃。
- 如果您知道現有資料庫叢集中的虛擬核心和伺服器數目，請參閱使用虛擬核心或 vCPU 來估計要求單位
- 如果您知道目前資料庫工作負載的一般要求率，請參閱使用 Azure Cosmos DB 容量規劃工具來估計要求單位