规划 Azure Database for PostgreSQL 部署，以优化运营性能

云计算极大地重塑了数据库托管环境。 它使团队能够访问以前无法实现的可伸缩性、复原能力、全球影响力和功能。 团队现在可以围绕他们在需要时所需的精确规模进行优化，并根据需求变化进行调整，而不是从一开始就承担为了支持最大可能工作负荷而产生的相当大的成本和开销。

Introduction

灵活选择适当的资源平衡对于 PostgreSQL 数据库部署尤其有用。 PostgreSQL 数据库工作负荷可能从小型、快速增长、季节性增长、从读取密集型转变为写入密集型，或者从事务工作负荷实时演变为混合操作和分析系统。 Azure Database for PostgreSQL通过在计算、存储、可用性、复制、安全性、备份和操作管理方面提供广泛的选择来确保解决方案达到目标。

在这种强大能力的背后，伴随着责任，尤其是在规划部署时。 若要实现最佳性能，部署决策必须符合总体工作负荷的要求。

成功的Azure Database for PostgreSQL部署不仅仅是选择“我们需要的最核心和内存”的问题。相反，最大的操作性能来自了解应用程序的行为、客户端的行为、计算、存储和数据库增长特征，以及所有这些内容如何相交和交互。

最佳体系结构是有意对齐这些部分的体系结构。

云性能规划是共同的责任

迁移到受信任的云平台的主要好处之一是共同责任模型。 Microsoft提供全球基础结构、托管服务、硬件创新、可靠性、安全性和运营工程。 你的团队具有特定的应用程序上下文专业知识：业务关键性、工作负荷行为、数据模型设计、网络流量配置文件、增长预期、恢复目标和最终用户体验要求。

当这两个力量统一时，会出现最强烈的结果。

Azure提供高度可缩放的 Postgres 基础结构，但团队必须提供以下方面的见解：

• 正常和高峰期预期有多少并发用户？
• 最重要的操作是读取密集型、写入密集型操作还是混合操作？
• 月末、季度末、假日、发布或报告时段的需求是否激增？
• 数据集增长的速度有多快？
• 哪些操作对延迟敏感？
• 哪些查询或作业可以容忍更长的运行时？
• 工作负荷主要是 OLTP、OLAP 还是混合工作负荷？
• 客户端位于数据库区域附近、全球分布还是集中在一个地理位置？

在部署之前捕获这些详细信息，而不是在生产环境出现问题之后才捕获。 云部署可以简化缩放，但性能最高且最经济高效的设计仍从健全要求收集和正确规划开始。 在大多数情况下，这些问题可以提取到跨并发连接的关系、最大 IOPS 和所需吞吐量。

性能具有多个层

数据库性能很少由单个设置确定。 成功的部署体验取决于多个层协同工作：

• 应用程序层性能。
  此层包括应用程序代码、查询模式、索引覆盖率、触发器使用情况、数据分区、连接处理、缓存、重试逻辑、池化、ORM 行为、事务设计和后台作业行为。
• 客户端和网络层性能。
  此层包括客户端所在的位置、客户端连接方式、请求是否跨区域和可用性区域、网络延迟、TLS 开销、连接流失以及应用程序是否有效使用连接池。
• 数据库平台性能。
  此层包括 Postgres 部署配置、计算大小、内存、CPU、存储类型、存储大小、存储 IOPS、存储吞吐量、高可用性、副本和维护操作。

本文主要介绍第三层：规划 Azure Postgres 数据库部署，以确保计算和存储选项能够支持所需的性能要求。

Azure Database for PostgreSQL提供灵活性，但规划至关重要

Azure Database for PostgreSQL灵活服务器提供了广泛的部署选项，包括：

这种灵活性非常强大，因为不同的工作负荷需要不同的功能。 写入密集型事务系统不需要与报告密集型系统相同的配置文件。 全局 SaaS 应用程序不需要与内部区域应用程序相同的设计。 年增长 5% 的数据库与每月增长 200% 的数据库不需要相同的存储计划。

规划目标是确定工作负荷性能概要需求，然后跨计算和存储选项做出适当选择，以成功交付端到端解决方案。

从工作负载配置文件开始

在选择计算或存储之前，请定义工作负荷。 有用的规划维度包括：

目标是不完美预测未来。 目标是避免盲目设计。

了解三个核心存储性能概念

Azure存储性能规划通常归结于三个相关但不同的概念：IOPS、吞吐量和延迟。 这些因素是应用程序性能规划的关键。

IOPS

IOPS 表示每秒的输入/输出操作。 它测量数据库每秒可以发送到存储的读取或写入操作数。

