Azure Cosmos DB 中的预配吞吐量简介Introduction to provisioned throughput in Azure Cosmos DB

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

Azure Cosmos DB 允许对数据库和容器设置预配吞吐量。Azure Cosmos DB allows you to set provisioned throughput on your databases and containers. 有两种类型的预配吞吐量:标准(手动)或自动缩放。There are two types of provisioned throughput, standard (manual) or autoscale. 本文概述了预配吞吐量的工作原理。This article gives an overview of how provisioned throughput works.

Azure Cosmos 数据库是一组容器的管理单元。An Azure Cosmos database is a unit of management for a set of containers. 数据库包含一组不限架构的容器。A database consists of a set of schema-agnostic containers. Azure Cosmos 容器是吞吐量和存储的缩放单元。An Azure Cosmos container is the unit of scalability for both throughput and storage. 容器跨 Azure 区域中的一组计算机水平分区,并分布在与 Azure Cosmos 帐户关联的所有 Azure 中国区域中。A container is horizontally partitioned across a set of machines within an Azure region and is distributed across all Azure China regions associated with your Azure Cosmos account.

使用 Azure Cosmos DB 时,可以在两个粒度级别预配吞吐量:With Azure Cosmos DB, you can provision throughput at two granularities:

  • Azure Cosmos 容器Azure Cosmos containers
  • Azure Cosmos 数据库Azure Cosmos databases

对容器设置吞吐量Set throughput on a container

在 Azure Cosmos 容器上预配的吞吐量专门保留给该容器使用。The throughput provisioned on an Azure Cosmos container is exclusively reserved for that container. 容器始终可获得预配的吞吐量。The container receives the provisioned throughput all the time. 对容器预配的吞吐量有 SLA 提供的经济保障。The provisioned throughput on a container is financially backed by SLAs. 若要了解如何对容器配置标准(手动)吞吐量,请参阅对 Azure Cosmos 容器预配吞吐量To learn how to configure standard (manual) throughput on a container, see Provision throughput on an Azure Cosmos container. 若要了解如何对容器配置自动缩放吞吐量,请参阅预配自动缩放吞吐量To learn how to configure autoscale throughput on a container, see Provision autoscale throughput.

对容器设置预配吞吐量是最常用的选项。Setting provisioned throughput on a container is the most frequently used option. 可以通过使用请求单位 (RU) 预配任意数量的吞吐量来弹性缩放容器的吞吐量。You can elastically scale throughput for a container by provisioning any amount of throughput by using Request Units (RUs).

为容器预配的吞吐量在其物理分区之间均匀分布。假设有一个适当的分区键,它在物理分区之间均匀分配逻辑分区,那么吞吐量也均匀分布在容器的所有逻辑分区上。The throughput provisioned for a container is evenly distributed among its physical partitions, and assuming a good partition key that distributes the logical partitions evenly among the physical partitions, the throughput is also distributed evenly across all the logical partitions of the container. 无法选择性地指定逻辑分区的吞吐量。You cannot selectively specify the throughput for logical partitions. 由于某个容器的一个或多个逻辑分区由物理分区托管,因此,物理分区专属于该容器,并支持对该容器预配的吞吐量。Because one or more logical partitions of a container are hosted by a physical partition, the physical partitions belong exclusively to the container and support the throughput provisioned on the container.

如果在逻辑分区上运行的工作负荷消耗的吞吐量超过分配给底层物理分区的吞吐量,则操作可能会受到速率限制。If the workload running on a logical partition consumes more than the throughput that was allocated to the underlying physical partition, it's possible that your operations will be rate-limited. 当一个逻辑分区的请求比其他分区键值多得多时,就会出现所谓的“热分区”。What is known as a hot partition occurs when one logical partition has disproportionately more requests than other partition key values.

出现速率限制时,可以增大整个容器的预配吞吐量,或重试操作。When rate-limiting occurs, you can either increase the provisioned throughput for the entire container or retry the operations. 还应确保选择均匀分配存储和请求卷的分区键。You also should ensure that you choose a partition key that evenly distributes storage and request volume. 有关分区的详细信息,请参阅 Azure Cosmos DB 中的分区和横向缩放For more information about partitioning, see Partitioning and horizontal scaling in Azure Cosmos DB.

