Azure Cosmos DB 中的请求单位Request Units in Azure Cosmos DB

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

Azure Cosmos DB 支持多种 API,例如 SQL、MongoDB、Cassandra、Gremlin 和表。Azure Cosmos DB supports many APIs, such as SQL, MongoDB, Cassandra, Gremlin, and Table. 每个 API 具有自身的数据库操作集。Each API has its own set of database operations. 这些操作包括简单的点读取和写入,以及复杂的查询等等。These operations range from simple point reads and writes to complex queries. 每个数据库操作根据其复杂性消耗系统资源。Each database operation consumes system resources based on the complexity of the operation.

所有数据库操作的成本将由 Azure Cosmos DB 规范化,并以“请求单位”(缩写为 RU)表示。 The cost of all database operations is normalized by Azure Cosmos DB and is expressed by Request Units (or RUs, for short). 你可以将 RU 视为性能货币,它抽象化了执行 Azure Cosmos DB 支持的数据库操作所需的系统资源,例如 CPU、IOPS 和内存。You can think of RUs as a performance currency abstracting the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.

对于一个 1 KB 的项,执行点读取(即,按 ID 和分区键值提取单个项)的成本是 1 个请求单位(或 1 RU)。The cost to do a point read (i.e. fetching a single item by its ID and partition key value) for a 1 KB item is 1 Request Unit (or 1 RU). 以类似方式为其他所有数据库操作分配 RU 成本。All other database operations are similarly assigned a cost using RUs. 不管使用哪个 API 来与 Azure Cosmos 容器和数据库操作交互,都始终以 RU 来计量成本。No matter which API you use to interact with your Azure Cosmos container, costs are always measured by RUs. 无论数据库操作是写入、点读取还是查询,都始终以 RU 来计量成本。Whether the database operation is a write, point read, or query, costs are always measured in RUs.

下图展示了 RU 的概要情况。The following image shows the high-level idea of RUs:


为了方便管理和规划容量,Azure Cosmos DB 会确保针对给定数据集执行的给定数据库操作的 RU 数是确定性的。To manage and plan capacity, Azure Cosmos DB ensures that the number of RUs for a given database operation over a given dataset is deterministic. 可以检查响应标头来跟踪任一数据库操作消耗的 RU 数。You can examine the response header to track the number of RUs that are consumed by any database operation. 了解影响 RU 费用的因素以及应用程序吞吐量要求后,可以经济高效地运行应用程序。When you understand the factors that affect RU charges and your application's throughput requirements, you can run your application cost effectively.

你使用的 Azure Cosmos 帐户的类型决定了消耗的 RU 的计费方式。The type of Azure Cosmos account you're using determines the way consumed RUs get charged. 可以在 3 种模式下创建帐户:There are 3 modes in which you can create an account:

  1. 预配的吞吐量模式:在此模式下,将按秒来预配应用程序的 RU 数,增量为每秒 100 RU。Provisioned throughput mode: In this mode, you provision the number of RUs for your application on a per-second basis in increments of 100 RUs per second. 若要缩放应用程序的预配吞吐量,可以随时增加或减少 RU 数,增量或减量为 100 RU。To scale the provisioned throughput for your application, you can increase or decrease the number of RUs at any time in increments or decrements of 100 RUs. 可以编程方式或使用 Azure 门户进行更改。You can make your changes either programmatically or by using the Azure portal. 系统会针对你预配的每秒 RU 数按小时向你收费。You are billed on an hourly basis for the amount of RUs per second you have provisioned. 若要了解详细信息,请参阅预配的吞吐量一文。To learn more, see the Provisioned throughput article.

    可在两个不同的粒度级别预配吞吐量:You can provision throughput at two distinct granularities:

  2. 无服务器模式:在此模式下,在 Azure Cosmos 帐户中创建资源时无需预配任何吞吐量。Serverless mode: In this mode, you don't have to provision any throughput when creating resources in your Azure Cosmos account. 在计费周期结束时,会针对你的数据库操作已消耗的请求单位量计费。At the end of your billing period, you get billed for the amount of Request Units that has been consumed by your database operations. 若要了解详细信息,请参阅无服务器吞吐量一文。To learn more, see the Serverless throughput article.

  3. 自动缩放模式:在此模式下,你可以根据使用情况自动且即时地缩放数据库或容器的吞吐量(RU/秒),而不会影响工作负荷的可用性、延迟、吞吐量或性能。Autoscale mode: In this more, you can automatically and instantly scale the throughput (RU/s) of your database or container based on it's usage, without impacting the availability, latency, throughput, or performance of the workload. 此模式非常适合具有可变或不可预测流量模式且需要高性能和大规模 SLA 的关键工作负荷。This mode is well suited for mission-critical workloads that have variable or unpredictable traffic patterns, and require SLAs on high performance and scale. 若要了解详细信息,请参阅自动缩放吞吐量一文。To learn more, see the autoscale throughput article.