IOPS 对于 OLTP 工作负荷尤其重要。 这些系统通常执行许多小型随机读取和写入，例如插入、更新、索引查找、点读操作和短事务。 包含数千个并发用户的事务工作负荷可能需要高 IOPS，即使每个操作都很小。

常见的 IOPS 敏感方案包括：

• 大批量订单处理
• 用户信息更新
• 清单系统
• 事件引入
• 付款或计费系统
• 高度并发 SaaS 应用程序

吞吐量

吞吐量（有时称为带宽）测量一段时间内可读取或写入存储的数据量。 它以 MB/秒表示。

当操作移动大量数据时，吞吐量很重要。 分析查询、备份、还原、批处理作业、索引生成、表扫描和 ETL 工作流可能需要高吞吐量，即使它们不需要最高的 IOPS 也是如此。

常见的吞吐量敏感方案包括：

• 在大型表上执行查询
• 批量导入或导出
• 数据仓库方式扫描
• 备份和还原操作
• 大型索引创建或重新生成操作
• 批处理

延迟

延迟 是单个 I/O 请求完成所需的时间。 低延迟对于面向用户的数据库操作至关重要，尤其是许多小型操作在事务中链接在一起的情况。

如果延迟较高，系统可能具有较高的理论 IOPS，但仍会感到缓慢。 对于 Postgres 工作负荷，存储延迟可能会直接影响查询响应时间、事务提交行为、检查点行为和应用程序整体响应能力。

必须一起考虑 IOPS、吞吐量和延迟

IOPS 和吞吐量是相互关联的。 发出多个小型 8 KiB 操作的工作负荷可能会驱动高 IOPS，而无需高吞吐量。 发出大型多 MB 操作的工作负荷可能会驱动高吞吐量，且 IOPS 较低。

考虑它的简单方法：

IOPS x I/O 大小 = 吞吐量

对于 Postgres，实际意义在于工作负荷存储规划应基于观察到的或估计的工作负荷行为，而不是仅数据库大小。 例如：

• 高并发 OLTP 系统可能需要更多的 IOPS 和较低的延迟。
• 报告密集型系统可能需要更多吞吐量。
• 混合系统可能需要这两个系统，尤其是在峰值周期期间。
• 高并发 OLTP 系统可能需要更多的 IOPS 和较低的延迟。
• 报告密集型系统可能需要更多吞吐量。
• 混合系统可能需要这两个系统，尤其是在峰值周期期间。

部署选择直接影响存储性能

常见的错误是为目标性能编号设置存储，而无需完全考虑所选计算 SKU 是否可以驱动相同的性能级别。

Azure存储性能有多个注意事项。 这些详细信息包括：

• 计算功能集（最大计算 IOPS 和吞吐量限制）。
• 存储代系（SSD v1、SSD v2）。
• 存储磁盘大小（4,096 GB 以下的 SSD v1 磁盘包括主机缓存，允许超出标准基线的 IOPS 突发）。
• 存储 IOPS 容量。
• 存储吞吐量

从实用角度看：你实际有效的性能极限是链条中最小相关限制。

如果存储配置可以提供 80,000 IOPS，但计算 SKU 只能驱动 20,000 IOPS，则部署不会提供 80,000 IOPS。 相反，如果 VM 代系支持高 IOPS，但所选存储层上限较低，则存储层将变为限制。

计算和存储规划应同时进行。

高级 SSD v1：具有重要缓存行为的强基线性能

高级 SSD v1 是生产Azure Postgres 工作负载的常见选择，需要可预测的预配性能。 Azure Postgres SSD v1 存储支持高达 32 TB 空间、20,000 IOPS 和 900 MB/s 吞吐量。

高级 SSD v1 适用于受益于主机缓存的工作负载。 Azure Postgres 支持 SSD v1 磁盘大小的主机缓存不超过 4,096 GB。 预配最多 4,095 GB 的任何磁盘都可以受益于主机缓存。 在 预配 4,096 GB 或更大容量的存储后，不支持主机缓存。 边界很重要。 对于低于 4 TB 的高级 SSD v1 部署，缓存可以提高读取性能并减少读取延迟。 此缓存为低于缓存阈值的读取密集型或混合工作负载创造了出色的成本与性能效率。

为什么 4 TB 限制很重要

当高级 SSD v1 部署超出缓存支持的范围时，性能配置文件可能会更改：

