다음을 통해 공유

Azure Cosmos DB for MongoDB vCore 群集的计算和存储配置

计算资源以 vCore 的形式提供,代表基础硬件的逻辑 CPU。 预配的存储大小是指群集中分片可用的容量。 此存储用于数据库文件、临时文件、事务日志和数据库服务器日志。 可以独立选择计算和存储设置。 所选的计算和存储值适用于群集中的每个分片。

Azure Cosmos DB for MongoDB vCore 中的计算

单个分片中的 RAM 总量取决于所选的 vCore 数量。

群集层 vCore 数 一个分片,GiB RAM
M10 1(可突发) 2
M20 2(可突发) 4
M25 2(可突发) 8
M30 2 8
M40 4 16
M50 8 32
M60 16 64
M80 32 128
M200 64 256

Azure Cosmos DB for MongoDB vCore 中的存储

预配的总存储量也定义了可供群集中的每个分片使用的 I/O 容量。

存储大小,GiB 最大 IOPS
32 3,500†
64 3,500†
128 3,500†
256 3,500†
512 3,500†
1,024 5,000
2,048 7,500
4,095 7,500
8,192 16,000
16,384 18,000
32,767 20,000

† 具有免费磁盘突发的最大 IOPS。 最高 512 GiB(含)的存储,已启用免费磁盘突发。

最大化计算/存储配置的 IOPS

每个计算配置都存在 IOPS 限制,具体取决于 vCore 数量。 请确保为群集选择计算配置,以充分利用所选存储中的 IOPS。

存储大小 存储 IOPS,最高 最小计算层 最小 vCore 数
最高 0.5 TiB 3,500† M30 2 个 vCore
1 Tebibyte (1 TiB) 5,000 M40 4 个 vCore
2 TiB 7,500 M50 8 个 vCore
4 TiB 7,500 M50 8 个 vCore
8 TiB 16,000 M60 16 个 vCore
16 TiB 18,000 M60 16 个 vCore
32 TiB 20,000 M60 16 个 vCore

† 具有免费磁盘突发的最大 IOPS。 最高 512 GiB(含)的存储,已启用免费磁盘突发。

例如,如果每个分片需要 8 TiB 或更多存储,请确保为节点的计算配置选择 16 个或更多的 vCore。 通过此选择,可最大限度地使用所选存储提供的 IOPS。

计算和存储注意事项

工作集和内存注意事项

在 Azure Cosmos DB for MongoDB vCore 中,工作集是指应用程序经常访问和使用的数据部分。 它包括在执行应用程序典型操作期间定期读取或写入的数据和索引。 工作集的概念对于性能优化非常重要,因为与许多数据库一样,当工作集可以装入 RAM 时,MongoDB 的性能最佳。

若要定义和了解 MongoDB 数据库工作集,请考虑以下组件:

  1. 经常访问的数据:此类数据包括应用程序定期读取或更新的文档
  2. 索引:查询操作中使用的索引也是工作集的一部分,因为它们需要加载到内存中以确保快速访问
  3. 应用程序使用模式:分析应用程序的使用模式有助于确定数据的哪些部分访问得最频繁

将工作集保存在 RAM 中可以最大程度地减少较慢的磁盘 I/O 操作,从而提高 MongoDB 数据库的性能。 如果你发现工作集超出了可用的 RAM,可以考虑优化数据模型、添加更多 RAM 或使用分片将数据分布在多个节点上。

为工作负载选择最佳配置

