Azure Cosmos DB 中自动缩放预配吞吐量的常见问题解答Frequently asked questions about autoscale provisioned throughput in Azure Cosmos DB

使用自动缩放预配吞吐量,Azure Cosmos DB 将根据使用情况自动管理和缩放数据库或容器的 RU/s。With autoscale provisioned throughput, Azure Cosmos DB will automatically manage and scale the RU/s of your database or container based on usage. 本文解答了有关自动缩放的常见问题。This article answers commonly asked questions about autoscale.

常见问题Frequently asked questions

在 Azure Cosmos DB 中,“Autopilot”和“自动缩放”有什么区别?What is the difference between "autopilot" and "autoscale" in Azure Cosmos DB?

“自动缩放”或“自动缩放预配吞吐量”是该功能的更新名称,以前称为“Autopilot”。"Autoscale" or "autoscale provisioned throughput" is the updated name for the feature, previously known as "autopilot." 在自动缩放的当前版本中,我们添加了新功能,包括设置自定义最大 RU/s 的功能和编程支持。With the current release of autoscale, we've added new features, including the ability to set custom max RU/s and programmatic support.

在之前的 Autopilot 层模型中创建的数据库或容器会发生什么情况?What happens to databases or containers created in the previous autopilot tier model?

新的自动缩放自定义最大 RU/s 模型自动支持使用之前的层模型创建的资源。Resources that were created with the previous tier model are automatically supported with the new autoscale custom maximum RU/s model. 该层的上限成为新的最大 RU/s,这产生相同的缩放范围。The upper bound of the tier becomes the new maximum RU/s, which results in the same scale range.

例如,如果你之前选择了缩放比例为 400 到 4,000 RU/s 的层,则数据库或容器现在将显示具有最大为 4,000 RU/s 的吞吐量,缩放比例为 400 到 4,000 RU/s。For example, if you previously selected the tier that scaled between 400 to 4000 RU/s, the database or container will now show as having a maximum RU/s of 4000 RU/s, which scales between 400 to 4000 RU/s. 在此处,你可以将最大 RU/s 更改为自定义值以适应你的工作负载。From here, you can change the maximum RU/s to a custom value to suit your workload.

自动缩放根据流量高峰进行增减的速度有多快?How quickly will autoscale scale up and down based on spikes in traffic?

使用自动缩放,系统根据传入的流量在 0.1 * TmaxTmax 范围内上下缩放吞吐量 (RU/s) TWith autoscale, the system scales the throughput (RU/s) T up or down within the 0.1 * Tmax and Tmax range, based on incoming traffic. 因为缩放是自动且即时的,所以可在任何时间点无延迟地使用吞吐量(最多使用预配的 Tmax)。Because the scaling is automatic and instantaneous, at any point in time, you can consume up to the provisioned Tmax with no delay.

如何确定系统当前缩放到的吞吐量 (RU/s)?How do I determine what RU/s the system is currently scaled to?

使用 Azure Monitor 指标监视已预配的自动缩放最大 RU/s 和系统缩放到的当前吞吐量 (RU/s)。Use Azure Monitor metrics to monitor both the provisioned autoscale max RU/s and the current throughput (RU/s) the system is scaled to.

自动缩放采用何种定价方式?What is the pricing for autoscale?

每小时将向你收取系统在该小时内扩展到的最高吞吐量 T 的费用。Each hour, you will be billed for the highest throughput T the system scaled to within the hour. 如果你的资源在这个小时内没有请求,或者缩放的范围未超出 0.1 * Tmax,则将向你收取最低 0.1 * Tmax 的费用。If your resource had no requests during the hour or did not scale beyond 0.1 * Tmax, you will be billed for the minimum of 0.1 * Tmax. 请参考 Azure Cosmos DB 定价页面了解详细信息。Refer to the Azure Cosmos DB pricing page for details.

自动缩放如何显示在我的帐单上?How does autoscale show up on my bill?

