优化 Azure Cosmos DB 中的请求成本Optimize request cost in Azure Cosmos DB

适用于: SQL API Cassandra API Gremlin API 表 API Azure Cosmos DB API for MongoDB

本文介绍了如何将读取和写入请求转换为请求单位,以及如何优化这些请求的成本。This article describes how read and write requests translate into Request Units and how to optimize the cost of these requests. 读取操作包括点读取和查询。Read operations include point reads and queries. 写入操作包括插入、替换、删除和更新插入项。Write operations include insert, replace, delete, and upsert of items.

Azure Cosmos DB 提供了对容器中的项进行操作的一组丰富的数据库操作。Azure Cosmos DB offers a rich set of database operations that operate on the items within a container. 与这些操作关联的成本取决于完成操作所需的 CPU、IO 和内存。The cost associated with each of these operations varies based on the CPU, IO, and memory required to complete the operation. 可以考虑将请求单位 (RU) 视为执行各种数据库操作来处理请求时所需的资源的单一度量值,而无需考虑和管理硬件资源。Instead of thinking about and managing hardware resources, you can think of a Request Unit (RU) as a single measure for the resources required to perform various database operations to serve a request.

度量请求的 RU 费用Measuring the RU charge of a request

请务必度量请求的 RU 费用,以了解其实际成本,并评估你的优化的效率。It is important to measure the RU charge of your requests to understand their actual cost and also evaluate the effectiveness of your optimizations. 你可以通过以下方式获取此成本:使用 Azure 门户,或者通过某个 SDK 检查 Azure Cosmos DB 发回的响应。You can fetch this cost by using the Azure portal or inspecting the response sent back from Azure Cosmos DB through one of the SDKs. 有关如何实现此目的的详细说明,请参阅在 Azure Cosmos DB 中查找请求单位费用See Find the request unit charge in Azure Cosmos DB for detailed instructions on how to achieve that.

读取数据:点读取和查询Reading data: point reads and queries

Azure Cosmos DB 中的读取操作通常按 RU 消耗从最快/效率最高到较慢/效率较低进行排序,如下所示:Read operations in Azure Cosmos DB are typically ordered from fastest/most efficient to slower/less efficient in terms of RU consumption as follows:

  • 点读取(对单个项 ID 和分区键进行键/值查找)。Point reads (key/value lookup on a single item ID and partition key).
  • 单个分区键内具有筛选器子句的查询。Query with a filter clause within a single partition key.
  • 针对任何属性都没有等于或范围筛选器子句的查询。Query without an equality or range filter clause on any property.
  • 不包含筛选器的查询。Query without filters.

一致性级别的角色Role of the consistency level

当使用 有限过期一致性级别时,任何读取操作(点读取或查询)的 RU 开销都会加倍。When using either the strong or bounded staleness consistency levels, the RU cost of any read operation (point read or query) is doubled.

点读取Point reads

影响点读取的 RU 费用的唯一因素(除了使用的一致性级别外)是所检索项的大小。The only factor affecting the RU charge of a point read (besides the consistency level used) is the size of the item retrieved. 下表显示了大小为 1 KB 和 100 KB 的项的点读取 RU 成本。The following table shows the RU cost of point reads for items that are 1 KB and 100 KB in size.

项大小Item Size 一次点读取成本Cost of one point read
1 KB1 KB 1 RU1 RU
100 KB100 KB 10 RU10 RUs

因为点读取(基于项 ID 的键/值查找)是最有效的读取类型,因此你应确保项 ID 具有有意义的值,以便可以在可能的情况下使用点读取(而非查询)来提取项。Because point reads (key/value lookups on the item ID) are the most efficient kind of read, you should make sure your item ID has a meaningful value so you can fetch your items with a point read (instead of a query) when possible.

查询Queries

