次の方法で共有

Azure DocumentDB 的计算和存储配置

Azure DocumentDB 计算资源以 vCore 的形式提供,表示基础硬件的逻辑 CPU。 预配的存储大小是指群集中分片可用的容量。

存储用于数据库文件、临时文件、事务日志和数据库服务器日志。 可以独立选择计算和存储设置。 所选的计算和存储值适用于群集中的每个分片。

Azure DocumentDB 中的计算

单个分片中的 RAM 总量基于所选的虚拟内核数量。

群集层 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 DocumentDB 中的存储

分配的总存储量还定义了群集中每个分片可用的 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(含 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 Tebibytes (TiB) 20,000 M60 16 个 vCore

†可用磁盘突发的最大 IOPS。 最多 512 GiB(含 512 GiB)的存储启用了免费磁盘突发功能。

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

计算和存储注意事项

配置 Azure DocumentDB 群集时,请务必了解计算和存储选择如何影响特定工作负荷的性能、成本和可伸缩性。

工作集和内存方面的注意事项

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

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

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

通过将工作集保留在 RAM 中,可以最大程度地降低磁盘 I/O作速度,从而提高 MongoDB 数据库的性能。 如果工作集超出可用 RAM,请考虑优化数据模型、向群集添加更多 RAM,或使用分片在多个节点之间分配数据。

为工作负荷选择最佳配置

确定 Azure DocumentDB 工作负载的正确计算和存储配置涉及评估与应用程序要求和使用模式相关的几个因素。 确定最佳配置的关键步骤和注意事项包括:

  1. 了解工作负荷

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

    • 资源利用率:在将工作负荷迁移到 Azure 之前,使用监视工具跟踪 CPU、内存、磁盘 I/O 和网络使用情况。 在 Azure DocumentDB 群集上部署 MongoDB 工作负荷后,继续使用 Azure 监视指标进行监视
    • 性能指标:监视关键性能指标,例如延迟、吞吐量和缓存命中率。
    • 瓶颈:确定任何现有的性能瓶颈,例如 CPU 使用率高、内存压力或磁盘 I/O 速度缓慢。
  3. 估算资源要求

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

    • 垂直缩放:扩展或缩减计算/RAM,并向上扩展存储。
      • 计算:如果您的工作负载需要临时扩展,或 CPU 利用率经常长时间超过 70%,则扩展群集上的 vCore/RAM。
      • 请确保在 Azure DocumentDB 数据库中保留适当的数据。 通过使用保留功能可以减少不必要的存储使用。 通过在“存储百分比”和/或“已使用存储”指标上设置警报,并结合“Max”聚合,来监视存储使用情况。 请考虑增加存储,因为工作负荷容量超过 70% 使用量。
    • 水平缩放:考虑对群集使用多个分片在多个 Azure DocumentDB 节点之间分配数据,以提高性能,并在工作负荷增长时更好地进行容量管理。 此缩放对于大型数据集(超过 2-4 TiB)和高吞吐量应用程序特别有用。
  5. 测试和迭代

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

通过系统地评估这些因素并持续监视和调整配置,可以确保 MongoDB 部署针对特定工作负荷进行了很好的优化。

存储注意事项

为工作负荷确定适当的存储大小涉及几个注意事项,以确保最佳性能和可伸缩性。 下面是 Azure DocumentDB 中存储大小的注意事项:

  1. 估计数据大小:

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

    • Azure DocumentDB 使用 索引 进行高效的查询。 索引占用额外的磁盘空间。
    • 根据以下条件估计索引的大小:
      • 索引数
      • 索引字段的大小
  3. 性能注意事项

    • 磁盘性能会影响数据库操作,尤其是对于无法将其工作集适合放入内存的工作负载。 请考虑以下事项:
      • I/O 吞吐量: IOPS 或每秒输入/输出作数是每秒发送到存储磁盘的请求数。 更大的存储大小附带更多的 IOPS。 确保读取/写入作的吞吐量足够。 使用“IOPS”指标和“最大值”聚合监视群集上的 IOPS 使用情况。
      • 延迟: 延迟是指应用程序接收单个请求、将其发送到存储磁盘并将响应发送到客户端所需的时间。 除了 IOPS 和吞吐量外,延迟是应用程序性能的关键度量值。 使用的存储类型和存储配置在很大程度上定义了延迟。 在 Azure DocumentDB 等托管服务中,快速存储(如高级 SSD 磁盘)与经过优化的设置一起使用,以减少延迟。
  4. 未来的增长和可伸缩性:

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

    • 假设初始数据大小为 500 GiB。
    • 使用索引时,它可能会增长到 700 GiB。
    • 如果预计两年内数据翻倍,请计划 1.4 TiB (700 GiB * 2)。
    • 为开销、增长和运营需求添加缓冲区。
    • 你可能希望从 1-TiB 存储开始,一旦其大小超过 800 GiB,就将其扩展为 2 TiB。

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

什么是弹性计算?

可突发层提供专为小型数据库工作负荷定制的智能化解决方案。 通过在空闲期间提供最低的 CPU 性能,这些群集可以优化资源利用率。 但是,真正的辉煌在于他们能够无缝扩展到完整的 CPU 能力,以应对流量或工作负荷需求的增加。 这种适应能力可在需要时精确提供最佳性能,同时节省大量成本。

通过降低服务的初始价格点,Azure DocumentDB 的可突发群集层旨在以更低的价格促进用户加入和探索 Azure DocumentDB。 这种访问的民主化使各种规模的企业能够利用 Azure DocumentDB 的强大功能,同时无需花费巨资。 无论你是初创公司、小型企业还是企业,此层都为经济高效的可伸缩性开辟了新的可能性。

预配可突发层与预配常规层一样简单;只需在群集层选项中选择“M10”、“M20”或“M25”。 下面是有关如何设置 Azure DocumentDB 群集的分步说明的快速入门指南。