在单主数据库帐户中,每 100 RU/s 的自动缩放速率是标准(手动)预配吞吐量速率的 1.5 倍。In single-master accounts, the autoscale rate per 100 RU/s is 1.5x the rate of standard (manual) provisioned throughput. 在账单上,你可看到现有的标准预配吞吐量计量。On your bill, you will see the existing standard provisioned throughput meter. 此计量的数量乘以 1.5。The quantity of this meter will be multiplied by 1.5. 例如,如果系统在一小时内缩放到的最高 RU/s 为 6,000 RU/s,则该小时的计费是 60 * 1.5 = 90 个计量单位。For example, if the highest RU/s the system scaled to within an hour was 6000 RU/s, you'd be billed 60 * 1.5 = 90 units of the meter for that hour.

在多主数据库帐户中,每 100 RU/s 的自动缩放速率与标准(手动)预配的多主数据库吞吐量速率相同。In multi-master accounts, the autoscale rate per 100 RU/s is the same as the rate for standard (manual) provisioned multi-master throughput. 在帐单上,你可看到现有的多主数据库计量。On your bill, you will see the existing multi-master meter. 由于速率相同,因此如果你使用自动缩放,你可看到与标准吞吐量相同的数量。Since the rates are the same, if you use autoscale, you'll see the same quantity as with standard throughput.

自动缩放是否适用于免费层?Does autoscale work with free tier?

是的。Yes. 在免费层,可以对容器使用自动缩放吞吐量。In free tier, you can use autoscale throughput on a container. 尚不支持具有自定义最大 RU/s 的自动缩放共享吞吐量数据库。Support for autoscale shared throughput databases with custom max RU/s is not yet available. 查看免费层计费与自动缩放一起工作的方式。See how free tier billing works with autoscale.

是否所有 API 都支持自动缩放?Is autoscale supported for all APIs?

是的,所有 API 都支持自动缩放:Core (SQL)、Gremlin、Table、Cassandra 以及 MongoDB API。Yes, autoscale is supported for all APIs: Core (SQL), Gremlin, Table, Cassandra, and API for MongoDB.

多主数据库帐户是否支持自动缩放?Is autoscale supported for multi-master accounts?

是的。Yes. 添加到 Azure Cosmos DB 帐户的每个区域都支持最大 RU/s。The max RU/s are available in each region that is added to the Azure Cosmos DB account.

如何对新数据库或容器启用自动缩放?How do I enable autoscale on new databases or containers?

请参阅此文章如何启用自动缩放See this article on how to enable autoscale.

是否可对现有数据库或容器启用自动缩放?Can I enable autoscale on an existing database or a container?

是的。Yes. 还可以根据需要在自动缩放和标准(手动)预配的吞吐量之间切换。You can also switch between autoscale and standard (manual) provisioned throughput as needed. 目前,对于所有 API,只能使用 Azure 门户来执行这些操作。Currently, for all APIs, you can only use the Azure portal to do these operations.

自动缩放和标准(手动)预配的吞吐量之间的迁移是如何工作的?How does the migration between autoscale and standard (manual) provisioned throughput work?

从概念上讲,更改吞吐量类型是一个两阶段的过程。Conceptually, changing the throughput type is a two-stage process. 首先,发送请求,更改吞吐量设置以使用自动缩放或手动预配的吞吐量。First, you send a request to change the throughput settings to use either autoscale or manual provisioned throughput. 在这两种情况下,系统将根据当前吞吐量设置和存储自动确定和设置初始 RU/s 值。In both cases, the system will automatically determine and set an initial RU/s value, based on the current throughput settings and storage. 在此步骤中,不接受用户提供的 RU/s 值。During this step, no user-provided RU/s value will be accepted. 然后,在更新完成后,可以更改 RU/s 以适应你的工作负载。Then, after the update is complete, you can change the RU/s to suit your workload.

从标准(手动)预配的吞吐量迁移到自动缩放Migration from standard (manual) provisioned throughput to autoscale

对于容器,请使用以下公式估计初始自动缩放最大 RU/s:MAX(4000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB * 100),四舍五入到最接近的 1000 RU/s。For a container, use the following formula to estimate the initial autoscale max RU/s: MAX(4000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB * 100), rounded to the nearest 1000 RU/s. 实际的初始自动缩放最大 RU/s 可能因帐户配置而异。The actual initial autoscale max RU/s may vary depending on your account configuration.

