3. 云上PostgreSQL实例规划
云上 PostgreSQL 的规格选型,本质上不是“挑一个最大配置”,而是把业务负载翻译成可量化的资源需求,再映射到云厂商提供的实例族、存储类型和网络能力上。选型偏小会导致连接排队、查询变慢、写入抖动;选型偏大则长期浪费成本。因此,规划的核心是建立“负载特征 → 资源指标 → 规格参数”的对应关系。
一、先明确五类资源与业务负载的映射
云数据库实例通常由计算、内存、存储、IOPS/吞吐、网络与连接数共同决定。它们并非独立,而是相互制约:内存不足会放大磁盘读,磁盘 IOPS 不足会拖慢事务提交,连接数过多会消耗内存并加剧 CPU 上下文切换。规划时应先识别业务属于 OLTP、OLAP 还是混合负载,再确定主导瓶颈。
| 资源维度 | 关键指标 | 典型业务信号 | 选型关注点 |
|---|---|---|---|
| 计算 | vCPU、主频、CPU 积分 | 高并发短事务、复杂排序聚合 | 通用型/计算型/突发型 |
| 内存 | 实例内存、shared_buffers、work_mem | 缓存命中率低、临时文件多 | 内存与数据热集比例 |
| 存储 | 容量、类型、IOPS、吞吐 | 写入量大、WAL 频繁、批量导入 | ESSD/SSD/高效云盘 |
| 网络 | 带宽、时延、内网/公网 | 跨可用区复制、应用远程访问 | 同 VPC、就近接入 |
| 连接数 | max_connections、连接池 | 连接数突增、空闲连接多 | 连接池 + 规格上限 |
二、计算与内存:从工作集和并发量估算
计算规格首先看 vCPU 与内存配比。OLTP 场景通常选择内存型或通用型,内存与 vCPU 比在 4:1 到 8:1 之间较常见;OLAP 场景更依赖 CPU 并行扫描和内存排序,可偏向计算型。一个实用的估算方法是:先统计活跃数据集大小,再按“热数据尽量驻留内存”的原则确定内存下限。
例如,某订单库活跃数据约 80 GB,历史归档后热数据约 30 GB。若希望热数据大部分命中缓存,实例内存至少应覆盖 30 GB 热数据,并预留约 25% 给连接、排序、维护操作,则内存需求约为 30 ÷ 0.75 ≈ 40 GB。对应可选择 8 vCPU / 32 GB 或 16 vCPU / 64 GB 规格,再结合并发压力决定。这里的数据为教学示例,实际应以监控和压测为准。
PostgreSQL 的关键内存参数需要与规格匹配:shared_buffers 通常设为实例内存的 25% 左右,work_mem 要按“最大并发排序数”反推,避免单连接占用过大导致 OOM。若 work_mem 设为 64 MB,而同时有 50 个排序操作,则潜在内存消耗可达 3.2 GB,必须纳入总内存预算。
三、存储与 IOPS:按写入量和事务提交频率估算
存储规划要同时看容量、IOPS 和吞吐。容量不能只看当前数据量,还要预留 WAL、临时文件、索引膨胀和未来增长。一般建议初始容量至少为当前数据量的 2 到 3 倍,并设置自动扩容阈值。
IOPS 估算可从 TPS 推导。假设业务峰值 2000 TPS,每个事务平均产生 4 次随机 I/O,则随机 IOPS 需求约为 2000 × 4 = 8000。若使用云盘,应选择能稳定提供 8000 以上随机 IOPS 的 ESSD PL1 或更高等级,并关注其 IOPS 与容量绑定关系。吞吐方面,批量导入或备份恢复场景更看重 MB/s,需单独评估顺序读写能力。
-- 查看当前数据库缓存命中率,辅助判断内存是否不足
SELECT
sum(blks_hit) AS hits,
sum(blks_read) AS reads,
round(sum(blks_hit)::numeric / nullif(sum(blks_hit + blks_read), 0) * 100, 2) AS hit_ratio
FROM pg_stat_database;
-- 查看临时文件使用,辅助判断 work_mem 是否偏小
SELECT datname, temp_files, temp_bytes
FROM pg_stat_database
ORDER BY temp_bytes DESC;
若缓存命中率长期低于 95%,或临时文件持续增长,说明内存或 work_mem 需要调整;若磁盘读延迟升高而 CPU 不高,则瓶颈更可能在存储 IOPS。
四、网络与连接数:避免“规格够但连不上”
网络规划重点在时延和带宽。应用与数据库应尽量部署在同一地域、同一 VPC,跨可用区访问会增加 1 到 2 ms 时延,跨地域则可能达到数十毫秒。对于高频小事务,时延放大会直接拉低 TPS。带宽方面,需评估备份、复制和批量导出是否与业务流量争抢。
连接数是最容易被低估的资源。PostgreSQL 每个连接对应一个后端进程,会消耗内存和调度开销。云实例的 max_connections 有上限,且并非越大越好。推荐做法是:应用侧使用 PgBouncer 等连接池,将数据库真实连接数控制在 200 到 500 以内,再根据规格调整。若应用直接创建数千连接,即使 CPU 和内存充足,也会因上下文切换和锁竞争导致性能下降。
五、规格选型流程与判断依据
综合以上维度,可按以下顺序推进:先根据业务类型确定实例族,再用热数据估算内存,用 TPS 和 I/O 次数估算 IOPS,用应用实例数估算连接数,最后校验网络时延和带宽。选型后应通过压测和监控验证,而不是一次性定死。
选型完成后,建议用真实业务 SQL 做压测,观察缓存命中率、磁盘 IOPS 使用率、连接数峰值和 CPU 利用率。若命中率低于 95%、IOPS 长期超过 80%、连接数接近上限,就应按图中路径逐项调整。规格选型不是一次性的,而是随业务增长持续校准的过程。