Azure DocumentDB 使用 Premium SSD v2 磁盘,通过从 IOPS 和带宽设置取消耦合存储容量,为 I/O 密集型工作负荷提供更高的性能。
使用 Azure DocumentDB 上的高级 SSD v2 存储时,无论为群集配置的存储容量如何,默认都可以使用可配置的最大 IOPS 和带宽设置。 计算层的 IOPS 和带宽容量决定了存储层中可实现的 IOPS 和带宽,而无需纵向扩展存储容量。
只需选择所需的存储容量,而最高可实现的 IOPS 和带宽由 Azure DocumentDB 自动配置,无需额外成本。 无需额外的用户干预来确保为最佳性能设置群集。 结果是 12 倍的性能提升,无需额外成本。
以前,从 5,000 IOPS 跃升到 20,000 IOPS,需要将磁盘的大小从 1TB 增加到 20TB,即使在缺少更高的存储需求的情况下也是如此。 使用高级 SSD v2,只要群集的计算层具有推送和维护 20,000 IOPS 的容量,就可以在同一 1TB 磁盘上实现 20,000 IOPS。 此外,高级 SSD v2 磁盘最多可支持 80,000 IOPS - 比高级 SSD 增加 4 倍。
在 Azure DocumentDB 上使用高级 SSD v2 磁盘的吞吐量优势(80,000 IOPS)
请考虑一个存储量为 2 TB 的应用程序,并定期增加下面详述的流量:
- 第 1 个月中的 7,000 IOPS
- 第 2 个月中的 10,000 IOPS
- 第 3 个月达到 19,000 IOPS
在引入高级 SSD v2 磁盘之前,IOPS 与存储容量直接相关。
因此,满足应用程序不断增长的 IOPS 要求需要以下磁盘大小增加:
- 2 TB 磁盘(SSD v1 上的容量为 7,500 IOPS),以在 1 月 1 中实现 7,000 IOPS
- 8 TB 磁盘(容量为 16,000 IOPS SSD v1),以在 2 个月内实现 10,000 IOPS
- 32 TB 磁盘(容量为 20,000 IOPS SSD v1),以在 3 个月内实现 19,000 IOPS
旧一代存储磁盘的 20,000 IOPS 限制,需要 32 TB 的存储容量才能达到该限制。
只有通过向集群添加更多分片并对应用程序流量进行横向扩展,才能实现超过 20,000 的 IOPS。 这会增加管理开销,方法是将逻辑分片引入应用程序的体系结构,以跨多分片群集分配数据库流量。
随着应用程序的需求的增长,更大的磁盘和逻辑分片复杂性也会增加,尽管只需要 2 TB 的存储。
但是,对于高级 SSD v2 磁盘,存储容量与 IOPS 和带宽无关,默认情况下,任何大小的磁盘的 IOPS 可用 80,000 IOPS ,无需额外成本。
考虑到上述相同应用程序,其增长现在可以维持在具有高级 SSD v2 磁盘的同一 2 TB 磁盘上:
- 2 TB 磁盘(SSD v2 上的默认容量为 80,000 IOPS),第 1 个月为 7,000 IOPS
- 在第 2 个月,相同的 2 TB 磁盘(10,000 IOPS;SSD v2 的默认容量为 80,000 IOPS)
- 对于 19,000 IOPS(SSD v2 的默认容量为 80,000 IOPS),仍为相同的 2 TB 磁盘(第 3 个月为 80,000 IOPS)
以前需要的 32 TB 磁盘现在可在较小的 2 TB 磁盘上实现 -- 成本降低 16 倍。
相同的 2 TB 磁盘可以实现高达 80,000 IOPS,而以前上限为 7,500 IOPS -- 性能提升近 11 倍。
在 Azure DocumentDB 上使用高级 SSD v2 磁盘的带宽优势(1200 MB/秒)
除了从 SSD v2 磁盘上的 IOPS 分离的存储容量外,带宽(MB/秒)限制也与磁盘大小无关。
以前,为了获得更高的带宽,即使没有更高的存储需求,也需要扩充磁盘的存储容量。
考虑需要 2 TB 存储容量的相同工作负荷,另外需要 900 MB/秒的带宽:
- 在 SSD v2 之前,2 TB 磁盘的容量为 150 MB/秒
- 需要 900 MB/秒的带宽,将 2 TB 磁盘扩展到 32 TB
- 将磁盘从 2 TB 缩放到 32 TB 会导致存储成本增加 16 倍
在 Azure DocumentDB 上使用高级 SSD v2(高性能)磁盘:
- 无论预配的存储容量如何,最大带宽为 1200 MB/秒,都无需增加任何费用
- 因此,同一 2 TB 磁盘的可用带宽为 1,200 MB/秒
- 在相同存储容量下,性能提升 8 倍
请考虑另一个工作负荷,该工作负荷旨在对单个分片Azure DocumentDB 群集实现每秒 100 万次写入。 使用高级 SSD v2(高性能)磁盘:
- 无论磁盘的预配存储容量如何,都可以使用 1200 MB/秒
- 对于 1 kB 文档,每秒 100 万次写入需要 1000 MB/秒
- 使用高级 SSD v2(高性能)磁盘,可以轻松实现 100 万次写入,并留出空间
- 无需增加存储容量,即可占用可用 1,200 MB/s 中的 1,000 MB/s
在 Azure DocumentDB 上使用高级 SSD v2 磁盘的复原优势
由于默认容量为 80,000 IOPS 和 1,200 MB/秒的带宽,高级 SSD v2(高性能)磁盘为应用程序流量的峰值提供更多的头空间,以及处于稳定状态的较高流量。
此外,在高峰时段,由于有额外的可用余量,与旧一代磁盘相比,以下弹性特性得到了改善:
- 在副本集中的主节点和备用节点之间进行更快的复制
- 由于主节点和辅助节点之间的复制速度更快,写入延迟更快
- 由于主节点与辅助节点之间的复制速度更快,因此在副本集中进行主节点选举期间,故障转移也更快
- 由于副本集主节点上的资源争用更低,整体故障转移次数更少
Guidance
Azure DocumentDB 群集的 maximum 性能现在仅依赖于 计算层而不是存储大小。 首先,只需选择群集所需的存储大小,然后选择一个计算层来提供工作负荷所需的(IOPS)和吞吐量(MB/秒)。 下面列出的表格是每个计算层实现的最高可实现且可持续的 IOPS 和带宽限制。
IOPS 和吞吐量上限
可实现的 IOPS 和带宽仅依赖于计算群集层,而不依赖于使用高级 SSD v2 磁盘时的 预配存储容量 。
下面列出了每个计算层可实现的上限 IOPS 和带宽。
| 计算层 | 最大 IOPS | 最大带宽(MB/秒) |
|---|---|---|
| M30 (2 核) | 3,750 | 85 |
| M40 (4 核) | 6,400 | 145 |
| M50 (8 核) | 12,800 | 290 |
| M60 (16 核) | 25,600 | 600 |
| M80 (32 核) | 五万一千二百 | 865 |
| M200 (64 核) | 80,000 | 1,200 |
下面列出的表格是对 Azure DocumentDB 上每个存储层可实现的 IOPS 的比较。 显示的值假定已预配能够提供 80,000 IOPS 的计算集群层级(例如 M200)
| 存储容量 | 高级 SSD v2 之前的最大 IOPS | 高级 SSD v2 的最大 IOPS |
|---|---|---|
| 32 GB | 120 | 80,000 |
| 64 GB | 240 | 80,000 |
| 128 GB | 500 | 80,000 |
| 256 GB | 1,100 | 80,000 |
| 512 GB | 2,300 | 80,000 |
| 1 TB(兆字节) | 5,000 | 80,000 |
| 2兆字节 | 7,500 | 80,000 |
| 4 TB(兆字节) | 7,500 | 80,000 |
| 8 TB(兆字节) | 16,000 | 80,000 |
| 16 TB(兆字节) | 18,000 | 80,000 |
| 32 兆字节 | 20,300 | 80,000 |
同样,下面列出的表格是对 Azure DocumentDB 上每个存储层可实现的带宽(MB/秒)的比较。 显示的值假设已预配能够提供 1,200 MB/秒吞吐量的计算集群层级(例如 M200)。
| 存储容量 | 高级 SSD v2 之前的最大 MB/秒 | 高级 SSD v2 的最高 MB/秒 |
|---|---|---|
| 32 GB | 25 MB/秒 | 1,200 MB/秒 |
| 64 GB | 50 MB/秒 | 1,200 MB/秒 |
| 128 GB | 100 MB/秒 | 1,200 MB/秒 |
| 256 GB | 125 MB/秒 | 1,200 MB/秒 |
| 512 GB | 150 MB/秒 | 1,200 MB/秒 |
| 1 TB(兆字节) | 200 MB/秒 | 1,200 MB/秒 |
| 2兆字节 | 250 MB/秒 | 1,200 MB/秒 |
| 4 TB(兆字节) | 250 MB/秒 | 1,200 MB/秒 |
| 8 TB(兆字节) | 500 MB/秒 | 1,200 MB/秒 |
| 16 TB(兆字节) | 750 MB/秒 | 1,200 MB/秒 |
| 32 兆字节 | 900 MB/秒 | 1,200 MB/秒 |
先决条件
- 一份 Azure 订阅。 如果没有 Azure 订阅,请创建一个试用帐户。
现有的 Azure DocumentDB 群集
- 如果没有群集,请 创建新群集
如需在本地运行 CLI 参考命令,请安装 Azure CLI。 如果在 Windows 或 macOS 上运行,请考虑在 Docker 容器中运行 Azure CLI。 有关详细信息,请参阅如何在 Docker 容器中运行 Azure CLI。
如果使用的是本地安装,请使用 az login 命令登录到 Azure CLI。 若要完成身份验证过程,请遵循终端中显示的步骤。 有关其他登录选项,请参阅使用 Azure CLI 登录。
出现提示时,请在首次使用时安装 Azure CLI 扩展。 有关扩展的详细信息,请参阅 将扩展与 Azure CLI 配合使用。
运行az version命令,以查看已安装的版本和依赖库。 若要升级到最新版本,请运行az upgrade。
- Terraform 1.2.0 或更高版本。
使用高级 SSD v2(高性能)存储创建群集
使用 高级 SSD v2 (高性能)存储配置群集,作为群集创建步骤的一部分。
登录到 Azure 门户 (https://portal.azure.cn)。
在 Azure 门户菜单或主页中,选择“创建资源” 。
在 “新建 ”页上,搜索并选择 Azure DocumentDB。
在“创建 Azure DocumentDB 群集”页和“基本信息”部分中,选择“群集层”部分中的“配置”选项。
在 “配置 ”页上,根据需要选择群集层和存储大小。 选择存储类型作为 高级 SSD v2 以启用高性能存储,然后选择“保存”以应用更改。
填写剩余的详细信息,然后选择“ 查看 + 创建”。
查看提供的设置,然后选择“创建”。 创建群集需要几分钟时间。 等待资源部署完成。
最后,选择转到资源以前往门户中的 Azure DocumentDB 集群。
打开新的终端。
登录到 Azure CLI。
创建新的 Bicep 文件以定义角色定义。 将文件命名 为 main.bicep。
将此模板添加到文件的内容。 将
<cluster-name>、<location>、<username>和<password>占位符替换为适当的值。resource cluster 'Microsoft.DocumentDB/mongoClusters@2025-09-01' = { name: '<cluster-name>' location: '<location>' properties: { administrator: { userName: '<username>' password: '<password>' } serverVersion: '8.0' storage: { sizeGb: 32 type: 'PremiumSSDv2' } compute: { tier: 'M30' } sharding: { shardCount: 1 } highAvailability: { targetMode: 'Disabled' } } }使用
az deployment group create部署 Bicep 模板。 指定 Bicep 模板的名称,并将占位符替换为<resource-group>目标 Azure 资源组的名称。az deployment group create \ --resource-group "<resource-group>" \ --template-file main.bicep等待部署完成。 查看部署的输出。
打开新的终端。
登录到 Azure CLI。
检查目标 Azure 订阅。
az account show在新 Terraform 文件中定义群集。 将文件 命名为 cluster.
tf。将此资源配置添加到文件的内容。 请将
<cluster-name>、<resource-group>和<location>占位符替换为相应的值。variable "admin_username" { type = string description = "Administrator username for the cluster." sensitive = true } variable "admin_password" { type = string description = "Administrator password for the cluster." sensitive = true } terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 4.0" } } } provider "azurerm" { features {} } data "azurerm_resource_group" "existing" { name = "<resource-group>" } resource "azurerm_mongo_cluster" "cluster" { name = "<cluster-name>" resource_group_name = data.azurerm_resource_group.existing.name location = "<location>" administrator_username = var.admin_username administrator_password = var.admin_password shard_count = "1" compute_tier = "M30" high_availability_mode = "Disabled" storage_size_in_gb = "32" storage_type = "PremiumSSDv2" version = "8.0" }小窍门
有关使用
azurerm_mongo_cluster资源的选项的详细信息,请参阅azurermTerraform 注册表中的提供程序文档。初始化 Terraform 部署。
terraform init --upgrade创建执行计划并将其保存到名为 cluster.tfplan 的文件。 当系统提示输入
admin_username和admin_password变量时提供值。ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --out "cluster.tfplan"注释
此命令暂时设置
ARM_SUBSCRIPTION_ID环境变量。 自版本 4.0 起,azurerm提供程序需要此设置。有关详细信息,请参阅azurerm中的订阅 ID。应用执行计划将群集部署到 Azure。
ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "cluster.tfplan"等待部署完成。 查看部署的输出。
打开新的终端。
登录到 Azure CLI。
创建名为 cluster.json的新 JSON 文件。
将此文档添加到文件的内容。 请将
<location>、<username>和<password>占位符替换为相应的值。{ "location": "<location>", "properties": { "administrator": { "userName": "<username>", "password": "<password>" }, "serverVersion": "8.0", "storage": { "sizeGb": 32, "type": "PremiumSSDv2" }, "compute": { "tier": "M30" }, "sharding": { "shardCount": 1 }, "highAvailability": { "targetMode": "Disabled" } } }az rest使用 Azure CLI 命令创建包含 JSON 文件中指定的配置的新群集。 在请求中将 JSON 文件的名称指定为body,并替换以下占位符:Description <subscription-id>目标 Azure 订阅的唯一标识符 <resource-group>目标 Azure 资源组的名称 <cluster-name>新 Azure DocumentDB 群集的唯一名称 az rest \ --method "GET" \ --url "https://management.chinacloudapi.cn/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01" \ --body @cluster.json小窍门
使用
az account show获取目标 Azure 订阅的唯一标识符。等待部署完成。 查看部署的输出。
高级 SSD v2 存储的当前限制(高性能)
高级 SSD v2 存储不支持客户管理的密钥(CMK)。
高级 SSD v2 磁盘上的存储容量设置可在 24 小时内最多调整四次。 对于新创建的群集,最多可以在前 24 小时内进行三次存储容量调整。
仅迁移方案支持从高级 SSD 复制到高级 SSD v2。 不支持正在进行的复制,因为高级 SSD 无法匹配高级 SSD v2 的性能,并可能导致更高的延迟。
目前不支持从高级 SSD 联机迁移到高级 SSD v2。 若要从高级 SSD 升级到高级 SSD V2,您可以使用高级 SSD V2 执行时间点恢复到新服务器。 或者,可以创建从高级 SSD 服务器到高级 SSD v2 服务器的只读副本,并在复制完成后将其提升。
如果执行任何需要磁盘冻结的操作,则可能会发生以下错误。 发生此错误是因为高级 SSD V2型磁盘在磁盘仍在填充时不支持任何操作。
- 错误消息:无法完成操作,因为磁盘仍在冻结。 请稍后重试。
- 可以触发此行为的操作包括:
- 执行计算缩放、存储缩放、快速连续启用高可用性(HA)。
- 这还包括由服务触发的故障转移,以确保高可用性。
- 使用 PITR(时间点还原)创建新的集群,并在磁盘仍在进行水化时立即启用高可用性。
- 最佳做法是,使用高级 SSD v2 磁盘时,请超时这些操作或按顺序完成这些操作,确保磁盘冻结在操作之间完成。