示例 #1:假设你有一个具有 10,000 RU/s 手动预配吞吐量和 25 GB 存储空间的容器。Example #1: Suppose you have a container with 10,000 RU/s manual provisioned throughput, and 25 GB of storage. 启用自动缩放时,初始自动缩放最大 RU/s 为:10,000 RU/s,缩放范围为 1,000 - 10,000 RU/s。When you enable autoscale, the initial autoscale max RU/s will be: 10,000 RU/s, which will scale between 1000 - 10,000 RU/s.

示例 #2:假设你有一个具有 50,000 RU/s 手动预配吞吐量和 2,500 GB 存储的容器。Example #2: Suppose you have a container with 50,000 RU/s manual provisioned throughput, and 2500 GB of storage. 启用自动缩放时,初始自动缩放最大 RU/s 为:250,000 RU/s,缩放范围为 25,000 - 250,000 RU/s。When you enable autoscale, the initial autoscale max RU/s will be: 250,000 RU/s, which will scale between 25,000 - 250,000 RU/s.

从自动缩放迁移到标准(手动)预配吞吐量Migration from autoscale to standard (manual) provisioned throughput

初始手动预配吞吐量等于当前自动缩放最大 RU/s。The initial manual provisioned throughput will be equal to the current autoscale max RU/s.

示例:假设你有一个自动缩放数据库或容器,最大 RU/s 为 20,000 RU/s(缩放范围为 2,000 - 20,000 RU/s)。Example: Suppose you have an autoscale database or container with max RU/s of 20,000 RU/s (scales between 2000 - 20,000 RU/s). 当你更新为使用手动预配吞吐量时,初始吞吐量将为 20,000 RU/s。When you update to use manual provisioned throughput, the initial throughput will be 20,000 RU/s.

是否支持使用自动缩放通过 Azure CLI 或 PowerShell 来管理数据库或容器?Is there Azure CLI or PowerShell support to manage databases or containers with autoscale?

目前,只能使用自动缩放从 Azure 门户、.NET V3 SDK、Java V4 SDK 和 Azure 资源管理器创建和管理资源。Currently, you can only create and manage resources with autoscale from the Azure portal, .NET V3 SDK, Java V4 SDK, and Azure Resource Manager. 目前尚不提供对 Azure CLI、PowerShell 和其他 SDK 的支持。Support in Azure CLI, PowerShell, and other SDKs is not yet available.

共享吞吐量数据库是否支持自动缩放?Is autoscale supported for shared throughput databases?

是的,共享吞吐量数据库支持自动缩放。Yes, autoscale is supported for shared throughput databases. 若要启用此功能,请在创建数据库时选择自动缩放和“预配吞吐量”选项。To enable this feature, select autoscale and the Provision throughput option when creating the database.

启用自动缩放后,每个共享吞吐量数据库允许的容器数是多少?What is the number of allowed containers per shared throughput database when autoscale is enabled?

Azure Cosmos DB 在一个共享吞吐量数据库中最多可实施 25 个容器,这适用于具有自动缩放或标准(手动)吞吐量的数据库。Azure Cosmos DB enforces a maximum of 25 containers in a shared throughput database, which applies to databases with autoscale or standard (manual) throughput.

自动缩放对数据库一致性级别有何影响?What is the impact of autoscale on database consistency level?

自动缩放不影响数据库的一致性级别。There is no impact of the autoscale on consistency level of the database. 有关可用一致性级别的详细信息,请参阅一致性级别一文。See the consistency levels article for more information regarding available consistency levels.

与每个最大 RU/s 选项关联的存储限制是多少?What is the storage limit associated with each max RU/s option?