请求单位注意事项Request Unit considerations

在估计你的工作负荷消耗的 RU 数量时,请考虑以下因素:While you estimate the number of RUs consumed by your workload, consider the following factors:

  • 项大小:随着项的增大,读取或写入该项所要消耗的 RU 数也会增加。Item size: As the size of an item increases, the number of RUs consumed to read or write the item also increases.

  • 项索引:默认情况下会自动为每个项创建索引。Item indexing: By default, each item is automatically indexed. 如果选择不为容器中的某些项创建索引,则消耗的 RU 数将会减少。Fewer RUs are consumed if you choose not to index some of your items in a container.

  • 项属性计数:假设所有属性采用默认索引,写入某个项所要消耗的 RU 数会随着项属性计数的增加而增加。Item property count: Assuming the default indexing is on all properties, the number of RUs consumed to write an item increases as the item property count increases.

  • 带索引的属性:每个容器的索引策略都可确定默认情况下要进行索引的属性类别。Indexed properties: An index policy on each container determines which properties are indexed by default. 若要减少写入操作的 RU 消耗,请限制带索引的属性数目。To reduce the RU consumption for write operations, limit the number of indexed properties.

  • 数据一致性:在执行读取操作时,非常一致性和有限过期一致性级别消耗的 RU 数大约比其他宽松一致性级别要多两倍。Data consistency: The strong and bounded staleness consistency levels consume approximately two times more RUs while performing read operations when compared to that of other relaxed consistency levels.

  • 读取的类型:点读取消耗的 RU 明显少于查询。Type of reads: Point reads cost significantly fewer RUs than queries.

  • 查询模式:查询的复杂性会影响操作使用的 RU 数。Query patterns: The complexity of a query affects how many RUs are consumed for an operation. 影响查询操作成本的因素:Factors that affect the cost of query operations include:

    • 查询结果数The number of query results
    • 谓词数The number of predicates
    • 谓词性质The nature of the predicates
    • 用户定义的函数数目The number of user-defined functions
    • 源数据的大小The size of the source data
    • 结果集的大小The size of the result set
    • 投影数Projections

    对相同数据的相同查询在重复执行时始终消耗相同数量的 RU。The same query on the same data will always costs the same number of RUs on repeated executions.

  • 脚本的使用:与查询一样,存储过程和触发器也是根据所执行的操作的复杂性来消耗 RU。Script usage: As with queries, stored procedures and triggers consume RUs based on the complexity of the operations that are performed. 开发应用程序时,请检查请求费用标头,以更好地了解每个操作消耗的 RU 容量。As you develop your application, inspect the request charge header to better understand how much RU capacity each operation consumes.

请求单位和多个区域Request units and multiple regions

如果针对 Cosmos 容器(或数据库)预配了 'R' 个 RU,则 Cosmos DB 可确保 'R' 个 RU 在与 Cosmos 帐户关联的每个区域中都可用。 If you provision 'R' RUs on a Cosmos container (or database), Cosmos DB ensures that 'R' RUs are available in each region associated with your Cosmos account. 无法有选择地将 RU 分配给特定区域。You can't selectively assign RUs to a specific region. 针对 Cosmos 容器(或数据库)预配的 RU 是在与 Cosmos 帐户关联的所有区域中预配的。The RUs provisioned on a Cosmos container (or database) are provisioned in all the regions associated with your Cosmos account.

假设为 Cosmos 容器配置了 R 个 RU,并且有 N 个区域与 Cosmos 帐户关联,那么该容器在多个区域可用的 RU 总数 = R x N。Assuming that a Cosmos container is configured with 'R' RUs and there are 'N' regions associated with the Cosmos account, the total RUs available multiple-regionally on the container = R x N.

所选的一致性模型也会影响吞吐量。Your choice of consistency model also affects the throughput. 与更强的一致性级别(例如,“有限过期”或“强”一致性)相比,更宽松的一致性级别(例如“会话”、“一致前缀”和“最终”一致性)可以获得约 2 倍的读取吞吐量。You can get approximately 2x read throughput for the more relaxed consistency levels (e.g., session, consistent prefix and eventual consistency) compared to stronger consistency levels (e.g., bounded staleness or strong consistency).

后续步骤Next steps