如果你希望容器的性能可预测,建议你以容器粒度配置吞吐量。We recommend that you configure throughput at the container granularity when you want predictable performance for the container.

下图显示了物理分区如何托管容器的一个或多个逻辑分区:The following image shows how a physical partition hosts one or more logical partitions of a container:

承载着容器的一个或多个逻辑分区的物理分区

对数据库设置吞吐量Set throughput on a database

对 Azure Cosmos 数据库预配吞吐量时,在该数据库中的所有容器(称作共享的数据库容器)之间共享吞吐量。When you provision throughput on an Azure Cosmos database, the throughput is shared across all the containers (called shared database containers) in the database. 一种例外是在数据库中的特定容器上指定了预配的吞吐量。An exception is if you specified a provisioned throughput on specific containers in the database. 在容器之间共享数据库级预配吞吐量相当于在计算机群集上托管数据库。Sharing the database-level provisioned throughput among its containers is analogous to hosting a database on a cluster of machines. 由于数据库中的所有容器共享一台计算机上的可用资源,因此,任何特定容器的性能自然不可预测。Because all containers within a database share the resources available on a machine, you naturally do not get predictable performance on any specific container. 若要了解如何对数据库配置预配吞吐量,请参阅对 Azure Cosmos 数据库配置预配吞吐量To learn how to configure provisioned throughput on a database, see Configure provisioned throughput on an Azure Cosmos database. 若要了解如何对数据库配置自动缩放吞吐量,请参阅预配自动缩放吞吐量To learn how to configure autoscale throughput on a database, see Provision autoscale throughput.

由于数据库中的所有容器共享预配的吞吐量,因此,Azure Cosmos DB 不会针对该数据库中的特定容器提供任何可预测的吞吐量保证。Because all containers within the database share the provisioned throughput, Azure Cosmos DB doesn't provide any predictable throughput guarantees for a particular container in that database. 特定容器可获得的吞吐量部分取决于:The portion of the throughput that a specific container can receive is dependent on:

  • 容器数量。The number of containers.
  • 为各个容器选择的分区键。The choice of partition keys for various containers.
  • 工作负荷在容器的各个逻辑分区之间的分布形式。The distribution of the workload across various logical partitions of the containers.

若要在多个容器之间共享吞吐量,而不希望将吞吐量专门提供给任何特定的容器使用,则我们建议对数据库配置吞吐量。We recommend that you configure throughput on a database when you want to share the throughput across multiple containers, but don't want to dedicate the throughput to any particular container.

以下示例演示了最适合在数据库级别的哪个位置预配吞吐量:The following examples demonstrate where it's preferred to provision throughput at the database level:

  • 对于多租户应用程序来说,在一组容器之间共享数据库的预配吞吐量非常有用。Sharing a database's provisioned throughput across a set of containers is useful for a multitenant application. 每个用户可由不同的 Azure Cosmos 容器表示。Each user can be represented by a distinct Azure Cosmos container.

  • 将 VM 群集或本地物理服务器中托管的 NoSQL 数据库(例如 MongoDB 或 Cassandra)迁移到 Azure Cosmos DB 时,在一组容器之间共享数据库的预配吞吐量非常有利。Sharing a database's provisioned throughput across a set of containers is useful when you migrate a NoSQL database, such as MongoDB or Cassandra, hosted on a cluster of VMs or from on-premises physical servers to Azure Cosmos DB. 可将针对 Azure Cosmos 数据库配置的预配吞吐量视为在逻辑上等同于(但更具成本效益和弹性)MongoDB 或 Cassandra 群集的计算容量。Think of the provisioned throughput configured on your Azure Cosmos database as a logical equivalent, but more cost-effective and elastic, to that of the compute capacity of your MongoDB or Cassandra cluster.

必须使用分区键创建在具有预配吞吐量的数据库内创建的所有容器。All containers created inside a database with provisioned throughput must be created with a partition key. 在任意给定的时间点,分配给数据库中容器的吞吐量将分布在该容器的所有逻辑分区中。At any given point in time, the throughput allocated to a container within a database is distributed across all the logical partitions of that container. 如果有容器共享对数据库配置的预配吞吐量,则无法选择性地将吞吐量应用到特定的容器或逻辑分区。When you have containers that share provisioned throughput configured on a database, you can't selectively apply the throughput to a specific container or a logical partition.