每个最大 RU/s 的存储限制(以 GB 为单位)为:数据库或容器的最大 RU/s / 100。The storage limit in GB for each max RU/s is: Max RU/s of database or container / 100. 例如,如果最大 RU/秒为 20,000 RU/秒,则该资源可以支持 200 GB 的存储空间。For example, if the max RU/s is 20,000 RU/s, the resource can support 200 GB of storage. 请参阅自动缩放限制一文,了解可用的最大 RU/s 和存储选项。See the autoscale limits article for the available max RU/s and storage options.

如果超过了与最大吞吐量关联的存储空间上限,会发生什么情况?What happens if I exceed the storage limit associated with my max throughput?

如果超出了与数据库或容器的最大吞吐量关联的存储限制,Azure Cosmos DB 会自动将最大吞吐量提高到可以支持该级别存储的下一个最大 RU/s。If the storage limit associated with the max throughput of the database or container is exceeded, Azure Cosmos DB will automatically increase the max throughput to the next highest RU/s that can support that level of storage.

例如,如果开始时以 50,000 RU/s 为最大值(在 5000-50,000 RU/s 之间缩放),则最多可以存储 500 GB 的数据。For example, if you start with a max RU/s of 50,000 RU/s (scales between 5000 - 50,000 RU/s), you can store up to 500 GB of data. 如果超过 500 GB,例如存储现在为 600 GB,则新的最大 RU/s 为 60,000 RU/s(在 6000-60,000 RU/s 之间缩放)。If you exceed 500 GB - e.g. storage is now 600 GB, the new maximum RU/s will be 60,000 RU/s (scales between 6000 - 60,000 RU/s).

能否更改数据库或容器的最大 RU/s?Can I change the max RU/s on the database or container?

是的。Yes. 请参阅本文,了解关于如何更改最大 RU/s。See this article on how to change the max RU/s. 根据请求的值更改最大 RU/s 时,此异步操作可能需要一些时间才能完成(根据所选的 RU/s,可能需要长达 4-6 小时)When you change the max RU/s, depending on the requested value, this can be an asynchronous operation that may take some time to complete (may be up to 4-6 hours, depending on the RU/s selected)

增加最大 RU/sIncreasing the max RU/s

当你发送请求以增加最大 RU/s Tmax 时,根据所选的最大 RU/s,服务将预配更多资源来支持更高的最大 RU/s。When you send a request to increase the max RU/s Tmax, depending on the max RU/s selected, the service provisions more resources to support the higher max RU/s. 当这种情况发生时,你现有的工作负载和操作不会受到影响。While this is happening, your existing workload and operations will not be affected. 系统将继续在以前的 0.1*TmaxTmax 之间缩放数据库或容器,直到 0.1*Tmax_newTmax_new 的新缩放范围就绪。The system will continue to scale your database or container between the previous 0.1*Tmax to Tmax until the new scale range of 0.1*Tmax_new to Tmax_new is ready.

降低最大 RU/sLowering the max RU/s

降低最大 RU/s 时,可设置的最小值为:MAX(4000, highest max RU/s ever provisioned / 10, current storage in GB * 100),四舍五入到最接近的 1,000 RU/s。When you lower the max RU/s, the minimum value you can set it to is: MAX(4000, highest max RU/s ever provisioned / 10, current storage in GB * 100), rounded to the nearest 1000 RU/s.

示例 #1:假设你有一个自动缩放容器,最大 RU/s 为 20,000 RU/s(缩放范围为 2,000 - 20,000 RU/s)且具有 50 GB 存储。Example #1: Suppose you have an autoscale container with max RU/s of 20,000 RU/s (scales between 2000 - 20,000 RU/s) and 50 GB of storage. 对于最大 RU/s,可设置的最低且最小的值为:MAX(4,000, 20,000 / 10, 50 * 100) = 5,000 RU/s(缩放范围为 500 - 5,000 RU/s)。The lowest, minimum value you can set max RU/s to is: MAX(4000, 20,000 / 10, 50 * 100) = 5000 RU/s (scales between 500 - 5000 RU/s).