查询的请求单位依赖于许多因素。Request units for queries are dependent on a number of factors. 例如,加载/返回的 Azure Cosmos 项的数量、对索引的查找次数、查询编译时间等详细信息。For example, the number of Azure Cosmos items loaded/returned, the number of lookups against the index, the query compilation time etc. details. Azure Cosmos DB 保证在相同数据上执行相同的查询时,即使重复执行,也始终使用相同数量的请求单位。Azure Cosmos DB guarantees that the same query when executed on the same data will always consume the same number of request units even with repeat executions. 使用查询执行指标的查询配置文件使你可以很好地了解请求单位的使用情况。The query profile using query execution metrics gives you a good idea of how the request units are spent.

在某些情况下,可能会在查询的分页执行中看到 200 个和 429 个响应序列以及变量请求单位,这是因为查询将根据可用的 RU 尽可能快地运行。In some cases you may see a sequence of 200 and 429 responses, and variable request units in a paged execution of queries, that is because queries will run as fast as possible based on the available RUs. 可能会看到查询执行在服务器和客户端之间分成多个页面/往返。You may see a query execution break into multiple pages/round trips between server and client. 例如,10,000 个项可以作为多个页面返回,每个页面根据对该页面执行的计算收费。For example, 10,000 items may be returned as multiple pages, each charged based on the computation performed for that page. 对这些页面求和时,应获得与整个查询相同的 RU 数。When you sum across these pages, you should get the same number of RUs as you would get for the entire query.

用于对查询进行故障排除的指标Metrics for troubleshooting queries

查询(包括用户定义的函数)的性能和消耗的吞吐量主要取决于函数主体。The performance and the throughput consumed by queries (including user-defined functions) mostly depend on the function body. 查找 UDF 中的查询执行花费的时间和使用的 RU 数量的最简单方法是启用查询指标。The easiest way to find out how much time the query execution is spent in the UDF and the number of RUs consumed, is by enabling the query metrics. 如果使用的是 .NET SDK,则以下是 SDK 返回的示例查询指标:If you use the .NET SDK, here are sample query metrics returned by the 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  

成本优化查询的最佳做法Best practices to cost optimize queries

优化成本查询时,请考虑以下最佳做法:Consider the following best practices when optimizing queries for cost:

  • 共置多个实体类型Colocate multiple entity types

    尝试在单个或较少数量的容器中共置多个实体类型。Try to colocate multiple entity types within a single or smaller number of containers. 此方法不仅对定价有好处,而且对查询执行和事务也有好处。This method yields benefits not only from a pricing perspective, but also for query execution and transactions. 查询的作用域为单个容器;通过存储过程/触发器的多个记录的原子事务的作用域为单个容器内的分区键。Queries are scoped to a single container; and atomic transactions over multiple records via stored procedures/triggers are scoped to a partition key within a single container. 在同一容器内共置实体可以减少网络往返次数,以便解析记录之间的关系。Colocating entities within the same container can reduce the number of network round trips to resolve relationships across records. 因此,它可以提高端到端性能,为较大的数据集启用多个记录的原子事务,从而降低成本。So it increases the end-to-end performance, enables atomic transactions over multiple records for a larger dataset, and as a result lowers costs. 如果你的情景难以在单个或较少数量的容器中共置多个实体类型,通常是因为你正在迁移现有应用程序且不希望进行任何代码更改 - 你应该考虑在数据库级别预配吞吐量。If colocating multiple entity types within a single or smaller number of containers is difficult for your scenario, usually because you are migrating an existing application and you do not want to make any code changes - you should then consider provisioning throughput at the database level.

  • 测量和优化较低的每秒请求单位使用量Measure and tune for lower request units/second usage

    查询的复杂性会影响操作使用的请求单位 (RU)数量。The complexity of a query impacts how many request units (RUs) are consumed for an operation. 谓词数、谓词性质、UDF 数目以及源数据集的大小。The number of predicates, nature of the predicates, number of UDFs, and the size of the source data set. 所有这些因素都会影响查询操作的成本。All these factors influence the cost of query operations.

