如何在标准（手动）和自动缩放预配的吞吐量之间进行选择
适用对象：
NoSQL MongoDB Cassandra Gremlin 表
Azure Cosmos DB 支持两种类型或提供预配的吞吐量：标准（手动）和自动缩放。 这两种吞吐量类型都适用于要求高性能和缩放的任务关键型工作负载，并且在吞吐量、可用性、延迟和一致性方面由相同的 Azure Cosmos DB SLA 支持。
本文介绍如何为工作负载选择标准（手动）和自动缩放预配的吞吐量。
预配的吞吐量类型概述
在深入探讨标准（手动）和自动缩放之间的区别之前，首先要了解 Azure Cosmos DB 中预配的吞吐量的工作原理。
使用预配的吞吐量时，你可以设置吞吐量，以工作负载所需的每秒请求单位 (RU/s) 为单位。 服务预配支持吞吐量需求所需的容量。 针对服务的数据库操作（如读取、写入和查询）会消耗一定数量的请求单元 (RUs)。 详细了解请求单元。
下表显示了标准（手动）和自动缩放之间的高级比较。
| 说明 | 标准（手动） | 自动缩放 |
|---|---|---|
| 最适用于 | 具有稳定或可预测流量的工作负载 | 具有可变或不可预测流量的工作负载。 请参阅自动缩放的用例。 |
| 工作原理 | 除非手动更改 RU/s T，否则将预配一组随时间变化的静态 RU/s T。 每秒最多可以使用 T RU/s 吞吐量。 例如，如果设置标准（手动）400 RU/s，吞吐量将保持在 400 RU/s。 |
你设置了不希望系统超过的最高或最大 RU/s Tmax。 系统会自动调整吞吐量 T，以便 0.1* Tmax <= T <= Tmax。 例如，如果将自动缩放最大 RU/s 设置为 4000 RU/s，系统将在 400 - 4000 RU/s 之间缩放。 |
| 何时使用 | 你需要手动管理吞吐量 (RU/s) 并自行缩放。 具有高、一致的预配 RU/s 利用率。 在一个月的所有小时中，如果设置了预配的 RU/s T，并且使用了 66% 或更多小时的全额，那么估计你将使用标准（手动）预配的 RU/s 来节省时间。这是基于在标准（手动）中设置 T 与在自动缩放中设置相同数量 Tmax 之间的比较。 |
你希望 Azure Cosmos DB 根据使用情况管理吞吐量 (RU/s) 和缩放。 使用的是可变或难以预测的 RU/s 使用情况。 在一个月的所有小时中，如果设置了自动缩放最大 RU/s Tmax，并使用了 66% 或更少小时的全额 Tmax，那么估计你将使用自动缩放来节省时间。这是基于在标准（手动）吞吐量中设置自动缩放 Tmax 和相同数量的 T 之间的比较。 |
| 计费模式 | 对于预配的 RU/s，无论消耗了多少 RU，都按每小时计费。 示例： 对于小时 1 和小时 2，将以标准（手动）速率为这两个小时收取 400 RU/s 的费用。 |
计费以小时为单位，将按系统在一小时内缩放到的最高 RU/s。 示例： Tmax 的 10%）将在第 1 小时收到 3500 RU/s 的计费，在第 2 小时收到 400 RU/s 的计费，按自动缩放预配的吞吐量率。 每 RU/s 的自动缩放速率为 1.5 * 标准（手动）速率。 |
| 如果超过了预配的 RU/s，会发生什么情况 | RU/s 在预配的位置保持静态。 任何在一秒钟内消耗超过预配的 RU 的请求都将受到速率限制，响应建议在重试之前等待一段时间。 如果需要，可以手动增加或降低 RU/s。 | 系统将把 RU/s 扩展到自动缩放最大 RU/s。 任何在一秒钟内消耗超过自动缩放最大 RU 的请求都将受到速率限制，响应建议在重试之前等待一段时间。 |
了解流量模式
新应用程序
如果你正在生成一个新应用程序，但还不知道流量模式，你可能想要从入口点 RU/s（或最小 RU/s）开始，以避免在开始时过度预配。 或者，如果你有一个不需要大规模的小型应用程序，你可能只需要预配最小的入口点 RU/s 来优化成本。 对于预期流量较低的小型应用程序，还可以考虑无服务器容量模式。
无论计划使用标准（手动）还是自动缩放，都应该考虑以下事项：
如果在 400 RU/s 的入口点预配标准（手动）RU/s，则无法消耗超过 400 RU/s 的吞吐量，除非手动更改吞吐量。 你将以每小时标准（手动）预配的吞吐量为 400 RU/s 计费。
如果你将自动缩放吞吐量的最大 RU/秒预配为 4000 RU/秒，资源将在 400 到 4000 RU/秒之间缩放。 由于每 RU/s 的自动缩放吞吐量计费速率是标准（手动）速率的 1.5 倍，对于系统已缩减到最低 400 RU/s 的小时，你的计费将高于手动预配 400 RU/s 的计费。 但是，使用自动缩放，在任何时候，如果你的应用程序流量激增，则可以在不需要用户操作的情况下消耗高达 4000 RU/s。 通常情况下，你应该权衡一个好处，即能够在任何时候以 1.5 倍的自动缩放速率消耗最大 RU/s。
使用 Azure Cosmos DB 容量计算器估计吞吐量需求。
现有应用程序
如果现有应用程序使用标准（手动）预配的吞吐量，则可以使用 Azure Monitor 指标来确定流量模式是否适合自动缩放。
首先，查找数据库或容器的规范化请求单位消耗指标。
接下来，确定规范化利用率随时间变化的方式。 查找每小时的最高标准化利用率。 然后，计算所有小时的平均标准化利用率。 如果发现平均利用率低于 66%，请考虑在数据库或容器上启用自动缩放。 相反，如果平均利用率高于 66%，则建议保留标准（手动）预配的吞吐量。
提示
如果你的帐户配置为使用多区域写入并且具有多个区域，则对于手动和自动缩放，每 100 RU/s 的速率都是相同的。 这意味着启用自动缩放不会产生额外的成本，而不考虑利用率。 因此，当你有多个区域时，始终建议将自动缩放与多区域写入一起使用，以便利用只为应用程序缩放到的 RU/s 付费所节省的金额。 如果你有多区域写入和一个区域，请使用平均利用率来确定自动缩放是否会节省成本。
如何计算平均利用率
在一小时内缩放到的最高 RU/s 的自动缩放计费。 分析一段时间内的规范化 RU 消耗量时，在计算平均值时务必使用每小时最高利用率。
若要计算所有小时内最高利用率的平均值，请执行以下操作：
- 将规范化的 RU 消耗指标上的“聚合”设置为“最大值”。
- 将“时间粒度”选为 1 小时。
- 导航到“图表选项”。
- 选择“条形图”选项。
- 在“共享”下，选择“下载到 Excel”选项。 从生成的电子表格中，计算所有小时的平均利用率。
测量和监视使用情况
随着时间的推移，在选择吞吐量类型之后，应该监视应用程序并根据需要进行调整。
使用自动缩放时，请使用 Azure Monitor 查看预配的自动缩放最大 RU/s（自动缩放最大吞吐量）和系统当前缩放到的 RU/s（预配的吞吐量） 。
以下示例展示了一个使用自动缩放的可变或不可预测的工作负载。 注意，当没有任何流量时，系统将 RU/s 缩放到最大 RU/s 的 10% 的最小值，在本例中分别为 5,000 RU/s 和 50,000 RU/s。
将标准预配吞吐量迁移到自动缩放
想要将大量资源从标准预配吞吐量迁移到自动缩放的用户可以使用 Azure CLI 脚本将 Azure 订阅中的每个吞吐量资源迁移到自动缩放。 有关详细信息，请参阅转换为自动缩放。
后续步骤
- 使用 RU 计算器估计新工作负载的吞吐量。
- 使用 Azure Monitor 监视现有工作负载。
- 了解如何在 Azure Cosmos DB 数据库或容器上预配自动缩放吞吐量。
- 查看自动缩放常见问题解答。
- 尝试为迁移到 Azure Cosmos DB 进行容量计划？ 可以使用有关现有数据库群集的信息进行容量规划。
- 如果只知道现有数据库群集中的 vCore 和服务器数量，请阅读使用 vCore 或 vCPU 估算请求单位
- 若知道当前数据库工作负载的典型请求速率，请阅读使用 Azure Cosmos DB 容量计划工具估算请求单位