示例 #2:假设你有一个自动缩放容器,最大 RU/s 为 100,000 RU/s 且具有 100 GB 存储。Example #2: Suppose you have an autoscale container with max RU/s of 100,000 RU/s and 100 GB of storage. 现在,可以将最大 RU/s 缩放到 150,000 RU/s(缩放范围为 15,000 - 150,000 RU/s)。Now, you scale max RU/s up to 150,000 RU/s (scales between 15,000 - 150,000 RU/s). 对于最大 RU/s,现可设置的最低且最小的值为:MAX(4,000, 150,000 / 10, 100 * 100) = 15,000 RU/s(缩放范围为 1,500 - 15,000 RU/s)。The lowest, minimum value you can now set max RU/s to is: MAX(4000, 150,000 / 10, 100 * 100) = 15,000 RU/s (scales between 1500 - 15,000 RU/s).

对于共享的吞吐量数据库,在降低最大 RU/s 时,可设置的最小值为:MAX(4000, highest max RU/s ever provisioned / 10, current storage in GB * 100, 4000 + (MAX(Container count - 25, 0) * 1000)),四舍五入到最接近的 1,000 RU/s。For a shared throughput database, when you lower the max RU/s, the minimum value you can set it to is: MAX(4000, highest max RU/s ever provisioned / 10, current storage in GB * 100, 4000 + (MAX(Container count - 25, 0) * 1000)), rounded to the nearest 1000 RU/s.

上述公式和示例与可设置的最小自动缩放最大 RU/s 相关,并且不同于系统自动缩放范围(0.1 * TmaxTmax)。The above formulas and examples relate to the minimum autoscale max RU/s you can set, and is distinct from the 0.1 * Tmax to Tmax range the system automatically scales between. 不管最大 RU/s 是多少,系统总是在 0.1 * TmaxTmax 之间缩放。No matter what the max RU/s is, the system will always scale between 0.1 * Tmax to Tmax.

TTL 如何与自动缩放一起工作?How does TTL work with autoscale?

使用自动缩放,TTL 操作不影响 RU/s 的缩放。With autoscale, TTL operations do not affect the scaling of RU/s. 由于 TTL 而使用的任何 RU 都不属于自动缩放容器的计费 RU/s。Any RUs consumed due to TTL are not part of the billed RU/s of the autoscale container.

例如,假设你有一个 400 - 4,000 RU/s 的自动缩放容器:For example, suppose you have an autoscale container with 400 - 4000 RU/s:

  • 1 小时:T=0:容器未执行操作(没有 TTL 或工作负载请求)。Hour 1: T=0: The container has no usage (no TTL or workload requests). 计费 RU/s 为 400 RU/s。The billable RU/s is 400 RU/s.
  • 1 小时:T=1:已启用 TTL。Hour 1: T=1: TTL is enabled.
  • 1 小时:T=2:容器开始接收请求,在 1 秒内使用 1,000 RU。Hour 1: T=2: The container starts getting requests, which consume 1000 RU in 1 second. 此外,还有需使用 200 RU 的 TTL 要实现。There are also 200 RUs worths of TTL that need to happen. 计费 RU/s 仍然为 1,000 RU/s。The billable RU/s is still 1000 RU/s. 无论何时发生 TTL,它们都不会影响自动缩放逻辑。Regardless of when the TTLs occur, they will not affect the autoscale scaling logic.

最大 RU/秒和物理分区之间的映射是什么?What is the mapping between the max RU/s and physical partitions?

首次选择最大 RU/s 时,Azure Cosmos DB 将进行以下预配:最大 RU/秒/10000 RU/秒 = 物理分区的数量。When you first select the max RU/s, Azure Cosmos DB will provision: Max RU/s / 10,000 RU/s = # of physical partitions. 每个物理分区最多可支持 10,000 RU/s 和 50 GB 的存储。Each physical partition can support up to 10,000 RU/s and 50 GB of storage. 随着存储大小的增长,Azure Cosmos DB 将自动拆分分区,以添加更多物理分区来应对存储的增长;如果存储超过相关限制,Azure Cosmos DB 将增加最大 RU/s。As storage size grows, Azure Cosmos DB will automatically split the partitions to add more physical partitions to handle the storage increase, or increase the max RU/s if storage exceeds the associated limit.