• 读取不再受益于主机缓存。
• 更多读取操作直接来自基础磁盘。
• 根据磁盘 IOPS 和吞吐量限制读取计数。
• 延迟敏感的读取工作负荷可能会出现不同的表现。
• 以前有效的配置可能需要预配更多的 IOPS、更多吞吐量、计算缩放、查询优化或其他存储选项。

超过 4 TB 并不糟糕，但你必须为此做好 计划。

如果预期数据库增长超过 4 TB，请考虑体系结构设计期间的未来状态。 在 2 TB 的情况下，缓存性能良好的设计可能需要在 5 TB 时使用不同的性能计划，而无需缓存。

突增有助于应对峰值，但不能取代持久的容量。

在 Azure 中，Postgres Premium SSD v1 的存储分配小于 4TB 时，支持主机缓存的突发功能，这在以下场景中可以提供帮助：

• 初创活动
• 短批处理作业
• 流量高峰
• 月末处理
• 临时工作负荷激增

虽然 bursting 机制非常有用，但请谨慎使用。 突发可以吸收临时峰值，但它不应该是持续工作负荷需求的基础。 如果工作负荷经常运行在基线之上，最好预配更高的性能层、调整存储性能设置、缩放计算或重新设计工作负荷模式。

一个好的规划问题是： 这是暂时的峰值，还是这是新的正常？

临时峰值可能是爆发式增长的好候选项。 通过故意的容量规划处理持续需求。

高级 SSD v2 解耦容量、IOPS 和吞吐量

高级 SSD v2 通过分离磁盘大小、IOPS 和吞吐量来更改规划模型。 Azure Database for PostgreSQL 灵活服务器 Premium SSD v2 支持：

• 容量从 32 GB 到 64 TB。
• 最多 80,000 IOPS。
• 最大 吞吐量为 1,200 MB/秒 。
• 以 1 GB 为增量的细粒化容量调整。
• 灵活的 IOPS 和吞吐量配置。
• 延迟低于高级 SSD v1。
• 没有主机缓存。

此更改是一个主要转变。 使用高级 SSD v1 时，性能与磁盘大小更紧密耦合。 使用高级 SSD v2，可以更直接地围绕工作负荷需求配置性能。

例如，事务密集型数据库可能需要高 IOPS，而无需大量的存储。 Azure Postgres 提供基线 IOPS 和吞吐量，无需额外的费用，额外的 IOPS 和吞吐量可以收取额外的费用。 高级 SSD v2 产品/服务：

• 最多 399 GB 的磁盘接收 3,000 IOPS 和 125 MB/秒的基线。
• 磁盘 400 GB 或更大的享有12,000 IOPS和500 MB/秒的基线。
• 当大小至少为 160 GB 可用空间时，磁盘最多可以达到 80,000 IOPS 。
• 吞吐量可以扩展到 1,200 MB/秒。

当你需要更精确的成本和性能控制时，高级 SSD v2 通常很有吸引力。 您可以有针对性地配置性能，而不是通过扩展存储容量来提升性能。

规划业务周期，而不仅仅是稳定状态

许多系统没有单一的性能配置文件。 他们有好几个：

为平均使用率配置的数据库在关键时刻可能难以应对。 相反，数据库永久调整为每月一次的峰值可能会不必要地昂贵。

Azure的灵活性使团队能够做出更微妙的选择。 例如：

• 使用高级 SSD v2 调整 IOPS 和吞吐量，因为工作负荷需求会发生变化。
• 在适当情况下，使用只读副本卸载读取密集型工作负荷。
• 在已知的高峰时段缩放计算能力。
• 在扩展基础架构之前，优化查询、索引和连接池。
• 使用可观测性确定瓶颈是 CPU、内存、IOPS、吞吐量、锁争用、连接压力还是查询设计。

最佳部署并不总是最大的部署。 它是与工作负荷匹配的设计，可以安全地发展。

可观测性是体系结构的一部分

性能规划不应在部署时停止。 Postgres 工作负荷随时间而变化。 数据增长、查询模式转变、新功能启动、客户流量更改和运营作业累积。

Azure Database for PostgreSQL 文档通过 Azure 门户或 Azure CLI 指标突出显示对 I/O 资源消耗的监视，包括存储限制、存储使用量百分比、已用存储和 I/O 使用百分比。

这些指标有助于回答最重要的操作问题： 哪个层实际上限制了性能？

如果没有可观测性，团队可能会在错误的方向上扩展。 查询计划问题可能类似于存储问题。 连接风暴可能表现为 CPU 压力。 缺少的索引可能类似于 IOPS 不足。 区域客户端放置问题可能类似于数据库延迟。

监视可帮助团队做出有针对性的更改，而不是昂贵的猜测。