确定 Azure Cosmos DB for MongoDB vCore 工作负载的正确计算和存储配置涉及到评估与应用程序要求和使用模式相关的几个因素。 确定最佳配置的关键步骤和考虑因素包括:

  1. 了解你的工作负载

    • 数据量:估算数据的总大小,包括索引
    • 读/写比:确定读取操作与写入操作之比
    • 查询模式:分析应用程序执行的查询类型。 例如,简单读取,复杂聚合。
    • 并发性:评估数据库需要处理的并发操作数量
  2. 监视当前性能

    • 资源利用率:在将工作负载移动到 Azure 之前,使用监视工具跟踪 CPU、内存、磁盘 I/O 和网络使用情况;开始在 Azure Cosmos DB for MongoDB vCore 群集上运行 MongoDB 工作负载之后监视指标
    • 性能指标:监视关键性能指标,例如延迟、吞吐量和缓存命中率
    • 瓶颈:确定任何现有性能瓶颈,例如 CPU 使用率过高、内存压力或磁盘 I/O 速度缓慢
  3. 估算资源要求

    • 内存:确保工作集(经常访问的数据和索引)可以装入 RAM。 如果工作集大小超出了可用内存,请考虑添加更多 RAM 或优化数据模型。
    • CPU:选择可以处理查询负载和并发要求的 CPU 配置。 CPU 密集型工作负载可能需要更多核心。 在 Azure Cosmos DB for MongoDB vCore 群集上使用带有“最大值”聚合的“CPU 百分比”指标来查看历史计算使用模式。
    • 存储 IOPS:选择具有足够 IOPS 的存储来处理读写操作。 在群集上使用带有“最大值”聚合的“IOPS”指标来查看历史存储 IOPS 使用情况。
    • 网络:确保有足够的网络带宽用于处理应用程序和数据库之间的数据传输,尤其是对于分布式设置。 确保为 MongoDB 应用程序配置主机以支持加速网络技术(例如 SR-IOV)。
  4. 适当缩放

    • 垂直缩放:纵向扩展和缩减计算/RAM,并纵向扩展存储
      • 计算:如果工作负载需要暂时提高 CPU 使用率或经常性地长时间超过 70% 的 CPU 利用率,请增加群集上的 vCore/RAM。
      • 确保在 Azure Cosmos DB for MongoDB vCore 数据库中设置适当的数据保留期。 设置保留期可以避免不必要地使用存储。 使用“最大值”聚合对“存储百分比”和/或“已用存储”指标设置警报来监视存储使用量。 当工作负载大小超过 70% 的使用率时,请考虑增加存储。
    • 水平缩放:考虑为群集使用多个分片,以将数据分布在多个 Azure Cosmos DB for MongoDB vCore 节点上,从而在工作负载增长时提高性能并更好地管理容量。 这对于大型数据集(超过 2-4 TiB)和高吞吐量应用程序特别有用。
  5. 测试和迭代

    • 基准测试:使用不同的配置对最常用的查询执行度量,以确定对性能的影响。 使用 CPU/RAM 和 IOPS 指标和应用程序级基准测试。
    • 负载测试:执行负载测试以模拟生产工作负载并验证所选配置的性能
    • 持续监视:持续监视 Azure Cosmos DB for MongoDB vCore 部署,并根据不断变化的工作负载和使用模式按需调整资源

通过系统性地评估这些因素并持续监视和调整配置,可以确保 MongoDB 部署根据特定工作负载进行合理优化。

存储注意事项

确定适合工作负载的存储大小需要考虑多种因素,这样才能确保最佳性能和可伸缩性。 下面是 Azure Cosmos DB for MongoDB vCore 中的存储大小注意事项:

  1. 估算数据大小

    • 计算 Azure Cosmos DB for MongoDB vCore 数据的预期大小。 请考虑以下事项:
      • 当前数据大小:如果从现有数据库迁移
      • 增长率:估算一段时间内会增加多少数据
      • 文档大小和结构:了解数据架构和文档大小,因为它们会影响存储效率
  2. 考虑到索引

    • Azure Cosmos DB for MongoDB vCore 使用索引来实现高效查询。 索引会占用额外的磁盘空间。
    • 根据以下因素估算索引大小:
      • 索引数量
      • 索引字段的大小
  3. 性能注意事项

    • 磁盘性能会影响数据库操作,尤其是对于那些无法将其工作集装入 RAM 的工作负载。 请考虑以下事项:
      • I/O 吞吐量:IOPS(即每秒输入/输出操作次数)是指一秒内发送到存储磁盘的请求数。 存储大小越大,支持的 IOPS 也越大。 确保为读/写操作提供足够的吞吐量。 使用带有“最大值”聚合的“IOPS”指标来监视群集上使用的 IOPS。
      • 延迟:延迟是指应用程序接收单个请求,将其发送到存储磁盘,然后再将响应发送到客户端所花费的时间。 延迟是除 IOPS 和吞吐量之外应用程序性能的另一个关键度量指标。 延迟主要由使用的存储类型和存储配置定义。 在 Azure Cosmos DB for MongoDB 等托管服务中,会使用高级 SSD 磁盘等快速存储和优化的设置来减少延迟。
  4. 未来增长和可伸缩性

    • 根据未来的数据增长和可伸缩性需求做好规划。
    • 可以分配超出当前需求的磁盘空间来适应未来的增长,而无需频繁扩展存储。
  5. 示例计算

    • 假设初始数据大小为 500 GiB。
    • 使用索引时,它可能会增长到 700 GiB。
    • 如果你预期数据量将在两年内翻倍,请规划 1.4 TiB (700 GiB * 2)。
    • 添加缓冲区来满足开销、增长和运营需求。
    • 可以暂时从 1 TiB 存储开始,在存储使用量超过 800 GiB 后,将存储增加到 2 TiB。

确定存储大小需要估算当前和未来的数据需求,考虑索引和压缩,并确保足够的性能和可伸缩性。 根据实际使用量和增长趋势定期监视和调整对于保持最佳 MongoDB 性能同样至关重要。

后续步骤