如果逻辑分区上的工作负荷消耗的吞吐量超过了分配给特定逻辑分区的吞吐量,操作将受到速率限制。If the workload on a logical partition consumes more than the throughput that's allocated to a specific logical partition, your operations are rate-limited. 出现速率限制时,可以增大整个数据库的吞吐量,或重试操作。When rate-limiting occurs, you can either increase the throughput for the entire database or retry the operations. 有关分区的详细信息,请参阅逻辑分区For more information on partitioning, see Logical partitions.

共享吞吐量数据库中的容器共享分配给该数据库的吞吐量(RU/秒)。Containers in a shared throughput database share the throughput (RU/s) allocated to that database. 使用标准(手动)预配吞吐量,数据库中最多可以有 25 个最小吞吐量为 400 RU/秒的容器。With standard (manual) provisioned throughput, you can have up to 25 containers with a minimum of 400 RU/s on the database. 如果使用自动缩放预配吞吐量,那么一个数据库中最多可以有 25 个容器,其吞吐量可自动缩放到的最大值是 4000 RU/秒(在 400 - 4000 RU/秒之间缩放)。With autoscale provisioned throughput, you can have up to 25 containers in a database with autoscale max 4000 RU/s (scales between 400 - 4000 RU/s).

备注

在 2020 年 2 月,我们引入了一项更改(允许在共享吞吐量数据库中最多拥有 25 个容器),因此可以更好地实现跨容器的吞吐量共享。In February 2020, we introduced a change that allows you to have a maximum of 25 containers in a shared throughput database, which better enables throughput sharing across the containers. 有了头 25 个容器之后,仅当容器预配了专用吞吐量(与数据库的共享吞吐量分离)时,才能向数据库添加更多容器。After the first 25 containers, you can add more containers to the database only if they are provisioned with dedicated throughput, which is separate from the shared throughput of the database.
如果 Azure Cosmos DB 帐户已包含一个具有 >=25 个容器的共享吞吐量数据库,则该帐户和同一 Azure 订阅中的所有其他帐户均不受此更改限制。If your Azure Cosmos DB account already contains a shared throughput database with >=25 containers, the account and all other accounts in the same Azure subscription are exempt from this change. 如果有反馈或疑问,请联系产品支持Please contact product support if you have feedback or questions.

如果工作负荷涉及到删除数据库中的所有集合并重新创建集合,则我们建议删除空数据库,再重新创建新的数据库,然后创建集合。If your workloads involve deleting and recreating all the collections in a database, it is recommended that you drop the empty database and recreate a new database prior to collection creation. 下图显示了物理分区如何托管属于数据库中不同容器的一个或多个逻辑分区:The following image shows how a physical partition can host one or more logical partitions that belong to different containers within a database:

承载着一个逻辑分区或属于不同容器的多个逻辑分区的物理分区

对数据库和容器设置吞吐量Set throughput on a database and a container

可以合并两个模型。You can combine the two models. 同时对数据库和容器预配吞吐量。Provisioning throughput on both the database and the container is allowed. 以下示例演示如何对 Azure Cosmos 数据库和容器预配标准(手动)预配吞吐量:The following example shows how to provision standard (manual) provisioned throughput on an Azure Cosmos database and a container:

  • 可以创建一个具有标准(手动)预配吞吐量(“K”RU)的名为 Z 的 Azure Cosmos 数据库。You can create an Azure Cosmos database named Z with standard (manual) provisioned throughput of "K" RUs.

  • 接下来,在该数据库中创建名为 ABCDE 的五个容器。Next, create five containers named A, B, C, D, and E within the database. 创建容器 B 时,请确保启用“为此容器预配专用吞吐量”选项,并在此容器上显式配置“P”个 RU 的预配吞吐量。When creating container B, make sure to enable Provision dedicated throughput for this container option and explicitly configure "P" RUs of provisioned throughput on this container. 只有在创建数据库和容器时,才能配置共享吞吐量和专用吞吐量。You can configure shared and dedicated throughput only when creating the database and container.

    在容器级别设置吞吐量

  • “K”RU 吞吐量在 ACDE 这四个容器之间共享。提供给 A、C、D 或 E 的确切吞吐量各不相同。 The "K" RUs throughput is shared across the four containers A, C, D, and E. The exact amount of throughput available to A, C, D, or E varies. 每个容器的吞吐量没有 SLA 的保障。There are no SLAs for each individual container's throughput.

  • 保证名为 B 的容器始终可以获得“P”RU 吞吐量。 The container named B is guaranteed to get the "P" RUs throughput all the time. 该容器有 SLA 的保障。It's backed by SLAs.