实用规划清单

在选择“生产环境的 Azure Database for PostgreSQL”配置之前，请收集以下信息。

建议的设计原则

规划 Azure Postgres 部署以提升运营性能时，请使用以下原则。

• 根据工作负荷形状确定大小，而不仅仅是数据大小。
  如果数据库高度事务性和延迟敏感，则 500 GB 数据库可能需要的 IOPS 多于 5 TB 数据库。 大小很重要，但工作负荷行为很重要。
• 一起验证计算和存储。
  不要仅根据磁盘限制选择存储。 确认所选计算 SKU 可以驱动所需的 IOPS 和吞吐量。
• 将 4 TB 高级 SSD 缓存边界视为设计里程碑。
  4 TB 以下的高级 SSD 部署可以从主机缓存中受益。 在 4,096 GB 及以上，不支持主机缓存。 如果增长将超过该阈值，请提前规划未来的性能模型。
• 请考虑使用高级 SSD v2 进行灵活的性能优化。
  高级 SSD v2 允许更精细地控制容量、IOPS 和吞吐量。 当性能需求不完全映射到固定磁盘大小时，这可能是一个很好的选择。
• 将突发性能用于应对临时需求，而非持续的需求。
  应对短期的峰值突发情况是有帮助的，但如果是频繁或持续的突发，通常意味着需要重新评估基线配置。
• 匹配一代与雄心壮志。
  
• 在更改前后进行度量。
  在云中扩展更容易，但有效的扩展依赖于正确的度量。 捕获基线、峰值和更改后指标，以便性能决策基于证据。

实际基准：比较负载下的存储配置

本文中概述的原则不是理论上的。 为了演示计算、存储和工作负荷在实践中如何交互，本部分总结了 pgbench 比较受控制、测量条件下的存储配置和计算层的基准。

基准设置和方法

基准测试使用 pgbench标准 PostgreSQL 基准工具来模拟五种不同的存储和计算配置的事务工作负荷。 测试从 500 个并发连接开始，在初始阶段后增加到 750 个并发连接，并在测试窗口的其余部分保持这种提高后的连接负载。 此纵向扩展模式模拟随着流量增长而增加负载的实际应用程序数，并衡量数据库如何响应初始峰值和持续较高的并发性。

所有基准测试都在同一区域、同一可用性区域中的Azure Database for PostgreSQL灵活服务器上运行，使用相同的测试数据库和工作负荷配置文件。 通过将存储和计算隔离为变量，可以确保性能差异反映实际平台功能，而不是网络、应用程序或工作负荷变化。

配置详细信息

测试五种不同的配置，以区分存储层和计算大小，以说明关键规划概念。

配置设计的关键观察结果：

• 配置 1 与配置 2： 这些配置仅在存储大小、4,095 GB 与 4,096 GB 之间有所不同。 此比较测试高级 SSD v1 磁盘的主机缓存边界。
• 配置 2 与配置 3： 这两种配置都使用 SSD v1，但 Config 3 扩展到 32 TB 容量，以解锁更高的 IOPS 和吞吐量。
• 配置 3 与配置 4： 这两种配置使用相同的计算，但配置 4 展示了高级 SSD v2 在容量独立情况下的灵活 IOPS 和吞吐量。
• 配置 4 与配置 5： 配置 5 将计算 SKU 加倍，以演示较高层计算如何解锁更多存储性能的余地。

性能结果

配置 1：具有主机缓存的 4,095-GB 高级 SSD v1

配置 1 使用高级 SSD v1 硬盘的 4,095 GB 大小，这得益于高级 SSD v1 的主机缓存。 在工作负荷期间，此配置持续：

• 最大 IOPS： 24,773，在高级 SSD v1 上上限为 7,500 个预配的 IOPS，缓存可放大有效性能。
• 最大读取 IOPS： 21,330，受益于主机缓存来执行读取密集型操作。
• 最大写入 IOPS： 7,610。

主机缓存提供读取放大功能，因此有效 IOPS 暂时超出了磁盘的 7,500 个预配 IOPS 限制并达到计算存储限制。

配置 2：4,096-GB 高级 SSD v1，无需主机缓存

配置 2 使用 4,096-GB 高级 SSD v1 大小，跨越缓存边界并失去主机缓存优势。 影响可见：

• 最大 IOPS： 与配置 1 相比，由于缓存丢失，有效 IOPS 较低。
• 最大读取 IOPS： 在不带主机缓存的情况下显著减少。
• 最大写入 IOPS： 7,610，未更改。