数据库或容器的最大 RU/s 在所有物理分区之间平均分配。The max RU/s of the database or container is divided evenly across all physical partitions. 因此,任何单个物理分区可扩展到的总吞吐量为:数据库或容器的最大 RU/s / 物理分区数。So, the total throughput any single physical partition can scale to is: Max RU/s of database or container / # physical partitions.

如果传入请求超过数据库或容器的最大 RU/秒,会发生什么情况?What happens if incoming requests exceed the max RU/s of the database or container?

如果 RU/s 总使用量超过数据库或容器的最大 RU/s,则超过最大 RU/s 的请求将受到限制并返回 429 状态代码。If the overall consumed RU/s exceeds the max RU/s of the database or container, requests that exceed the max RU/s will be throttled and return a 429 status code. 标准化利用率超过 100% 的请求也将受到限制。Requests that result in over 100% normalized utilization will also be throttled. 标准化利用率定义为所有物理分区中 RU/s 利用率的最大值。Normalized utilization is defined as the max of the RU/s utilization across all physical partitions. 例如,假设最大吞吐量为 20,000 RU/s,并且有两个物理分区 P_1 和 P_2,每个分区都可以扩展到 10,000 RU/s。For example, suppose your max throughput is 20,000 RU/s and you have two physical partitions, P_1 and P_2, each capable of scaling to 10,000 RU/s. 在给定的秒数内,如果 P_1 已使用 6000 RU,而 P_2 已使用 8000 RU,则标准化利用率为 MAX(6000 RU / 10,000 RU, 8000 RU / 10,000 RU) = 0.8。In a given second, if P_1 has used 6000 RUs, and P_2 8000 RUs, the normalized utilization is MAX(6000 RU / 10,000 RU, 8000 RU / 10,000 RU) = 0.8.

备注

Azure Cosmos DB 客户端 SDK 和数据导入工具(Azure 数据工厂、批量执行程序库)会在出现 429 错误时自动重试,因此,偶尔出现 429 错误是正常的。The Azure Cosmos DB client SDKs and data import tools (Azure Data Factory, bulk executor library) automatically retry on 429s, so occasional 429s are fine. 持续大量的 429 错误可能表明你需要提高最大 RU/s 或查看热分区的分区策略。A sustained high number of 429s may indicate you need to increase the max RU/s or review your partitioning strategy for a hot partition.

启用自动缩放后,是否仍有可能看到 429 错误(限制/速率限制)?Is it still possible to see 429s (throttling/rate limiting) when autoscale is enabled?

是的。Yes. 在两个情况下可能出现 429s。It is possible to see 429s in two scenarios. 第一种,当 RU/s 总使用量超过数据库或容器的最大 RU/s 时,服务将相应地限制请求。First, when the overall consumed RU/s exceeds the max RU/s of the database or container, the service will throttle requests accordingly.

第二种情况是,如果有一个热分区(即逻辑分区键值,该键值的请求数与其他分区键值的请求数相比过高),则基础物理分区可能超出其 RU/秒预算。Second, if there is a hot partition, i.e. a logical partition key value that has a disproportionately higher amount of requests compared to other partition key values, it is possible for the underlying physical partition to exceed its RU/s budget. 为避免出现热分区,最佳做法是选择一个合适的分区键,以实现存储和吞吐量的均匀分配。As a best practice, to avoid hot partitions, choose a good partition key that results in an even distribution of both storage and throughput.

例如,如果选择 20,000 RU/s 的最大吞吐量选项,并具有 200 GB 的存储和四个物理分区,则每个物理分区最多可以自动扩展至 5000 RU/s。For example, if you select the 20,000 RU/s max throughput option and have 200 GB of storage, with four physical partitions, each physical partition can be autoscaled up to 5000 RU/s. 如果特定逻辑分区键上有一个热分区,则当它所在的基础物理分区超过 5000 RU/s(即超过 100% 的标准化利用率)时,将显示 429 错误。If there was a hot partition on a particular logical partition key, you will see 429s when the underlying physical partition it resides in exceeds 5000 RU/s, i.e. exceeds 100% normalized utilization.

后续步骤Next steps