备注

具有预配吞吐量的容器无法转换为共享的数据库容器。A container with provisioned throughput cannot be converted to shared database container. 反之,共享的数据库容器无法转换为具有专用吞吐量的容器。Conversely a shared database container cannot be converted to have a dedicated throughput.

更新数据库或容器的吞吐量Update throughput on a database or a container

创建 Azure Cosmos 容器或数据库后,可以更新预配的吞吐量。After you create an Azure Cosmos container or a database, you can update the provisioned throughput. 可对数据库或容器配置的最大预配吞吐量没有限制。There is no limit on the maximum provisioned throughput that you can configure on the database or the container.

当前的预配的吞吐量Current provisioned throughput

可以通过 Azure 门户或 SDK 来检索容器或数据库的预配吞吐量:You can retrieve the provisioned throughput of a container or a database in the Azure portal or by using the SDKs:

这些方法的响应还包含容器或数据库的最小预配吞吐量The response of those methods also contains the minimum provisioned throughput for the container or database:

实际的最小 RU/s 可能因帐户配置而异。The actual minimum RU/s may vary depending on your account configuration. 但一般情况下,它为最大值:But generally it's the maximum of:

  • 400 RU/s400 RU/s
  • 当前存储以 GB * 10 RU/s 为单位(除非容器或数据库包含超过 1 TB 的数据,请参阅我们的“高存储/低吞吐量”计划Current storage in GB * 10 RU/s (unless your container or database contains more than 1 TB of data, see our high storage / low throughput program)
  • 数据库或容器上预配的最高 RU/s / 100Highest RU/s provisioned on the database or container / 100

更改预配吞吐量Changing the provisioned throughput

可以通过 Azure 门户或 SDK 来缩放容器或数据库的预配吞吐量:You can scale the provisioned throughput of a container or a database through the Azure portal or by using the SDKs:

如果你 减小预配吞吐量,则最多可以将其减小到 最小值If you are reducing the provisioned throughput, you will be able to do it up to the minimum.

如果你 增大预配吞吐量,则在大多数情况下,操作是即时的。If you are increasing the provisioned throughput, most of the time, the operation is instantaneous. 但是在某些情况下,由于系统任务的原因,该操作可能需要较长的时间来预配所需的资源。There are however, cases where the operation can take longer time due to the system tasks to provision the required resources. 在这种情况下,如果尝试在此操作正在进行时修改预配的吞吐量,则会生成一个 HTTP 423 响应,并会出现一条错误消息,指出另一个缩放操作正在进行。In this case, an attempt to modify the provisioned throughput while this operation is in progress will yield an HTTP 423 response with an error message explaining that another scaling operation is in progress.

备注

如果你正在规划非常大的引入工作负荷,并且该工作负荷需要大大增加预配的吞吐量,则请记住:缩放操作没有 SLA,当增加量很大时可能需要很长时间,如上一段所述。If you are planning for a very large ingestion workload that will require a big increase in provisioned throughput, keep in mind that the scaling operation has no SLA and, as mentioned in the previous paragraph, it can take a long time when the increase is large. 你可能需要提前规划并在工作负荷启动之前开始缩放,同时使用以下方法来检查进度。You might want to plan ahead and start the scaling before the workload starts and use the below methods to check progress.

你可以通过编程方式检查缩放进度,方法是:读取当前预配的吞吐量并使用以下项:You can programmatically check the scaling progress by reading the current provisioned throughput and using:

可以使用 Azure Monitor 指标来查看资源上预配吞吐量 (RU/s) 和存储的历史记录。You can use Azure Monitor metrics to view the history of provisioned throughput (RU/s) and storage on a resource.

高存储/低吞吐量计划High storage / low throughput program

如上面的当前的预配的吞吐量部分所述,可以在容器或数据库上预配的最小吞吐量取决于许多因素。As described in the Current provisioned throughput section above, the minimum throughput you can provision on a container or database depends on a number of factors. 其中一个因素是当前存储的数据量,因为 Azure Cosmos DB 强制实施每 GB 存储 10 RU/秒的最小吞吐量。One of them is the amount of data currently stored, as Azure Cosmos DB enforces a minimum throughput of 10 RU/s per GB of storage.

如果需要存储大量数据,但吞吐量要求相对较低,则这可能是个问题。This can be a concern in situations where you need to store large amounts of data, but have low throughput requirements in comparison. 为了更好地适应这些方案,Azure Cosmos DB 引入了一个“高存储/低吞吐量”计划,该计划降低了合格帐户上的每 GB RU/s 约束。To better accommodate these scenarios, Azure Cosmos DB has introduced a "high storage / low throughput" program that decreases the RU/s per GB constraint on eligible accounts.

目前,你若要获得资格,你的帐户中至少需要有 1 个包含 1 TB 以上数据的容器或共享吞吐量数据库。You currently need to have at least 1 container or shared-throughput database containing more than 1 TB of data in your account to be eligible. 若要加入此计划并评估你是否完全符合资格,只需填写此调查即可。To join this program and assess your full eligibility, all you have to do is to fill this survey. 然后,Azure Cosmos DB 团队会跟进处理你的加入事宜。The Azure Cosmos DB team will then follow up and proceed with your onboarding.

模型比较Comparison of models

下表显示了对数据库与容器预配标准(手动)吞吐量时的差异比较。This table shows a comparison between provisioning standard (manual) throughput on a database vs. on a container.

参数Parameter 对数据库预配标准(手动)吞吐量Standard (manual) throughput on a database 对容器预配标准(手动)吞吐量Standard (manual) throughput on a container 对数据库预配自动缩放吞吐量Autoscale throughput on a database 对容器预配自动缩放吞吐量Autoscale throughput on a container
入口点(最小 RU/秒)Entry point (minimum RU/s) 400 RU/秒。400 RU/s. 最多可以有 25 个容器,每个容器没有最小的 RU/秒吞吐量。Can have up to 25 containers with no RU/s minimum per container. 400400 在 400 - 4000 RU/秒之间自动缩放。Autoscale between 400 - 4000 RU/s. 最多可以有 25 个容器,每个容器没有最小的 RU/秒吞吐量。Can have up to 25 containers with no RU/s minimum per container. 在 400 - 4000 RU/秒之间自动缩放。Autoscale between 400 - 4000 RU/s.
每个容器的最小 RU/秒吞吐量Minimum RU/s per container -- 400400 -- 在 400 - 4000 RU/秒之间自动缩放Autoscale between 400 - 4000 RU/s
最大 RU 数Maximum RUs 对于数据库无限。Unlimited, on the database. 对于容器无限。Unlimited, on the container. 对于数据库无限。Unlimited, on the database. 对于容器无限。Unlimited, on the container.
分配或提供给特定容器的 RU 数RUs assigned or available to a specific container 无保证。No guarantees. 为给定容器分配的 RU 数取决于多种属性。RUs assigned to a given container depend on the properties. 属性可以是为共享吞吐量的容器选择的分区键、工作负荷的分布,以及容器的数量。Properties can be the choice of partition keys of containers that share the throughput, the distribution of the workload, and the number of containers. 对容器配置的所有 RU 专门保留给该容器使用。All the RUs configured on the container are exclusively reserved for the container. 无保证。No guarantees. 为给定容器分配的 RU 数取决于多种属性。RUs assigned to a given container depend on the properties. 属性可以是为共享吞吐量的容器选择的分区键、工作负荷的分布,以及容器的数量。Properties can be the choice of partition keys of containers that share the throughput, the distribution of the workload, and the number of containers. 对容器配置的所有 RU 专门保留给该容器使用。All the RUs configured on the container are exclusively reserved for the container.
容器的最大存储Maximum storage for a container 不受限制。Unlimited. 无限制Unlimited 无限制Unlimited 无限制Unlimited
容器的每个逻辑分区的最大吞吐量Maximum throughput per logical partition of a container 10K RU/s10K RU/s 10K RU/s10K RU/s 10K RU/s10K RU/s 10K RU/s10K RU/s
容器的每个逻辑分区的最大存储(数据 + 索引)Maximum storage (data + index) per logical partition of a container 20 GB20 GB 20 GB20 GB 20 GB20 GB 20 GB20 GB

后续步骤Next steps