此配置演示了 4 TB 缓存边界的实际重要性。 从 4,095 GB 转换到 4,096 GB 会导致性能表现变化，缓存读取被移除。 对于即将达到此阈值的不断增长的数据库，请提前规划。

配置 3：具有更高 IOPS 的 32 TB 高级 SSD v1

配置 3 通过扩展到 32 TB 的容量，解决了高级 SSD v1 在 IOPS（每秒输入输出操作数）和吞吐量上的限制。 此配置实现了：

• 最大 IOPS： 20,000。
• 最大读取 IOPS： 大约12,000。
• 最大写入 IOPS： 大约 5,000。

增加基础高级 SSD v1 存储容量会增加 IOPS 和吞吐量。 对于密集型工作负荷，仍可达到计算存储范围的上限。

配置 4：具有 40,000 IOPS 的高级 SSD v2

配置 4 演示高级 SSD v2 灵活性能配置，在 4,095 GB 的容量上预配 40,000 IOPS 和 1,200 MB/秒的吞吐量：

• 最大 IOPS： 由于 Premium SSD v2 的延迟和吞吐量能力，有效利用率更高。
• 最大读取 IOPS： 与高级 SSD v1 配置相比，提高了性能。
• 最大写入 IOPS： 更高的持续写入容量。

高级 SSD v2 允许预配高 IOPS，而无需大型存储容量，从而高效处理事务密集型工作负荷。

配置 5：D32ds_v5计算上具有 60,000 IOPS 的高级 SSD v2

配置 5 同时在存储性能和计算能力上进行扩展，其中存储性能达到 60,000 IOPS，计算使用 Standard_D32ds_v5 和 32 个 vCores。 此配置演示端到端对齐原则：

• 最大 IOPS： 明显高于所有以前的配置。
• 最大读取 IOPS： 通过额外的计算头空间进行强改进。
• 最大写入 IOPS： 持续更高的写入容量。

通过将计算层和存储与更高的性能层保持一致，此配置可实现最佳吞吐量和最低的 CPU 压力。 D32ds_v5更高的存储上限允许更充分地使用 60,000-IOPS 高级 SSD v2 磁盘。

基准测试的经验教训

这五种配置说明了本文的主要原则：

• 4 TB 缓存边界很重要。
  Config 1 与 Config 2 显示主机缓存提供低于 4 TB 的可度量读取性能放大，同时跨越 4,096 GB 会消除该优势。
• 容量不是性能。
  配置 3 预配了 32 TB，但未提供最高的 IOPS。 仅存储容量无法确定事务吞吐量。
• 高级 SSD v2 提供灵活的性能优化。
  配置四在适中容量上实现了高 IOPS，从而证明了高级 SSD v2 所支持的解耦模型的有效性。
• 必须对齐计算和存储。
  配置 5 显示，最大化存储性能需要足够的计算空间。 D32ds_v5更高的存储上限是更充分地使用 60,000-IOPS 预配所必需的。

基准结果验证核心原则：最佳性能是端到端属性。 没有单一层（如存储、计算或网络）可确定结果。 成功需要在所有层面进行有意的对齐，持续观察工作负载的演变，并进行测量验证。

结论

Azure Postgres 提供了一个强大且灵活的平台，用于构建现代云托管的数据库解决方案。 跨Azure计算、存储、网络、高可用性、复制、安全性和可观测性的工程可实现一些性能最高且可复原的 Postgres 体系结构。

性能上限不会意外发生。

最大化的运营性能需要了解应用程序、客户、工作负载、数据增长模式、读取/写入比例，以及决定需求的业务周期。 它还需要调整计算和存储选择，以便实现端到端的 IOPS、吞吐量和延迟目标。

高级 SSD v1 可以提供强大的可预测性能，尤其是在主机缓存应用于低于 4 TB 边界的数据时。 高级 SSD v2 通过分离容量、IOPS 和吞吐量来增加更灵活的性能配置。

最佳Azure Postgres 部署将平台功能与蓄意规划、持续监视和明确的运营所有权相结合。 借助正确的要求和正确的体系结构，团队可以提供提供提供最佳性能的世界级 Postgres 体验。

相关内容

• Azure 高级存储：高性能设计
• Azure磁盘突发
• Ddv5 和 Ddsv5 系列 VM 大小
• Ddsv6 系列 VM 大小
• Azure Database for PostgreSQL 中的 Premium SSD 存储选项
• Azure Database for PostgreSQL 中的 Premium SSD v2 存储选项
• Azure托管磁盘类型
• 监视 Azure Database for PostgreSQL 中的指标