通过使用预配置的吞吐量模型,Azure Cosmos DB 在吞吐量和延迟方面提供可预测的性能。Azure Cosmos DB provides predictable performance in terms of throughput and latency by using a provisioned throughput model. 预配的吞吐量以每秒请求单位或 RU/秒表示。The throughput provisioned is represented in terms of Request Units per second, or RU/s. 请求单位 (RU) 是对计算 CPU、内存、IO 等资源的逻辑抽象,这是执行请求所必需的。A Request Unit (RU) is a logical abstraction over compute resources such as CPU, memory, IO, etc. that are required to perform a request. 预留的预配吞吐量 (RU) 专用于容器或数据库,以提供可预测的吞吐量和延迟。The provisioned throughput (RUs) is set aside and dedicated to your container or database to provide predictable throughput and latency. 预配置吞吐量使 Azure Cosmos DB 能够以任何规模提供可预测且一致的性能,保证低延迟和高可用性。Provisioned throughput enables Azure Cosmos DB to provide predictable and consistent performance, guaranteed low latency, and high availability at any scale. 请求单位表示规范化货币,简化了对应用程序需要多少资源的推理。Request units represent the normalized currency that simplifies the reasoning about how many resources an application needs.

请求标头中返回的请求费用表示给定查询的费用。Request charge returned in the request header indicates the cost of a given query. 例如,如果查询返回 1000 个 1 KB 项,则操作成本为 1000。For example, if a query returns 1000 1-KB items, the cost of the operation is 1000. 因此在一秒内,服务器在对后续请求进行速率限制之前,只接受两个此类请求。As such, within one second, the server honors only two such requests before rate limiting subsequent requests. 有关详细信息,请参阅请求单位一文和请求单位计算器。For more information, see request units article and the request unit calculator.

写入数据Writing data

写入某个项的 RU 成本取决于:The RU cost of writing an item depends on:

  • 项大小。The item size.
  • 索引编制策略涵盖的需要编制索引的属性的数量。The number of properties covered by the indexing policy and needed to be indexed.

插入一个没有索引的 1 KB 项大约需要 5.5 RU。Inserting a 1 KB item without indexing costs around ~5.5 RUs. 替换某个项的成本是插入同一项所需费用的两倍。Replacing an item costs two times the charge required to insert the same item.

优化写入Optimizing writes

优化写入操作的 RU 成本的最佳方式是合理设置要编制索引的项和属性数。The best way to optimize the RU cost of write operations is to rightsize your items and the number of properties that get indexed.

  • 在 Azure Cosmos DB 中存储非常大的项会产生较高的 RU 费用,可将其视为反面模式。Storing very large items in Azure Cosmos DB results in high RU charges and can be considered as an anti-pattern. 特别要注意的是,不要存储不需要查询的二进制内容或大块文本。In particular, don't store binary content or large chunks of text that you don't need to query on. 最佳做法是将此类数据置于 Azure Blob 存储中,并将指向该 blob 的引用(或链接)存储在要写入到 Azure Cosmos DB 的项中。A best practice is to put this kind of data in Azure Blob Storage and store a reference (or link) to the blob in the item you write to Azure Cosmos DB.
  • 优化索引编制策略以仅为你的查询筛选的属性编制索引可能会对写入操作消耗的 RU 产生巨大影响。Optimizing your indexing policy to only index the properties that your queries filter on can make a huge difference in the RUs consumed by your write operations. 在创建新容器时,默认的索引编制策略会为在你的项中找到的每个属性编制索引。When creating a new container, the default indexing policy indexes each and every property found in your items. 虽然这是适用于开发活动的一个良好的默认设置,但我们强烈建议你在转到生产环境时或在工作负荷开始收到大量流量时,重新评估并自定义索引编制策略While this is a good default for development activities, it is highly recommended to re-evaluate and customize your indexing policy when going to production or when your workload begins to receive significant traffic.

当执行数据的批量引入时,我们还建议你使用 Azure Cosmos DB 批量执行工具库,因为它旨在优化此类操作的 RU 消耗。When performing bulk ingestion of data, it is also recommended to use the Azure Cosmos DB bulk executor library as it is designed to optimize the RU consumption of such operations. 另外,你还可以使用基于这个相同的库构建的 Azure 数据工厂Optionally, you can also use Azure Data Factory which is built on that same library.

后续步骤Next steps

接下来,可通过以下文章详细了解 Azure Cosmos DB 中的成本优化:Next you can proceed to learn more about cost optimization in Azure Cosmos DB with the following articles: